This article is a 3rd part in the series of blog post on ‘A practical guide to product roadmapping’. In this blog, i am focusing on the pragmatic purposes of product roadmap
2nd part – Why product roadmap?
Pragmatic purposes of product roadmap
The product roadmap apart from providing a blue print of where the product is heading and how the product is evolving over the next few years, they also serve specific purpose to each of the stakeholders and I have highlighted those purposes explicitly in this section. Each of those purposes further emphasize the importance of product roadmap.
Product Manager – Product roadmap preparation as a regular activity pushes the Product Manager to outline the product growth strategy to accomplish product objectives, translate the findings into product requirements/new products/new platforms/new solutions and finally add them to the product roadmap. Therefore it is appropriate to indicate that product roadmap reflects the product growth strategy and preparation of product roadmap will consciously let Product Manager to ponder upon the product growth strategy. Product Roadmap is also an important document that can aid Product Manager to reason out or justify the budget requirements for product development.
Customers – First and foremost, product roadmap provides confidence that the product is evolving. Secondly, it indicates the direction in which product is heading. The information is critical for customers to understand whether the evolution of the product is aligned with their business objectives. Thirdly, it provides timelines on when specific requirements would be delivered. Fourthly, customers can plan their business (expansion, launch of new services etc) accordingly. Finally, roadmap when shared with customer regularly eliminates conflicts or ambiguity between features expected by customers and planned features.
For the 4th point, many of you might question if product roadmap is just a plan, how customers could plan their business in accordance with the product roadmap. When I talk about roadmap, I am talking about a timeframe of 18-24 months and I generally split the roadmap into 4 pieces of 6 months each, assuming there is major SW release once in six months (discarding minor bug fix releases). The probability that contents of the product roadmap will change is relatively higher as we inch closer to the end of 2nd year. But the initial contents (0-6 months and 6-12 months) do not change much and customer can use that data for half-yearly or yearly planning.
Engineering team – Even though roadmap would be derived in consultation with engineering team, it provides direction to engineering team on how to align their resources to deliver the requirements added to the product roadmap. In case of new technology introduction or new product development, engineering team can also fathom about the need for new competencies accordingly can either plan to build or acquire those competencies.
Sales – Sales executive can use roadmap to close deals, to retain customers and to attract new customers, because roadmap provides the following inherent advantages:
- Roadmap provides competitive edge
- Roadmap can commit product requirements of either current or prospective customers. Roadmap is mostly a plan but in certain cases, few deals beget a need to commit addition of new features or products. In such specific scenarios, product roadmap acts as a commitment to deliver requested features or product within promised time frame.
- Roadmap is a sign that the product is evolving to meet future business challenges of both existing and prospective customer
Business development manager – Can look forward to expand the business into new territories or new market segments if new product requirements are being explicitly developed to foray into new geographical regions or new market segments. Even otherwise, BDM can estimate the revenue potential in his territory not only based on the current product capabilities but also based on how the product will be evolved.