A finance team we work with spent two quarters and a meaningful chunk of a contractor budget building a demand forecast. Gradient boosting, a feature store, a tidy backtest deck. When they finally put it in front of the VP of Ops, she pulled up the spreadsheet she maintains by hand and it was more accurate. Not by a rounding error, by enough that nobody in the room wanted to say it out loud.
This happens constantly, and it is not because the data science team was bad at their jobs. It is because forecast accuracy in most businesses is not bottlenecked by the model. It is bottlenecked by context, and context lives with the operator, not the modeler.
The asymmetry nobody accounts for
A model learns from history. That is the whole premise: feed it what happened, and it finds the patterns that tend to repeat. This works well right up until the moment the future stops looking like the past, which, in any business worth forecasting, is most of the time.
The VP of Ops knew three things the model could not:
A major account had quietly signaled it was consolidating vendors and would likely cut its order volume in the back half of the year. A competitor had just gone out of business, and some of that demand was about to land on her desk. And the spike the model was so confident about in the historical data? That was a one-time pull-forward from a customer who pre-bought ahead of a price increase, and it was never coming back.
None of that is in the time series. All of it matters more than the choice between ARIMA and a neural net. The operator is not winning because she is a better statistician. She is winning because she is holding information the model was never given.
What the forecasting competitions actually taught us
This is not a hunch. The Makridakis competitions (the long-running, public bake-offs where forecasting methods compete on thousands of real series) have been delivering the same uncomfortable lesson for years. Statistical sophistication does not reliably win. Simpler methods, sensibly applied, are shockingly hard to beat. Combinations of methods tend to outperform any single clever one. And where human judgment is allowed to adjust a baseline, it frequently helps.
The takeaway most people draw from this is "use simple models." That is half right. The more useful takeaway is that the marginal return on model complexity is low, and the marginal return on good context is high. If you are choosing where to spend the next month of effort, a gradient boosting model with mediocre inputs is a worse investment than a boring baseline with someone knowledgeable adjusting it for what they know is coming.
But operators are not magic either
It would be convenient to end there, "trust the gut, fire the data scientists," except that is not what we see in the data either. Left entirely to their own devices, operators make a predictable set of errors.
They over-anchor on the last thing that happened. A bad week bleeds into a pessimistic quarter; a good month gets extrapolated into a hockey stick. They almost never quantify uncertainty, so a forecast arrives as a single confident number with no sense of the range around it, which is the one thing a decision-maker actually needs. And the approach simply does not scale. One person can hold rich context on the top ten accounts or the top twenty SKUs. Nobody can do it across eight hundred of them, every week, without the whole thing degrading into copy-paste and stale assumptions.
So the honest picture is not "humans beat models." It is that humans and models are each strong exactly where the other is weak. The model is tireless, consistent, scales infinitely, and quantifies its own uncertainty. The operator has the context, the judgment, and the early-warning signals that never make it into a database.
The stack that actually works
The mistake is treating this as a choice. The teams that forecast well do not pick a side; they build a workflow where each side does what it is good at.
In practice that means a few things. The model should be good enough out of the box that nobody needs a research project to stand it up: a strong baseline on day one, not a six-month build. The operator should be able to inject context without learning to code: tell the system that a key account is churning, that a price change lands in March, that last spring's spike was a one-off and should not anchor the trend. And the output should always carry a range, not just a point, so the person making the call can see the downside as clearly as the expected case.
The version of this that fails is the one where the model is a black box the operator cannot touch, so they ignore it and go back to the spreadsheet, which is precisely how that two-quarter project ended up losing to a hand-maintained tab. The version that works treats the model as a fast, consistent first draft and the operator as the editor who knows what the draft cannot.
What this means for you
If you are deciding whether you need to hire a data science team to forecast well, the more useful question is whether your forecasting process lets the people with context shape the numbers. A small team with a good baseline and a tight loop between the model and the operators will beat a large team shipping models into a vacuum almost every time.
You do not need a data science team to forecast well. You need a forecast your operators can actually argue with, and a model good enough to be worth arguing with in the first place.