28 Mar 2019
4 mins read
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.
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.
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.
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.
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.
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.
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.
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.
About the Author
Application Transformation Mgmt.
31 Jan 2020
03 Sep 2019
31 Aug 2019
03 Jul 2019
26 Apr 2019
13 Aug 2018
19 Jun 2018
Application Transformation Mgmt., Healthcare, Insurance
18 Jun 2018
28 Nov 2017
14 Sep 2016
03 Sep 2016
25 Aug 2016
11 Jul 2016
17 Feb 2012
BI & Analytics
03 Jan 2013
Digital Assurance
04 Feb 2013
06 Feb 2013
Digital Assurance, Enterprise Solutions
14 Feb 2013
18 Feb 2013
21 Feb 2013
27 Feb 2013
Others
01 Mar 2013
04 Mar 2013
Enterprise Solutions
05 Mar 2013
18 Mar 2013
Digital Assurance, Enterprise Solutions, Others
22 Mar 2013
12 Apr 2013
26 Apr 2013
29 Apr 2013
13 May 2013
11 Jun 2013
17 Jun 2013
25 Jun 2013
19 Aug 2013
26 Aug 2013
27 Aug 2013
03 Sep 2013
10 Sep 2013
19 Sep 2013
24 Sep 2013
26 Sep 2013
30 Sep 2013
01 Oct 2013
03 Oct 2013
01 Nov 2013
19 Nov 2013
Enterprise Solutions, Manufacturing and Consumer
28 Nov 2013
03 Dec 2013
20 Dec 2013
03 Jan 2014
22 Jan 2014
27 Jan 2014
31 Jan 2014
12 Feb 2014
13 Feb 2014
20 Mar 2014
24 Mar 2014
17 Apr 2014
11 Jun 2014
Manufacturing and Consumer
26 Jun 2014
30 Jun 2014
10 Jul 2014
15 Jul 2014
16 Jul 2014
18 Jul 2014
28 Oct 2014
13 Jul 2015
06 Aug 2015
26 Aug 2015
28 Sep 2015
07 Oct 2015
26 Oct 2015
Infrastructure Mgmt. Services
07 Mar 2016
22 Mar 2016
13 May 2016
23 May 2016
15 Nov 2016
22 Nov 2016
25 Nov 2016
Business Process Services
25 Apr 2017
Banking and Financial Services
18 May 2017
30 May 2017
23 Jun 2017
27 Jun 2017
18 Jul 2017
26 Oct 2017
Healthcare, Insurance
11 Dec 2017
25 Jan 2018
21 Feb 2018
14 Mar 2018
22 Mar 2018
23 Apr 2018
15 Jun 2018
( Mandatory field * )
The information you provide will be used in accordance with our terms ofPolicy Policy
* Please select 'I Agree' or 'No, Thanks'