Three Qualities of Great Product Roadmaps

Listen to this article:

Goal-oriented (a.k.a. Outcome-based)

Traditionally, product roadmaps are output-focussed plans that map features like registration, search, and reporting onto a timeline. Such a roadmap essentially states when a piece of functionality will be delivered. This can be reassuring for customers and stakeholders, as the individuals believe that they know when their features will be delivered. But this approach has three drawbacks:

First, a feature-based roadmap makes it hard to secure agreement and create alignment, as stakeholders often compete to get their feature on the roadmap. Second, it overlaps with the product backlog, especially when detailed features are used. This makes the product roadmap more susceptible to change and it increases the effort to update it. Third, the features are sometimes regarded as a commitment rather than a part of a high-level plan that is likely to change. This limits your ability to experiment and learn, to discover the best way to address the user and customer needs and create value for the business.

I therefore recommend applying a different product roadmapping approach and using goal-oriented roadmaps, which are also called outcome-based. As their name suggests, these roadmaps focus on product goals or outcomes such as acquiring customers, increasing engagement, and future-proofing the product by removing technical debt. The goals state the specific value a product is likely to create and therefore communicate why it is worthwhile to progress it. This helps align the stakeholders and development teams, as I discuss below, and acquire a budget if required. Lastly, goal-oriented roadmaps are compatible with objectives and key results (OKRs): You can think of the goals as objectives and the other roadmap elements as the key results, as I explain in my article OKRs in Product Management. These benefits make goal-oriented, outcome-based product roadmaps preferable to traditional, feature-focused plans, especially for digital products that exhibit uncertainty and change virtually across their entire life cycles.

If you are looking for a template to create a goal-oriented roadmap, then try my GO product roadmap shown below.

In addition to goals, the template above contains dates or time frames, names, features, and metrics. Note that the features depend on the outcomes: Each feature must help meet a goal and achieve the desired benefit. What’s more, the goals are the primary roadmap elements and are used to secure agreement. You can find more information about the template in my article The GO Product Roadmap.

---

Shared

No matter how well thought-out your product roadmap is, it is worthless if the key stakeholders and the development team members don’t understand and support it. A great way to achieve a shared roadmap is to involve the individuals in the product roadmapping decisions, preferably in the form of a collaborative workshop—be it online or onsite.

Note that collaborative roadmapping does not mean that everybody gets their way or is necessarily super happy with every single decision. It means leveraging people’s expertise to create a product roadmap that maximises the value the product creates and that attracts as much support as possible. While it’s important that you cultivate an open mind, attentively listen to the ideas and concerns of the stakeholders and dev teams, and empathise with them, you should not allow the individuals to tell you what to do. Otherwise, your roadmap may end up being a weak compromise rather than a compelling plan that helps create the desired value for the users and the business.

Have the courage to say no and ensure that the roadmap tells a coherent story about the likely growth of your product. Consider asking your Scrum Master or agile coach to facilitate the workshop and to ensure that everybody is heard and nobody dominates, assuming that a Scrum Master is available. This is particularly helpful when the attendees are new to collaborative decision-making and when they haven’t worked together before. (See my article Making Effective Product Decisions: Tips for Deciding with Stakeholders and Dev Teams for more information on collaborative decision-making.)

---

Actionable

For a product roadmap to be effective, it must be actionable. The best way to achieve this is to base the plan on a validated product strategy, a strategy whose key assumptions have been tested. Such a strategy should state the user and customer needs, the target group, the product’s stand-out features, and its business goals. Before you develop a roadmap, you should therefore create and validate a product strategy, as the following picture shows.

Additionally, you will have to choose a realistic time frame, a period for which you can anticipate the likely growth of your product without resorting to speculation. My recommendation is to limit the roadmap of a digital product to the next six to twelve months and to regularly review and update the plan—once per quarter as a rule of thumb.

Finally, make sure that your product roadmap does not contain too much detail. Adding, for example, epics and user stories, is a bad idea, as it blurs the line between the roadmap and the product backlog. What’s more, it results in a product roadmap that is difficult to understand, prone to change, and comparatively difficult to manage. You should therefore view your roadmap as a strategic plan, focus it on outcomes and goals, and use it to describe your product’s overall journey. Let the product backlog capture the product details, as the following picture shows.

You can find more information the right relationship between the two artefacts in my article The Product Roadmap and the Product Backlog.