From Strategy to Product Roadmap

The roadmap is probably the most relevant result of product strategy planning. But while they are sometimes considered as Gantt charts with feature-level granularity and exact release dates, they should instead be seen as a strategic communication tool, as a means to communicate the current stage of the product and an explanation of the strategy.

What is a Product Roadmap?

Let’s actually start with a not-so-good definition by one of the product management gurus:

I define product roadmap as a prioritized list of features and projects … typical roadmaps are the root cause of most waste and failed efforts in product organizations.

Marty Cagan | INSPIRED

Sorry, Marty, we disagree. Yes, roadmaps, as defined here, might cause more harm — but then the definition is wrong.

Instead of thinking of roadmaps as a Gantt chart, you should view them as an explanation of strategy and the current stage of your product.

Melissa Perri | Escaping the Build Trap
Much better, Melissa, even though a bit fuzzy — how would you create an artifact for an explanation? So let’s review another alternative:

A product roadmap is a high-level visual summary that maps out the vision and direction of your product offering over time. A product roadmap communicates the why and what behind what you’re building. A roadmap is a guiding strategic document as well as a plan for executing the product strategy.

ProductPlan
Much better! There are several elements of that definition, so let’s decompose. A roadmap
  • is a visual summary — not just plain text but a graphical illustration of the plan;
  • maps out vision and direction — so describes how the vision and strategy will be implemented, see below;
  • represents items over time — so, yes, a timeline is relevant, whether with explicit dates or some now/next/later representation, see below;
  • contains the why and what of what is being worked on — so initiatives and features connected to strategic intents;
  • is both a guiding document as well as some kind of plan.
Putting all of that together, we define roadmaps with just slight variations to the ProductPlan version as follows:

A product roadmap is a high-level visual summary that displays the strategic intents a product team will be working on. It shows the initiatives and features along these strategic intents over time and, thus, communicates what the team will be building in order to serve the product strategy.

Most people would agree that a roadmap should contain all the themes, epics, features, and stories that the team is working on. We believe
  • it’s better to keep the roadmap high-level — so ignore stories and maybe even features
  • but instead, add experiments or any other relevant product discovery activities (see part 3 of the book).

A Roadmap Translates Vision to Reality

When there are so many misunderstandings and misconceptions, why do we need roadmaps at all?

Vision Mission Strategy House
From Strategy to Goals and Roadmap
Firstly, roadmaps bring strategy to life. As shown in From Mission to Product Strategy, roadmaps become relevant once the high-level strategy has been defined. Ideally, strategic intents help to structure the planning process by defining high-level objectives along which subsequent activities can be organized. Thus, competing priorities are resolved to ensure focus across all teams which then also helps to avoid pet projects or wasting resources on less important tasks.
Secondly, roadmaps ensure internal alignment across all teams. Specifically when internal stakeholders are involved in creating the roadmap, then this process facilitates discussions of all relevant options and ensures transparency, for example to the Marketing team who might need to adjust campaigns and prepare impactful launches. Finally, roadmaps help communicate with external stakeholders, be they customers, investors, or else — see our concept of public roadmaps below.

7 Rules on How to Build a Roadmap

Regardless of the tool, in the following we provide a few tips for building good roadmaps:

#1 Use Strategic Intents to Structure a Roadmap

This is what was discussed already: Good roadmaps reflect the strategy, e.g. by explicitly mentioning themes or strategic intents, and using these to group related work items together. This offers several benefits:

  • It helps to organize the roadmap in a meaningful way based on higher-level strategic objectives.
  • It helps to communicate to stakeholders who, more often than not, are mostly interested in the strategic level but not so much in how items are broken down.
  • It lets teams rally around a strategic objective: when they finish an initiative and start the next one, it’s still serving the same strategic intent, so a lot is known already about the nature of the problem.
  • It ensures that all strategic intents are addressed — or else it will become obvious when there is an element of the strategy that is currently not covered.
  • It provides long-term transparency into the strategy: if the structure of the roadmap changes every quarter because new strategic intents are defined — then these are probably no strategic intents in the first place.

#2 Define Outcome-Based Roadmaps

