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.

Outcomes

• 
• 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.

• execs create/maintain coherent strategic context
• execs design product boundaries/charters; set OKRs
• execs create product teams with agency, each having a single leader
• expect Teams to create north star metrics, continuous discovery, continuous delivery based on thinking in bets to solve prioritized customer customer problems (opportunity solution tree)