As more and more organizations have started moving from project-based to product-based delivery, an understanding about product roadmap as an approach to manage the strategic direction is not only gaining prominence but also evolving and mutating in form. This, in turn, is also adding some confusion among users with regards to the format, utility and applicability of the roadmap. This blog is an attempt to clarify certain aspects of the product roadmap, how it is created and, what problems it solves. We will try to clear the clutter and establish it as an easy-to-use artifact.
What is product roadmap?
A product roadmap is a guide to planning and communicating the product strategy and is also an operational plan linking product vision at one end and the actual task of achieving it at the other. This definition makes it one of the important tools for product managers to guide product development effort and sync it with other product activities like GTM etc.
Usually, product managers use a product roadmap to communicate their product strategy to stakeholders and to plan and prioritize what needs to be build and when. This is essentially a high-level process well-organized to draw backlogs and release plan and, also has a scope for negotiation and collaboration to accommodate various viewpoints.
Figure – 1
Product roadmap design
Now, let’s understand how a product roadmap is designed. In most cases, it is derived out of the portfolio backlog and talks in terms of features. Figure 2 below will give you an illustration of where the roadmap fits in, at the program level below the portfolio.
Figure – 2
The portfolio backlog spans multi-year horizon comprising of business epics, technical epics and other high-level tasks. The product roadmap’s limit is typically up to one year depending on the type of industry and stability of the product. If the domain is highly volatile and the product is new, then a much smaller span of planning is considered.
The high-priority items from the portfolio backlog get elaborated further in the roadmap. This is typically presented as a progress bar with or without timelines and there are merits and demerits of both. For instance, in case of a timeline-based roadmap, the product manager will be able to answer in what timeframe a particular feature will be available; however, a common pitfall is it sometimes degenerates to a scheduling exercise rather than a strategic one.
As there are different types of epics at portfolio level and eventually different teams need to work on those, the roadmap is usually depicted in terms of themes and swim lanes. The swim lanes, depending on the type of roadmap, can represent teams, products, applications, impact areas and so on. It is usually a good practice to develop separate roadmaps for features, architecture, technology, GTM and marketing.
Figure – 3
Roadmap for prioritization
As mentioned earlier, the other important utility of a product roadmap is prioritization. There are multiple ways a roadmap can be prioritized, like Value Vs. Efforts, Weighted Scoring, Kano Model, Buy a Feature, Customer Satisfaction Score and so on. Also, at times, seemingly trivial methods like the Highest Paid Persons Opinion and Sales Commitment are also used to prioritize.
We find the combination of a weighted score and Value Vs. Efforts quite good to rely on. Now, let us understand the process in detail with the help of figure 3 below. In this, we score the features on a scale of 1-5 in terms of various business value they create. The individual business value parameters are assigned a weightage proportionate to their importance.
The weighted worth is the total sum of each business value parameter’s score multiplied by the assigned weightage. Once this is done, the effort is calculated based on a modified Fibonacci series. Then, we apply Dudes law to find out an “Index Value” by dividing weightage by effort.
Figure – 4
We then plot a graph, as seen in figure 4 below, by taking weightage value across ‘Y’ axis and effort forming the ‘X’ axis. The index values are represented by the size of the circle. So, the most valuable features along with their value are depicted in this single view. The main advantage of this is the product manager and other stakeholders can take a quick call on which features to prioritize for next sprints.
Figure – 5
Depending on requirement, the roadmap items may be further broken into features and capabilities, resulting in two separate backlogs to work upon. These are further elaborated at the backlog level in terms of user stories with each story comprising of various tasks and activities.
Conclusion
In a nutshell, a product roadmap is an instrument to decide on what needs to be done to achieve product vision. It provides a means to communicate strategy to stakeholders and frame a design on prioritizing features to be built. A well-planned, up-to-date and strategically positioned roadmap can be a key to solve as well as avoid numerous product problems that inevitably pop up throughout the product lifecycle.
Author information
Chinmoy Misra is a Technical Lead in Software Product Engineering practice at Hexaware Technologies Ltd. He has more than 15 years of experience in Coding, Product Management and Business Development. He has worked in multiple domains including, Civil Engineering, Unified Communication, Payments and Telecom.
