Skip to content

Product management · 20 October 2026 · 2 min read

Why roadmap dates should be ranges

Research on the planning fallacy explains why single-date roadmaps slip. It also points to what helps: forecasting from past projects.

Most roadmaps promise dates, and most of those dates slip. Execution usually takes the blame. The research places the problem earlier, at the moment the estimate is made.

The planning fallacy

Daniel Kahneman and Amos Tversky described the planning fallacy in 1979. We estimate a task by picturing how this particular task will unfold, and we overlook how long similar tasks have taken before. The plan in our head is a best case that rarely happens.

Roger Buehler, Dale Griffin and Michael Ross measured the effect in 1994. They asked students writing an honours thesis to predict when they would finish. On average the students predicted 33.9 days and needed 55.5. Only 29.7% finished by their own best estimate. Even by the date they gave for everything going as badly as possible, fewer than half had finished: 48.7%.

In IT, the tail is the risk

Bent Flyvbjerg and Alexander Budzier analysed 1,471 IT projects. The average cost overrun was 27%, which sounds manageable. Averages hide tails. One project in six overran its budget by about 200% on average, and its schedule by almost 70%. A single date on a roadmap carries that risk and shows none of it.

Start from the outside view

The corrective Kahneman and Tversky proposed, and Flyvbjerg later developed into reference class forecasting, begins with the outside view. Look at the actual outcomes of a class of similar past projects, place the new project within that distribution, and only then adjust for what is genuinely different.

  • Give dates as ranges, and say what each end of the range assumes.
  • Write down the assumptions that must stay true for the date to hold, and review them at a fixed cadence.
  • Keep a record of your own estimates against actuals. After a few quarters it becomes your reference class.
  • Commit to the next quarter in detail and keep the rest directional.

In the programmes I have run, dates go out as ranges, with the risks listed beside them. It can look like a lack of confidence. According to the evidence, it is the kind of date people can actually keep.

Sources

  1. Flyvbjerg, B., & Budzier, A. (2011). Why your IT project may be riskier than you think. Harvard Business Review, 89(9).
  2. Flyvbjerg, B. (2006). From Nobel Prize to project management: Getting risks right. Project Management Journal, 37(3), 5–15.
  3. Buehler, R., Griffin, D., & Ross, M. (1994). Exploring the “planning fallacy”: Why people underestimate their task completion times. Journal of Personality and Social Psychology, 67(3), 366–381.
  4. Kahneman, D., & Tversky, A. (1979). Intuitive prediction: Biases and corrective procedures. TIMS Studies in Management Science, 12, 313–327.