Depicted to the right is another, more up-to-date version of a hypothetical roadmap of Netflix derived from Gibson Biddle‘s SMT model. As shown, every item to be worked on is explicitly linked to a metric to ensure some business-relevant outcome. This metric is not about features, number of tickets, or lines of code — it’s about moving the needle for something that is relevant to the customer.
Hypothetical roadmap of Netflix
Hypothetical roadmap of Netflix
Gibson Biddle | Medium

Sometimes, these metrics are not as straightforward as in the case of Netflix (and I even wonder whether these were so straightforward back then or are only in hindsight). Sometimes the data for these metrics is hard to collect. Sometimes the feedback loop is much slower thereby making it difficult to act upon that data. But, still, any such item should start with a hypothesis on the business value it provides.

#3 Keep Roadmaps in Problem Space

A great roadmap does not yet name solutions but instead still operates in the problem space. We will go deeper into problem space vs. solution space in part 3 of this playbook. For now, imagine a hypothetical company that decided to support business growth by addressing enterprise customers thereby increasing average deal size. Listing relevant product initiatives for that could yield initiatives to tackle the following problems:

How to scale for the data volume expected for large enterprise customers?
How to address the compliance needs of large enterprise customers?
How to support large enterprise customers operating in different legal jurisdictions?
How to ensure internationalization in terms of language, date and number formats, time zones, and such?
How to sell to large enterprise customers, specifically when they operate on a global level?

All these items are still problems and challenges. They are all opportunities for which solutions can be discussed with the entire team, including engineering.

#4 Quarterly Rolling Roadmap vs. Now/Next/Later

There is a hot debate as to whether or not roadmaps should include any timing:
  • Some argue that a Now / Next / Later representation is more appropriate because of the uncertainty that is in the very nature of (digital) product development.
  • Others use a quarterly rolling roadmap to at least provide a rough outline of what to expect and when.
According to our experience, when we Focus on B2B, an open Now / Next / Later representation will not be sufficient in many industries. Customers will want to know when they can expect the functionality such that they can prepare for and, e.g., organize pieces of training. The Sales team will ask when a certain functionality will be available and can be sold. Even when it’s phrased as Now / Next / Later, most people will implicitly assume a certain timing, for example, based on upcoming release schedules.

A great, so Now is this sprint. Next is this quarter. And Later is next quarter.

An unknown Sales person

But regardless of whether an approximate timing is explicitly mentioned in the roadmap or not, it is critical to state that there are other aspects more relevant:

  • Roadmaps are subject to change: Unless there is a legally binding commitment (which should be the absolute exception), then roadmaps may change without notice and solely based on the decision of the company, as represented by the product leader.
  • Roadmaps need frequent updates: Even when not changed explicitly, delays in certain work packages, dependencies to other teams and such might have an impact on the planning. Consequently, roadmap documents, no matter to tool, are living documents and require frequent updates. Probably not every hour — but depending on the delivery processes an update after every agile sprint might be a good idea.

To illustrate the need and also find a way to deal with engineering, who frequently hesitate to give estimates, we sometimes compare these estimations with route planning as delivered by a GPS:

1
2
3
4
5
6
7
8
9
10

To emphasize the analogy: based on well-defined destination, you always know where you are, you adjust based on circumstances, and you have clear data when you have achieved your goal.

#5 Share Roadmaps Internally, Again and Again

As mentioned above, the act of creating and updating the roadmap jointly in a team to achieve alignment might even be more valuable than the actual roadmap artifact itself. Likewise, roadmaps are a highly efficient tool to communicate the status quo and progress of the product inside the organization:

  • Senior executives are involved in shaping the roadmap at a very early stage when business outcomes are defined and prioritized. Also, later on, they want to be updated about the progress — which can effectively be done by showing them an up-to-date version of the roadmap. Remember the GPS analogy from above, executives want to know (a) where you are and (b) what’s your expected time of arrival.
  • The Sales team has to, well, sell. So they need something to sell. Even more so in enterprise B2B environments with long sales cycles. Not only will a roadmap show them the current priorities — but it will also help to explain why certain extra topics cannot be addressed right now even though one of their prospects might ask for it.
  • The Marketing team has to prepare for product launches and potentially even plan campaigns, say for specific target audiences, verticals, or regions. They don’t sit around idle waiting for a release date to only then jump on creating tons of marketing material. Instead, discussing the roadmap as early as possible with them will allow them to plan and prepare such that all the effort that was put into the product also pays off.
  • And, of course, the Engineering team, also needs to know what’s coming now / next / later. Also what other teams are doing and how all of that creates a bigger picture. Even more, the product backlog that will be worked on, day over day, sprint over sprint, will be derived from the product roadmap.
