Product Roadmap isn’t About Features
In an ideal world, a product roadmap should make it easier for us to build winning products. It should help us to create solutions that deliver real value to customers. However, the story doesn’t go that way in reality sometimes.
Roadmaps can fail and, when they do, teams may be tempted to conclude that they are not helpful. The real problem isn’t just these documents per se but the understanding that we have of them. What people call product roadmaps, at times, are really not.
What a Product Roadmap Is Not
Ask product managers what a product roadmap is and most would likely describe it as a plan of what is to come. That’s not wrong — but if we are to go further and ask to see examples of what they have in mind, that’s where the problem starts.
What many PMs would probably present as a roadmap is nothing more than a list of features and a timeline. We could find it hard to identify the strategy that is driving whatever work they are planning to do from these documents.
A list of features that we’d want our product to have doesn’t necessarily qualify as a product roadmap. If team members cannot look at the document and immediately tell why we have to do certain work or the value we’re looking to create, then what we have created isn’t a real roadmap.
A product roadmap isn’t a backlog that shows what we want to build. The latter is ideally a product of the former. It lists out in the order of priority the tasks that we have to execute to achieve the vision and goals identified in our strategic document.
What we have isn’t a roadmap or is at best a bad roadmap if someone cannot easily connect the work to the strategy by simply looking at it. Such a face could make us conclude, as some do, that roadmaps are bad and don’t aid success.
What a Product Roadmap Is
What then is a true product roadmap? It is simply a high-level summary of the evolution of the product over time. A shared source of truth, the document maps out the vision, direction, priorities, and status of our product over time. It outlines the big efforts that are needed for the product to contribute to the achievement of overall business objectives.
A product roadmap helps us to make clear why we are building what we are. This is arguably the biggest thing that sets it apart from a list of features or a backlog. The document shows what direction we are heading and why we are doing so. It conveys the product vision and strategy.
Let’s imagine that what we call a roadmap is nothing more than a list of features. This makes it hard for other people in the organization to fathom why we decided on those features. Developers, for instance, may not be able to identify what items are more important and why. We’d also have a hard time convincing Sales and Marketing on why we think specific features are more important.
A bad roadmap will also, no doubt, make getting buy-in from stakeholders more difficult.
With a genuine product roadmap, the strategic goal becomes obvious to everyone. Teams and stakeholders then have something they can quickly refer to if they find themselves going off track or forgetting the strategic goal.
How to Build a True Product Roadmap
To create a real, effective roadmap, the following are some key steps that we can follow.
Identify the “why”
When looking to build a product (and its roadmap), we have to first justify it. Why should we continue? We need to set the product vision and establish how our work will support the overall business objectives. Our strategy provides the “why” of what we’re building.
Hone in on the customer
It is critical to be able to show how what we will build can add value to our customers. We must be explicit about what our customers need, providing all the necessary details. We should make it clear how our work will help end-users to meet their needs.
This explanation should avoid the use of technical language and be easy for stakeholders to grasp. We need not go into precise details of how developers will get the job done.
Set measurable goals
We should identify and set goals – quantifiable ones – when building a product roadmap. What do we aim to achieve over a period? After identifying goals, we proceed to determine the initiatives (within our capacity and resources) that can help us to achieve them.
Get feedback
Building a product roadmap isn’t a one-man show. It is not something that we leave exclusively to product managers. We should share the “what” and the “why” with stakeholders for their feedback. This can go a long way in fostering a shared understanding for faster, easier, and more effective decision-making.
Decide priorities
Having established our vision and the direction we’re heading, we now need to settle on our priorities based on the strategy. What items are more important for the achievement of our goals? We should identify key or strategic themes that are market or customer-driven. This simplifies how we go about deciding what’s more important to do first. With the foregoing well-covered, it becomes easy building a true product roadmap. We’ll thus be able to create a strategic document that’s truly worthwhile.
