A practical guide to product roadmapping – Part I

I am now back to starting a  series of blog post related to Product Roadmap, I am basically attempting to provide some practical tips to product roadmapping based on my experiences of developing product strategy and creating product roadmap. In the 1st series i will be starting with the introduction of ‘What is Product Roadmap’ followed by series of blog posts related to ‘Product Roadmap’. Upon completion of the series, i will formulate an ebook and upload it to slideshare.

What is Product Roadmap?

Product roadmap is a collection of product requirements, solutions or new products planned to be released over a period of time. The product roadmap could be broadly classified into 2 categories:

  1. New product roadmap

As name suggests, this roadmap will outline the new products or platforms to be rolled out into the market. New product roadmap will be really long term (around 3 years, assuming new product introduction takes 12-18 months)

  1. Feature roadmap

Feature roadmap would contain product requirements addition to existing product line. The product requirements could be segregated based on themes (usability, performance, technology, new solutions, etc) or market segments. The duration of feature roadmap will be 18-24 months in general. In case of new product just launched into the market, it might be tough to prepare a long term roadmap especially if the product is addressing a new market and the customer needs are not lucid. The duration of the roadmap is dependent on the maturity of the market in addition to other factors.

Note: Please note that I am outlining my thoughts from my experiences of being a HW Product Manager for B2B product where the development cycles are longer than SW products, so the timelines that I had outlined might be too long for SW products (especially in agile development methodology). Also in B2B products, product roadmaps are generally shared with customers and it is not the norm in case of B2C products.

Internal vs External Roadmap

In most cases, there could be an internal and external roadmap. Product Manager does not directly add a feature to the external roadmap and share it with the customer. Most likely scenario is that after the Product Manager identifies a customer need, he will convert the need into a product requirement and discuss with engineering team to give a proper shape to the requirement. What I precisely meant by giving proper shape to the requirement is that while Product Manager will explain ‘What’ and ‘Why’ of the requirement, engineering can figure out ‘How’ part of the requirement to conduct high level feasibility analysis and estimate the time frame required to deliver the requirement. Internal roadmap could be termed as a work-in-progress item trying to finalize the contents of the roadmap collaborating with internal stake holders and later pushing it to the external roadmap after getting a buy-in internally. There are other notable differences between an internal and external roadmap.

  • The primary difference is that internal roadmap is engineering focused and it will be too technical, external roadmap is customer focused and therefore the use-cases/solutions that provide tangible benefits to the customer will be part of the external roadmap. For instance, if there is a feature that changes certain algorithms to improve the efficiency or make the product scalable, internal roadmap list the exact technical changes done to the product while external roadmap will abstract the customer from technical nitty-gritties and reveal only the possible benefits. So Product Manager while adding the exact technical requirements to the internal roadmap will add only the tangible benefits to the external roadmap.
  • External roadmap is a subset of internal roadmap. Product requirements, new technology or new platforms that are under evaluation might not find space in external roadmap. External roadmap can also be viewed as selling tool, so any additions to the external roadmap that does not directly contribute to the purpose of selling might not be added. For instance, changes to the product to make it more stable or efforts reduce the defects found is purely internal item and it will never be added to external roadmap
  • In case of external product roadmap, Product Manager has to ascertain (i) what to share, (ii) how much to share and (iii) when to share. I have earlier talked about (i) what to share and (ii) how much to share. Regarding (iii) when to share, there are no hard and fast rules. In case of new product arrival, even though the news might excite the customers sometimes the details could not be shared with them if there is a possibility of taking hit on the sales of existing products. So simple thumb rule that I follow is to ascertain the risks vs benefits of sharing the news over a time interval (probably 4 quarters) and identify at which specific interval does the benefits exceeds the risks. If Product Manager plots a simple graph of risks vs benefits on Y-axis and time interval on X-axis, the risks and benefits will be mostly linear with each of them following an inverse pattern.
  • Engineering team is the audience for internal roadmap while Customers, Sales Managers, Account Managers, and BDMs are the audience for external roadmap.

Appreciate your thoughts or opinions

This site uses Akismet to reduce spam. Learn how your comment data is processed.