Concept 4 of 4

Product roadmap and release plan

3 questions test this

The framework states the distinction in one line inside the Product Roadmap box. The roadmap is a plan, not a commitment. The Focus course spends time on it because almost every conflict a product manager has with sales or with an executive over timing traces back to the two documents having been merged.

What the roadmap carries

Direction and phases. Where the product is going, in what order the major pieces of that direction arrive, and what problem each phase solves. It reaches further out than anything can be reliably estimated for, which is precisely why it does not carry dates that anyone should hold you to.

A roadmap is useful when a reader can say what the product will be able to do for them by the end of a phase, and cannot say which Tuesday a particular feature ships.

What the release plan carries

Scope and dates. It covers the near horizon where the requirements are known, the effort has been estimated by the people doing the work, and dependencies are identified. It is a commitment in a way the roadmap is not, and it should cover a much shorter period.

The Focus course supplies release plan templates separately from roadmap material for exactly this reason.

Why merging them is expensive

A dated roadmap is read as a contract, and the reading is reasonable because it looks like one. Two things follow.

Sales sells the dates, which means the far end of the roadmap enters customer contracts before anybody has validated it.

The product manager starts defending the plan against evidence. New market information becomes an inconvenience rather than an input, which reverses the entire market-driven premise.

Communicating the difference

The move that works is not to hide the roadmap but to label the two documents and say what each guarantees. Near term, here is what is committed and when. Beyond that, here is the direction and the phases, which will change as we learn, and here is how you will hear about it when it does.

Stakeholders accept this far more readily than product managers expect, provided the near term commitments are actually met. Credibility on the release plan is what buys the freedom to keep the roadmap undated.

Reviewing it

A roadmap that has not changed in a year is either serving a very stable market or is not being informed by anything. Reviewing it on the same cycle as opportunity scoring keeps it connected to the evidence, and each change should be explainable by naming what was learned.

Common misconceptions

A roadmap with dates on it is more useful to stakeholders.

Dates on a roadmap get read as commitments and then defended, which turns every piece of new market evidence into a threat to the plan. Dates belong on the release plan, where the scope is known well enough to support them.

A roadmap is a list of features by quarter.

That is a release plan with the dates blurred. A roadmap shows phases of deliverables against a direction, so it can survive learning that a particular feature was the wrong way to reach the phase.

Changing the roadmap damages credibility.

Changing it without explanation does. Changing it because the market said something new, and saying which evidence changed it, is the behaviour that makes the next version believable.

3 questions test this concept

The framework states in the Product Roadmap box that the roadmap is a plan, not a commitment. What follows from adding dates to it?

  • ADates make the roadmap more useful because stakeholders can plan around them.
  • BDates are required for the roadmap to be approved by finance.
  • CDates get read as commitments, so sales sells the far end of the roadmap into customer contracts and the product manager starts defending the plan against new market evidence.
  • DNothing changes, since everyone understands roadmaps are provisional.
Check whether it stuck.

One per page, with a worked explanation.

Start the set
Related material
Book
Product Roadmaps Relaunched, On roadmaps organised around outcomes rather than dated features.
Book
Strategize, On the chain from vision through strategy to roadmap.
Book
Impact Mapping, On tying deliverables to the behaviour they are meant to change.
Template
Outcome roadmap, Quarters expressed as measurable outcomes, each with a target metric, current baseline and a confidence rating.