cognitive psychology
Planning fallacy
What is the planning fallacy?
The planning fallacy is our habit of underestimating how long things will take and how much they'll cost, even when we know similar tasks have run over before. We picture the smooth, best-case version and quietly leave out the interruptions, rework and surprises that always show up - so the plan is optimistic almost by default.
Also known as: planning fallacy, optimism bias in planning
Prefer to watch?
Watch the recap 0:54
The demo
Quick estimate: you're shipping a small feature - design, build, review, release. How many days will it really take? Set your gut number, then watch reality fill in what you left out.
What this demo shows (text version)
You estimate how many days a small feature will take, then the demo plays out a realistic timeline. Your estimate covers the smooth run - design, build, review, release - while reality adds the steps people routinely leave out of a plan: waiting for review, a bug that needs fixing, a dependency that isn't ready. The actual bar ends up noticeably longer than the estimate.
That gap is the planning fallacy: we estimate from an imagined best case and omit the interruptions and rework that history guarantees. The reliable fix is the outside view - estimate from how long similar past work actually took, break work down to expose hidden steps, and add buffers rather than trusting the tidy plan in your head.
People estimate from the best case, not the typical case. We imagine the task going to plan and forget the delays, dependencies and do-overs that history says are coming, so estimates skew short - for ourselves far more than when we judge others. In product work this is why timelines slip and "quick" features aren't. The defences: estimate from how long similar past work actually took (the outside view), break work down so hidden steps surface, and build in buffers rather than trusting the tidy story in your head.
Your gut estimate was the smooth run - everything going right, nothing interrupting. Reality added the bits you mentally skipped: the wait, the rework, the surprise. That gap is the planning fallacy, and it barely shrinks even when you know about it. The cure isn't trying harder to imagine the steps; it's anchoring on how long this kind of thing has actually taken before.
The fallacy persists because we plan with the "inside view" - imagining this specific task unfolding step by step - which naturally produces a best-case story and omits the unknowns. The robust fix is the "outside view": ignore the details and ask how long similar projects actually took. Reference history beats imagined sequences, because history already includes the interruptions you can't foresee.
It's strikingly resistant to awareness and to optimism: people underestimate even when reminded of past overruns, and even when they consciously try to be cautious. It's also asymmetric - we're far more optimistic about our own tasks than about other people's, where we readily predict delays. This is why self-set deadlines slip while our forecasts for colleagues are often closer to the mark.
In product and design work it shows up as slipping roadmaps, underscoped "quick wins", and user-facing time estimates that prove wrong. Counter it by breaking work down until hidden steps appear, estimating from comparable completed work, padding for the unknown, and tracking estimate versus actual so your future guesses are calibrated by real data rather than hope.