The product roadmap can be an incredibly useful planning tool that aligns stakeholders and development teams and communicates how the product is expected to evolve. Unfortunately, this is not the case for all road maps. To ensure that your product roadmap is effective, you must make it goal-oriented or results-based, shared and actionable, as I will explain in this article.
Listen to this article:
Goal-oriented (machine-based results)
Traditionally, product roadmaps are output-focused programs that map features like registration, search, and timeline reporting. Such a roadmap basically indicates when some of the functionality will be provided. This can reassure customers and stakeholders, as people believe they know when their features will be delivered. But this approach has three disadvantages:
First, a feature-based roadmap makes it difficult to ensure consent and matchmaking, as stakeholders often compete to get their feature on the roadmap. Second, it overlaps with the product accumulator, especially when detailed features are used. This makes the product roadmap more sensitive to changes and it increases the effort to update it. Third, the attributes are sometimes considered as a commitment and not as part of a high-level program that is likely to change. It limits your ability to experiment and learn, discover the best way to address user and customer needs and create value for business.
I therefore recommend applying a different approach of road mapping and using Purpose-oriented road maps, Also called Result based. As their name implies, these roadmaps focus on product goals or results such as Customer acquisition, Increasing involvement, And Protecting the future of the product by removing technical debt. The goals indicate the specific value that a product may create and therefore communicate why it should be promoted. It helps align stakeholders and development teams, as I will discuss below, and purchase a budget if necessary. Finally, goal-oriented roadmaps are compatible Key Objectives and Results (OKRs): You can think of goals as goals and other roadmap components as key outcomes, as I explain in OKRs articles in Product Management. These benefits make goal-oriented, results-based products roadmaps a priority over traditional feature-focused programs, especially for digital products that exhibit uncertainty and change virtually throughout their life cycles.
If you’re looking for a template for creating a goal-oriented roadmap, try the roadmap of my GO product shown below.
In addition to destinations, the template above contains dates or time frames, names, attributes, and metrics. Note that attributes depend on results: each attribute must help meet the goal and achieve the desired benefit. Moreover, the destinations are the main roadmap components and are used to ensure compliance. You can find more information about the template in my article The Roadmap of the GO Product.
shared
No matter how well thought out your product roadmap is, it is worthless if key stakeholders and development team members do not understand and support it. A great way to get a shared roadmap is to involve people in the product mapping decisions of the product, preferably in the form of a joint workshop – whether it is online or on site.
![Product mapping workshop](https://www.romanpichler.com/wp-content/uploads/2016/07/roadmapping-workshop-with-stakeholders.png)
Note that collaborative road mapping does not mean that everyone gets their way or that they are necessarily super happy with every decision. It means leveraging people’s expertise to create a product roadmap that maximizes the value the product creates and attracts as much support as possible. While it is important that you cultivate an open mind, listen carefully to the ideas and concerns of stakeholders and development teams, and identify with them, do not let people tell you what to do. Otherwise, your roadmap may be a weak compromise rather than a compelling plan that helps create the desired value for users and the business.
Gain the courage to say no and ensure that the roadmap tells a coherent story about the expected growth of your product. Consider asking your Scrum Master or agile coach to lead the workshop and ensure that everyone is heard and no one is in control, assuming Scrum Master is available. This is especially helpful when participants are new to collaborative decision making and when they have not worked together before. (See my article Effective Product Decision Making: Decision Making Tips with Stakeholders and Development 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 program on a validated product strategy, a strategy whose key assumptions have been tested. Such a strategy should specify the needs of the user and the customer, the target group, the salient characteristics of the product and its business objectives. Before you develop a roadmap, you need to create and validate a product strategy, as the following image shows.
![The product strategy precedes the product roadmap](https://www.romanpichler.com/wp-content/uploads/2021/08/product-strategy-product-roadmap-1024x344.png)
In addition, you will need to choose a realistic time frame, a period in which you can anticipate the expected growth of your product without the need for speculation. My recommendation is to limit the roadmap of a digital product to the next six to twelve months and regularly check and update the program – once a quarter as a rule of thumb.
Finally, make sure the roadmap of your product does not contain too much detail. Adding, for example, epics and user stories, is a bad idea, as it blurs the line between the road map and the product cluster. Moreover, it leads to a roadmap of a product that is difficult to understand, prone to change and relatively difficult to manage. So you need to see your roadmap as a strategic plan, focus it on results and goals, and use it to describe the overall journey of your product. Let the product accumulator capture the product information, as shown in the following image.
![Product roadmap versus product aggregation](https://www.romanpichler.com/wp-content/uploads/2021/08/product-roadmap-vs-product-backlog-1024x361.png)
You can find more information about the correct relationship between the two objects in my article Roadmap of the product and the product aggregate.