Product Roadmap (part 2)
- Aldrius Low
- Oct 21, 2019
- 7 min read
In the previous article, we defined product roadmap and highlighted its importance and purposes. In this article we will discuss some useful tips on constructing a functional and effective product roadmap that will fulfill the purposes discussed previously (For further reading on the importance/purposes of roadmapping, please refer to the previous article here) :
1) Purpose: Aligning business strategy with product development
Product roadmap serves as a guide for the product team to align the business strategy with product and technology decision. The following pointers might be useful for product team to consider:
Outline business and product strategy first
Before a roadmap is created, it is important to lay out both the business strategy and product strategy so that the product team can i) describe and validate the path to realising the product vision and ii) devise the best strategies to be implemented .
Simply put, a business strategy states how the company will be successful, and the product strategy describe how a product will achieve success. The business strategy provides the basis for making the right investment decision, including if a new product idea should be pursued and how much resources should be allocated to the product. Within that context, the product team can then devise and validate the product strategy that will outline key elements required to develop a successful product. These inputs can then be referred to when constructing product roadmap.
Focus on goals and benefits
A goal-oriented or theme-based product roadmap should be considered when the business environment is dynamic, i.e. when the product is still young and is experiencing significant changes, or when the market is dynamic with new competitors or new technology,
Goal-oriented product roadmap focuses on goals, objectives and outcomes, like increasing customer acquisition and retention, increasing customer engagement, or removing technical barriers. Features still do exist, but they are derived from goals and should be used only sparingly. This top down approach to roadmapping shifts the conversation from debating features to agreeing on high level objectives. This will in turn allows the product team to focus on making smart investment decisions, effectively drive resources allocation, and aligning the stakeholders expectation. Roman Pichler has written a very useful post on the Goal Oriented product Roadmap here.
2) Purpose: Planning and Synergy
Roadmapping allows the product team to devise an effective plan at the beginning of their development journey; ensuring the correct technologies and capabilities are available at the right time and allowing possible synergies through resources and technology sharing. These few tips below should help the product team to create functional roadmap that allows proper planning and synergy.
Create a coherent, realistic and simple product roadmap
Coherent: A Product roadmap should be coherent, i.e. it should be logical, consistent and make sense as a whole. It should tell the likely growth on the product, and each release should build on the previous releases, moving the product closer to the vision.
Realistic: The product roadmap should be realistic, i.e. there should not be over speculation on timeline and ability of the product development team to achieve the product vision. It is important that the product team assess all available resources and technology available to them. Similarly, the product team should not oversell the product as well.
Simple: Resist the urge of adding too many details to your roadmap. Keep your roadmap simple and easy to understand. Product roadmap should focus on the goal and capture what really matters. Which features are built to achieve the goals are less important than the goal itself. Therefore, there is no need to include every feature in the product roadmap. The details, including the epics, user stories, scenarios and UI designs, belong in the product backlog and not on your roadmap.
Making the product roadmap measurable
When using a goal-oriented roadmap, make sure that every goal is measurable. This will help the team to review and measure the success of their product in achieving the goals. For example, if the goal is to increase customer engagement, it is important to determine how much more time the customers spend on the product. If the goal is to retain customers, it is important to assess how much longer the customers are using the product or how much the customer churn are reduced. If there is no target, it will be hard to tell if a goal has been met.
It is important that :
i) the goals on the roadmap are realistic,
ii) realistic targets are set, and
iii) the correct metrics are selected that will help the team in determining if a goal has been met or if a release has delivered the desired benefit.
Regularly review and adjust the roadmap
Before agile development methods gain prevalence, a product roadmap underwent much less fluctuation during the product’s lifetime. Depending on the organization, a roadmap’s time frame might be locked in for 18 months or longer. However, in the age of agile development, a product roadmap has become much more of a living document, with far shorter time frames and more frequent adjustments.
The product roadmap should always be changing based on the resources available, company priorities and market conditions, Ideally, the product roadmap development process should be a cycle that feeds into itselfs.
A young product in a dynamic market should be reviewed more frequently, for example, every 2 to 4 weeks, as opposed to a mature product in a stable market where review can be less frequent, for example, every 3-6 months.
3) Purpose: Prioritisation
Product roadmap helps prioritise investments based on key drivers, ensuring the most important things are developed first, spending time and resources in the best way. In a perfect world, you're able to attack all your goals at once but realistically, you’ll need to identify which areas hold the highest priority. As such it is important to:
Utilise suitable frameworks to prioritise.
We will examine a few frameworks on prioritisation below. They can be used as a standalone or in collaboration with each other. (Further reading on the 7 strategies here)
Weighting the value vs. complexity
The product team can evaluate every opportunity based on its business value and its relative complexity to implement. This is a common approach, and many product managers go through this assessment instinctively every day.
Buy a Theme/Feature
This is an informal activity where you assign a price to a list of features/ themes and customers allocate funds to the features/ themes based on interest and need. It is often used with stakeholders and customers.
Story Mapping
This involves breaking down themes into tasks and thinking about how each story connects to the user experience. It is used a lot for identifying gaps in the MVP process.
Weighted Scoring
Product managers can develop their own scoring models to help them quantify the priorities and rank priorities based on their score.
Kano Model
Kano Model focuses on customer delight and investment required. Think of a graph where you’re trying to get the optimal customer delight for the minimal investment required.
Opportunity Scoring
Opportunity scoring is similar to the Kano model where you try to match the level of importance vs. customer satisfaction by scoring each of the variables from 1-10
Affinity Grouping
Affinity grouping helps to provide structure to a brainstorming session. The process can start with brainstorming opportunities where participants can put their ideas on papers / sticky notes. Then, as a team, they begin to group similar items together, and name the groups. Finally, everyone on the team begins to vote on or rank the groups.
4) Purpose: Communication
Product roadmap is very important for communication, both internally among key stakeholders and externally to customers. As such, it is important to bear in mind the following points when constructing product roadmaps.
Cater for your audience
It is important that the product team has the audience in mind when building the product roadmap so that they can tailor the content, focus and presentation to their needs. The audience can either internal or external. The different roadmaps that could be built are:
Internal Roadmap for Executives.
For executive stakeholders and leadership team, the aim should be to secure buy-in for the product vision and to maintain support and enthusiasm throughout the development cycle. These roadmaps should focus, therefore, on high-level strategic concepts — such as driving growth, new market penetration, customer satisfaction, or market position.
Internal Roadmap for Engineers
For engineers and development team, the aim of the product roadmap is to structure and guide the product development process. These roadmaps often focus on features, releases, sprints, and milestones. They are typically more granular in scope and shorter in duration than the executive-facing roadmaps. For those using agile development methods, these roadmaps are often at the epic or feature level.
However, it could be smart practice to include a component of product goals and themes in these roadmaps so your developers understand your rationale for specific deadlines and requirements.
Internal Roadmap for Sales
The sales team will want to know how the product will help them sell more, so the focus here should be on a combination of features and customer benefits. Whenever possible, group similar features/items into themes that sales reps can discuss with prospects.
External Roadmap for Customers and Prospects
The external roadmap for customers are aimed at communicating the business, technology and product plan to customers. The focus should be entirely on the product’s benefits to them. Because these are external documents, customer roadmaps should be visual, attractive and easy to understand.
It’s a best practice to not include the release or launch dates in external-facing roadmap. Unless you are certain about the product’s availability date, it is smart practice to avoid including dates in an external-facing roadmap to avoid over-commitment and prematurely locking in to a release date.
Secure Strong buy-in from Stakeholders
The best roadmap is worthless if the people required to develop, market, and sell the product don’t buy into it. The best way to create agreement is to collaborate with the key stakeholders to create and update the product roadmap. This allows the product team to leverage their ideas and knowledge and creates strong buy-in. Below are a list of possible sources that the product team should consider when creating product roadmap:
Customer feedback
Engineering
Sales and marketing
The c-suite
Partners
Company vision
Company business objectives
Company and product strategy
A good way of engaging everyone and create a shared product roadmap is to run a collaborative Product roadmapping workshop.
Know when to say No
While it is important to get buy-in from key stakeholders, it is not advisable to say yes to every idea and request, this would turn a product roadmap into a feature soup, i.e. a random collection of features. As Steve Jobs said, “Innovation is not about saying yes to everything. It’s about saying no to all but the most crucial features,”. In short, use your vision and product strategy to make the right decisions. Have the courage to say “no”. Remember: Collaboration requires leadership.
Conclusion
In the end, all roads lead to Rome, there is no one specific way to construct the best product roadmap. It is more important to consider the purpose of building the product roadmap, and subsequently developing the product roadmap to fit the predetermined purpose. I would like to end this article by providing a few useful links on product roadmap. i) Some useful Product Roadmap Templates: https://www.productplan.com/resources/product-roadmap-templates/
ii) Comparison site for Product Roadmapping software
Comments