Writing by Peter Hilton

Roadmaps in two dimensions and three levels

How to relate your roadmap to what matters 2020-04-21 #product

Cute kittens

unsplash-logoJari Hytönen

After a recent meeting, someone commented that the product roadmap should show ‘how new roadmap items contribute to the overall progress of strategic initiatives’. They’d seen slides describing individual roadmap items - customer problems that upcoming work would address - but couldn’t relate them to long-term strategic initiatives. Indeed, if you don’t link the work to higher-level initiatives, then your roadmap looks like a random collection of work.

You can’t solve roadmap chaos by showing larger problems (assuming that you have a problem-based roadmap, rather than a feature backlog). That makes the roadmap more abstract, and you lose the concreteness in the chaos of lots of smaller problems to solve. Instead, you need to overlay a higher level that maps the objectives you’ll reach by solving those problems.

Use swim lanes for objectives

Adding swim lanes for objectives explains roadmap initiatives by grouping them, and answering the question of why? Swim lanes work because you pursue more than one objective in parallel, in practice.

Example roadmap, with swim lanes for two objectives
Get users hooked (objective)
Show cat cutenessShow cat cutenessPuppies
Enable social sharingFamous catsRabbits
World domination (objective)
Legal protectionCat politiciansDemote humans to staff
CitizenshipRewrite lawsWorld domination!

This hypothetical roadmap uses a familiar column-based relative time format (now, next, later - see The Birth of the Modern Roadmap), with two product objectives that provide context for the problems the roadmap addresses. Horizontal time horizons and vertical objectives make the roadmap two-dimensional, with three levels of detail.

Three levels of detail

At a high-level, the example roadmap (above) pursues two objectives at a time, and four customer problems. Objectives sit at the ‘top’ - the most abstract - of the levels of detail. You can structure your roadmap’s detail levels how ever you like, and it might end up like this.

  1. Long-term objectives, stable over time horizons, guide the work.
  2. Medium-term initiatives, spanning one or more time horizons, address related problems.
  3. Short-term work - in progress now and complete before what comes next.

In the example above, Show cat cuteness spans two time horizons, and could include short-term work such as:

These represent development work to build concrete product capabilities, which agile software development teams sometimes call epics. (Epic means long story, referring to the storytelling metaphor behind user stories.)

A system for explaining why

A multi-level roadmap like this achieves more than merely looking good in the next management meeting (although they love this stuff). This kind of roadmap creates a more important kind of transparency about the purpose of product development work.

The levels create a system for answering questions about why we should build this, and making roadmap tradeoffs. You build product capabilities, to solve customer problems, in pursuit of product objectives. And with luck, your product objectives contribute to a clearly-articulated company strategy.

Share on TwitterShare on LinkedIn