Why roadmaps?
A product roadmap is your strategy for organizing your product development, outlining what you plan to do to achieve your business goals.
Roadmaps:
- Deliver transparency – both internally and to the customers.
- Facilitate the sharing of information between stakeholders.
- Link strategy with ‘how’.
- Provide focus on outcomes and results.
There are several types of product roadmaps – feature roadmaps and outcome-based roadmaps. In this article, we will review both.
These are just a few examples of roadmaps:
Beautiful? Maybe so – but there are certain crucial elements that aren’t in these roadmaps. These are strategy, priorities, and outcomes, as well as user needs.
Feature product roadmaps
A feature-based roadmap typically contains features or feature blocks that are organized according to time periods (e.g. weeks, months, quarters). They are clean and well designed.
Feature roadmaps state that you already know what you will build. They are more like release plans and do not account for new customer feedback and external or internal stakeholders’ input.
Can you see the outcomes? How about objectives? Can you see what value users really need?
The answer is simply no.
Now, let’s look at some definitions.
Outcomes
The outcomes are the results of creating your product, service, or feature. It can be the changes in processes, policies, and people that you aim to achieve. Outcomes may be positive or negative.
For example, when developing a resource management module, the overall purpose isn’t to have a resource pool with some utilization numbers but to enable the effective planning of resource time and to balance workload.
Feature roadmaps show features, not the outcomes that feature will create.
End-user needs
Product success depends on the ultimate satisfaction of your customers. This is dependent on your ability to solve their problems and meet their needs.
It is your job to ensure that these needs are accounted for in product development strategies. This will help you reach your business goals.
A business must take user needs into account to achieve its goals. Customer needs must be factored in during product development to ensure a win-win outcome.
Strategy & objectives
Being strategic means seeing a goal clearly and working towards it.
By being strategic, you can save time and money by staying focused, skipping unnecessary work, and narrowing the feature scope.
If a roadmap does not allow you to trace each feature to a specific outcome, you could ship features that nobody will use.
Priorities
How can you decide what to deliver first?
Prioritizing based on assumptions will lead you nowhere. Most likely, you will end up shipping features that no one will use. This is usually because the features don’t solve the real problems of end-users and thus fail to be adopted.
Prioritization is easier when you know the severity of a problem and the desired outcome. This makes it easy for anyone to understand priorities and eliminates any potential disagreements.
Outcome-driven roadmaps
An outcome-driven roadmap establishes a link between product vision, strategy, and the problems that need solving, and demonstrates how they will be solved.
For your customers, an outcome roadmap will demonstrate your understanding of problems and how the product will address those problems.
In other words, using a roadmap, stakeholders can see how the strategy will be implemented and what outcomes will be created.
How to build outcome-based roadmaps
Our approach is to use product roadmap software such as PPM Express roadmaps to create an outcome-based roadmap. However, you can use any software or even Google Sheets or Microsoft Excel.
We suggest dividing the roadmap into three levels:
- Top-level is the strategic goals / strategic objectives for the product. Imagine, they are similar to swim lanes. With PPM Express, you can import existing objectives into the roadmap.
- Then you can use outcomes as bars that define the primary direction / significant outcome expected by your customers. With PPM Express, these can be thought of as projects or programs.
- You can have your epics/projects and any other related work elements at the lower level – the ‘How’.
Epics can be prioritized using one of the standard prioritization models, so teams can work on the high-priority elements first. With PPM Express, for example, define the priority with the help of labels to indicate the implementation horizons – for example, ‘Now / Next / Future’.
This simple categorization technique of using labels makes it easy to quickly reprioritize work. You can choose the correct category based on its importance, and prioritize items within the category.
Timeline
Many experts say no to the timeline aspect of roadmaps. But in reality, we all live under time and budget constraints. We believe that using timelines is more than OK.
In this way, timelines are still crucial – your customers and your stakeholders will always ask ‘When?’ and you need to have an answer.
The ability to forecast approximate timeframes/horizons but actively manage expectations is part of a product manager’s job. You should avoid focusing on exact dates by communicating the fact that a roadmap does not constitute a commitment and is not a release plan.
With custom fields, you can additionally categorize all epics and features; with PPM Express, automated integration and synchronization with Jira or Azure DevOps Boards keep information up-to-date in real-time time.
Track the progress using the progress field or the state of the epic – but feel free to use any status/state/progress tracking methods that suit your needs.
Outcome-based roadmaps can help an organization create and present the connection between its objectives and the outcomes its customers expect. They list objectives, outcomes, epics, and priorities in a simple and straightforward way for all stakeholders.
There is a place for both types of roadmaps, and they can complement each other; it is your call which one to use, depending on your needs and circumstances.