Project-oriented Roadmaps are counter-productive for Software Product Teams

Project-oriented Roadmaps are counter-productive for Software Product Teams.

Context: a management team wants to maximize the net-value-added during a year, by a product-development organization (multiple teams, post-product-market-fit).

Forces: management believes

  • they can generate, or at least judge, the most valuable ideas
  • the most valuable ideas can be packaged as large-ish (team-quarter or more) projects
  • large-ish projects can be estimated in time with reasonable accuracy
  • imposing a deadline as a commitment on a project will increase "urgency" and thereby increase velocity

Wrong-Solution: the Roadmap

  • The product-dev organization proposes more candidate-projects than could be done in the year.
  • Other executives will also propose candidate-projects.
  • Each candidate-project will have its scope defined, in a description of 1-10 pages.
  • All candidate-projects will be estimated for benefit and cost (person-months → team-months).
  • The management team will pick the "winning" projects.
  • The management team will set the priority/sequence of projects.
  • The management team might push for team re-organization to fit that roadmap.


  • map
  • Because everyone under-estimates how much of product-dev capacity gets taken up with operations/maintenance, bugs-fixing, and other unplanned-work (incl employee turnover/training), capacity is lower than estimated.
  • Because projects are planned in so far in advance, customer validation is rarely performed during roadmapping.
  • Once a project scope/deadline is defined, customer validation can only slow development.
  • Internal/executive stakeholders will often drive "project requirements", which will tend to not fit in the budgeted timeframe
  • Projects will rarely be deployed in increments. At "best" there will be a phased rollout which will generate bugs/requirements which weren't budgeted for.
  • Teams will rush to meet deadlines, sacrificing architecture and development quality, increasing technical debt.
  • Most projects are late, and deliver less-than-expected value.
  • For the following year, new projects are scoped/picked/developed, rather than building on the feedback of the completed work. This also means technical debt will not be reduced because nobody will be touching the same code in a coherent way.
  • Don't trust me, ask Martin Cagan: (2015-06-05) Cagan Product Fail

Improved Solution: Agile Product Development.

Edited:    |       |    Search Twitter for discussion