A product-development plan for a series of projects to be completed in a year. An Anti-Pattern.

Context: a management team wants to maximize the net-value-added during a year, by a product-development organization.

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.


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

In a StartUp, investors may want a 3-yr plan. This is supposed to do things like

  • Show that you're realistic enough not to think you'll be Done in a year.
  • Show that you are prepared for waves of bigger-market-attack, vs being a Life-Style Business
  • Create an expectation of progress MileStones which you will inevitably fail to meet.

Sept'2015: Martin Cagan sketches an alternative to the Road Map. Earlier I said we needed to acknowledge the two drivers for old-style roadmaps. The first was the desire to work on the highest Business Value items first. (see Nature Of Software Development) Hopefully it is clear that this need is addressed by management providing the specific objectives for the organization and their prioritization. The difference is that they are now prioritizing the importance of business results, rather than perceived value of features. The second driver was the need for Commitments. We address this with the concept of high-integrity commitments. We do this for those situations where we need to actually commit to a date or a specific deliverable.

A more-mature company may use a 1-yr RoadMap to

  • justify staffing (budget cycle)
  • try and encourage teams to Think (not-too-) Big with Project packaging (also creating implicit Commitments way too early for realism).

A process I'm trying to encourage

  • Start by prioritizing Problems/BottleNecks that need solving. Get group agreement on the top-3. Stop talking/thinking about others.
  • Spend lots of time on Idea Generation for attacking each those 3 Problems.
  • Rank/prioritize the Ideas, taking into account rough Cost and Odds of Success (see RICE model). (Avoid justifying an Idea by its attack on Multiple Problems, as that's (usually) more a source of distraction/diffusion than benefit.)
  • Restructure each Idea to start delivering results faster, (a) to accelerate benefit, and (b) to accelerate learning whether there will be benefit.
  • Stop working an idea once you've made Good Enough progress.
  • Periodically repeat Problem ranking and Idea Generation.

The MetaVerse Road Map Group provides a different Framing: A roadmap is the outcome of a collaborative foresight process that considers a broad set of factors and strategies important to reaching a future goal. cf Theory of Change

Roadmaps can include vision statements (Shared Vision), forecasts, scenarios (Scenario Planning), strategy and plans, but go beyond such tools in three ways:

  1. They emerge in a collaboration network of multidisciplinary and competing experts,

  2. They emphasize uncertainties and challenges as much as probable and preferred futures, and

  3. They have long-term time horizons (five to fifteen years is common) by comparison to traditional forecasts and plans.

Wikis often includes RoadMap pages for specific topics/themes to bring together some context across key related pages. (See WikiWikiWeb:RoadMap.)

Some pages in this space which are "classic Wiki roadmaps":

A different framing - Pattern Language

The way people figured out where to drive before GPS, like animals.

Edited:    |       |    Search Twitter for discussion