Ask a team how long the project will take and you get a story: the architecture is cleaner this time, the dependencies are known, the hard part is already prototyped. The estimate falls out of the story. It is usually wrong, usually in the same direction, and usually by a lot.
Daniel Kahneman had a name for where that estimate comes from: the inside view. You build it from the particulars of the case in front of you — this team, this design, this quarter. It feels rigorous because it is detailed. But detail is exactly what makes it optimistic, because a plan is a story about things going right, and the things that go wrong are the ones the story has no scene for. Illness, a departure, a dependency that ships late, the requirement discovered in month three. None of them is in the plan, and one of them almost always happens.
His fix came out of his own failure, which he told against himself for the rest of his career. A textbook project he joined estimated two years to completion. When he asked a colleague how long comparable projects had actually taken, the answer was that a large share never finished at all, and the survivors took seven to ten years. The team heard the number, agreed it was sobering, and carried on — and took closer to a decade, by which time the syllabus had moved on.
Start from the record, not the story
The outside view is a change in the order of operations. Before arguing about what makes this project special, ask what happened to projects like it. Not in the abstract — concretely: the last five migrations this company ran, the last five launches this size, the industry's record for integrations of this shape. That distribution is your starting estimate. The inside story only earns adjustments from there, and the burden of proof sits on the claim of difference, not on the record.
The uncomfortable part is that this works best precisely when it feels least necessary. The more compelling the inside story — the stronger the team, the cleaner the design — the more confident the estimate, and confidence is not evidence. The record of similar cases already includes the projects that had strong teams and clean designs. That is what a base rate is.
In practice the move takes an afternoon. Name the reference class. Collect even a rough distribution — five or six cases is enough to be sobering. Put your estimate beside it. If your number sits far below the record, write down what specifically about this case justifies the gap, and treat each justification as a claim someone should be allowed to attack.
Watch out for
The method has a soft spot: choosing the reference class is a judgment, and a motivated chooser can pick a flattering one. Compare your platform migration to routine upgrades and the base rate blesses your optimism. The honest version picks the class before seeing what it implies.
And the lens deserves its own medicine. Kahneman endorsed findings in print that the replication crisis later flattened, and said so — he had trusted small studies because their conclusions were compelling. The inside view is not a flaw in other people. It is the default setting of anyone holding a good story, including the man who named it.
Answer this next
For the estimate you are most committed to right now: what is the actual record of the last five comparable attempts — and if you do not know, what does it mean that nobody has looked?
