A product Roadmap is a high-level plan that shows how a product is likely to evolve. Scott Sehlhorst, product management and strategy consultant describes two views of the product roadmap in his recent blog.
Your product roadmap is a view of what you are building right now, in the near future, and in the more distant future. Or is your roadmap a view of why you are building whatever you’re building right now, in the near future, and in the more distant future?
Scott says that product roadmap includes both the views but one is more important than the other based on situation.
One view of what team is building includes the specification as precise right now, less specific in the near term, and very flexible in the future. Janna Bastow, product manager and founder of ProductCamp London, describes the rolling-wave planning in her blog on creating flexible roadmaps.
The concept of why you are building a product is different from what you are building. Why includes specific reason of building something. Scott says that your team is building a product with a set of capabilities, which you hope your customers will choose and use to help with solving their problems.
As a product manager, your perspective needs to be rooted in the perspective of the problems your customers are trying to solve – the intent driving your roadmap – not the things your team is building in order to solve the problem.
Roman Pichler, product management expert and owner of Pichler Consulting, mentions in his blog on creating an agile product roadmap that goals come first which drives the features selection.
I recommend that you derive the features on your roadmap from the corresponding goal. The features should be the key product capabilities or themes required to reach the goal. If your goal is to improve the user experience (UX), then an example for a feature would be “intuitive, hassle-free user registration” (assuming that the current registration process is not great).
Scott mentioned that where the view of what to build gets fuzzier as you move from the present to the future, the view of why you build gets clearer as you move from the present to the future. Both points of view are valid. From one point of view, all of the clarity occurs in the immediate term, and from the other point of view, all of the clarity manifests in the longer-term big picture.
A product manager has to be able to switch between both views – and communicate in either framework – depending on the context of what they are doing in the moment. Building the roadmap is working backwards from the customer to the feature.