How long did the last one take?

Kahneman told this one on himself. Years ago he was on a team writing a new curriculum, and at some point they did the sensible thing and estimated how long it would take. Going around the room, walking through the work, they landed on about two years. Then he thought to ask a colleague who had seen a number of similar efforts from the outside: how had those gone? The colleague, a little embarrassed, said that of the teams he’d watched, the ones that finished had taken seven to ten years — and roughly forty percent never finished at all. The team heard this, absorbed it, and carried on with their two-year plan anyway. Their project took eight years.

That gap has a name, the planning fallacy, and its mechanism is worth being precise about. When we estimate a task, we build the estimate from the inside — we imagine this specific project going step by step to completion, and the story runs smooth, because a story about the future can only contain the obstacles you can already name. It cannot contain the specific thing that will actually go wrong, for the simple reason that if you could picture it, you’d have planned around it. So the estimate systematically leaves out the category of “the unforeseen,” which, across enough projects, is the most predictable line item there is.

The cruel part is that effort makes it worse in a particular way. The more carefully you plan the happy path — the more detailed the tickets, the more thorough the breakdown — the more vivid and convincing the smooth story becomes, and the more confident you get in a number that’s still missing the same blank space. Detail feels like rigor. Here it’s often just a higher-resolution picture of the version where nothing surprises you.

⁂

Kahneman’s fix was to stop looking through the plan and start looking across your history: the outside view. Bent Flyvbjerg later turned it into a discipline he calls reference-class forecasting, built into some public-infrastructure planning after decades of megaprojects blowing through their budgets. The idea is almost rude in its simplicity. Don’t estimate the feature. Find the last five comparable things your team actually shipped, ask how long each one really took — from the day you started to the day it was truly done, counting the weeks you’d rather not — and let that spread be your forecast. Your detailed plan is a story about this one. The base rate is evidence from all the others, and the others already told you the truth about your smooth stories.

For a roadmap, that turns into a few concrete habits. Keep a plain log of past work items and their real ship dates; it costs almost nothing and it’s the only reference class you’ll trust, because it’s yours. When a new item comes up, forecast it from the class first — “features like this have taken us six to ten weeks” — and then adjust for genuine differences, not for optimism. And treat the sentence “but this one is different” as a yellow flag rather than an argument, because every one of the last five came with its own reason for being the exception, and they averaged out to the number you’re now ignoring.

⁂

The honest limits matter here, maybe more than usual. Reference-class forecasting needs a reference class, and for genuinely novel work — a thing your team has never attempted in any recognizable form — you may not have one, and the outside view has less to offer. It can also mislead if you pick the wrong class: filing something under “small feature” when it’s secretly a platform change will hand you a confidently wrong number from the wrong shelf. And taken too far it becomes its own vice, sandbagging every estimate into safe irrelevance. The skill isn’t applying a fixed multiplier to your gut. It’s choosing an honest class and believing what it tells you, especially when the inside story disagrees.

The next thing on the roadmap always feels like the exception to all of this. So did the last one, and the four before it.