To cope with all these different needs, it’s good practice that the roadmap isn’t actually a document (as in Microsoft PowerPoint or Apple Keynote) but a living document in some kind of collaboration tool. This is where products like Aha!, Confluence, Jira, or ProductPlan shine because:
  1. The roadmap gets updated as a byproduct of daily work: any change in priority, delay along the product backlog etc. is reflected automatically.
  2. There is a single, unified, and consistent view on the roadmap accessible to the entire company.
  3. This view can easily be shared with anybody in the company, in any product communication, internal newsletters, and emails.
The latter is an aspect that can hardly be overestimated. While the Product Management team is working with elements of the product roadmap on a daily basis, others are not. So, it’s important to remind them of the underlying strategy and how we want to bring this strategy to life. As far as telling anybody in the company about the product roadmap, it’s even more true than anywhere else:

You cannot over-communicate.

Mario Lenz

#6 Share Roadmaps Externally

In a slightly revised version, roadmaps are also a great tool to communicate with customers and prospects as explained in more detail by way of Public Roadmaps.

#7 Don't be dogmatic but rather handle with care

Of course, Product Managers shouldn’t be dogmatic about the guidelines sketched above:

  • When there is a legal requirement on certain functionality that can be achieved by way of an easy feature, then don’t invent a strategic intent but instead just add the feature to the backlog.
  • When the solution to such a requirement is obvious, then skip the problem space and go to solution mode right away.
  • When there is a strict deadline for that requirement, for example for legal reasons, then add a delivery date so that everyone is aware.
 

We would argue once the Product Manager is aware of the above guidelines, and when exceptions are consciously decided, then she is already on the safe side.

Further Reading

ProductPlan

The Ultimate Guide to Product Roadmaps

A product roadmap is a high-level visual summary that maps out the vision and direction of your product offering. Learn all there is to know about roadmaps.

ProductPlan

(Don't) Scream If You Want To Go Faster, and How to Best Share Roadmaps with Stakeholders

Ah, roadmaps. It seems like there’s a new article every week about whether they should have dates on, whether they’re delivery plans, whether they’re commitments or not. This is not one of those articles.

Jason Knight | Substack

3 Different Types of Roadmaps Every PM Needs to Master

Here is a step by step process to create roadmaps so you can influence anyone in your company like a true Jedi.

Product Dave | Product Coalition

Ditch the Timeline Roadmap

An argument for Now / Next / Later.

ProdPad
Previous Chapter
Chapter 7:
From Mission to Product Strategy
Chapter 9:
From Roadmap to Product Backlog
Next Chapter

Table of Contents

Part I: Introduction
Chapter 1:
Preface
Chapter 2:
The Four Key Risks
Chapter 3:
Focus on B2B
Chapter 4:
StartUp vs. ScaleUp
Part II: From Vision to Roadmap
Chapter 5:
Purpose & Vision
Chapter 6:
From Vision to Product Mission
Chapter 7:
From Mission to Product Strategy
Chapter 8:
From Strategy to Product Roadmap
Chapter 9:
From Roadmap to Product Backlog
Part III: The PM Process
Chapter 10:
Process Overview
Chapter 11:
Idea Collection
Chapter 12:
Problem Discovery
Chapter 13:
Problem Definition
Chapter 14:
Solution Discovery
Chapter 15:
Solution Validation
Chapter 16:
Delivery
Chapter 17:
Distribution
Chapter 18:
Optimization
Part IV: Life as a Product Manager
Chapter 19:
Archetypes of Product Managers
Chapter 20:
Traits of a Great Product Manager
Chapter 21:
Competency Assessment
Chapter 22:
Transitioning into Product Management
Chapter 23:
Business Acumen for Product Managers
Chapter 24:
Communication as a Product Manager
Chapter 25:
Implementing Customer Discovery – A Case Study
Part V: Product Leadership
Chapter 26:
From Individual Contributor to Product Leader
Chapter 27:
Onboarding New Product Managers