How to create a Product Roadmap everybody likes
A product roadmap is a powerful tool to communicate the product strategy, describe how a product is likely to grow, and organize the journey of product development.
However creating an effective roadmap is not easy, particularly in an agile context where changes occur frequently and unexpectedly. Executives have a vision of the future, sales and marketing teams want to be heard and engineering is waiting for those detailed requirements and user stories.
As a Product Management professional who is responsible for the overall success of the product, it is important to create a product roadmap that is compelling, can drive the strategy for the company and the development efforts and finally, can provide partners, press, analysts and customers with a clear idea of where the company is headed.
In my opinion, the best product managers start with a “goal first” approach and work to build consensus before building and sharing their roadmap. To accomplish this and get to a plan of record, I always follow few steps.
Define the product strategy
To start, you must clearly define your strategy by setting product vision, goals and initiatives for each product. Since major initiatives drive goals, it is good practice to link them together. Great products start with a clear strategy that is driven by the product-market fit. The strategy is the “why”. It is the foundation of a product lifecycle and its execution plan for further development. Strategy is comprised of three parts: Vision, Goals, and Initiatives. Product strategy is being achieved by the product roadmap.
Get consensus on goals and metrics
Goals and metrics are defined within the product strategy. They can be number driven (“increase conversions by 20%”) or more general (“mobile first approach”). Goal-oriented roadmaps focus on goals and objectives like acquiring customers, increasing engagement, and removing technical debt. Goals and metrics help product managers understand if the product is meetings its business goals and if the product strategy is working. Without KPIs, we end up guessing how the product is performing.
Once we get consensus from the product team and other stakeholders on the goals, it is fun time and get into real and fun work — define the features.
Wait! Features? Not really. Avoid feature-focused roadmap. My advice is a theme-focused approach. By grouping features together into themes, we can organize the roadmap in a way that describes value to customers and other stakeholders. Themes can help put together a roadmap that creates a story — the “why” behind what we are proposing. Themes help to keep the roadmap at a high level, especially for those long-term initiatives.
Requirements are coming from multiple sources, it is extremely important to listen to everybody and welcome every request and idea. At the same time, be ready to say “no”. While we want to get buy-in to from the key stakeholders, we should not say yes to every idea and request. This would turn the product roadmap into a random collection of features. Remember Steve Jobs? “Innovation is not about saying yes to everything. It’s about saying no to all but the most crucial features”. Keep the vision and product strategy in mind in order to make the right decisions.
Stay high level and keep it simple
A product roadmap is high-level plan where the product is heading. Stay high-level and don’t recreate the backlog. It’s all about the big picture. Resist the temptation of adding too many details to the roadmap. Keep it simple and easy to understand. Too many product roadmaps are feature-based, and it’s easy for stakeholders to get lost into the weeds. Instead, as mentioned before, use themes. The details, including the epics, user stories, scenarios and UI designs, belong in the product backlog and not on the roadmap.
Roadmaps are for communicating product managers’ plan and gaining consensus — it needs to be understood, it should tell a coherent story about the likely growth of the product. A visual representation is definitely better than a spreadsheet.
Make the roadmap measurable
Ensure that every goal is measurable. This tells if the goal have met or not. For example, if the goal is to acquire customers, then set how many new customers should be acquired; or if the goal is to reduce technical debt, determine how much of the bad code should be removed or refactored. Without a measurable target, it will be hard to tell if the goals are met. Nevertheless, it is important to set realistic targets and goals.
Whenever the product is new, young, or changing, it is a good practice to determine the development cost top-down. Determine how many people with which skills are likely to be required to create the desired releases on the roadmap. Draw on personal experience of developing similar products or previous versions of the same product; consider whether enough people with the right expertise are available in the company, or if hiring or contracting people is necessary. This should give an indication of the likely labor cost required and of the time as well.
Get buy in
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 product managers to leverage their ideas and knowledge and creates strong buy-in. I like to run a collaborative road-mapping workshop to engage everyone.
Work with engineers to get estimates
Plan releases and create backlog; this is the time to use dates and to view the roadmap timeline. Bring releases and features together for a unified view. Make sure specs, wireframes and, possibly, UIs, are well defined and documented in a backlog management tool like JIRA. Iteration with engineers is critical at this phase. Working as a team to define all the possible corner cases and details in order to make the feature well defined and user friendly. Pay extremely attention to details.
Product managers should focus on the use cases and the problem that a feature should solve and leave the solution to the engineers team. Engineers feedback are key during the prioritization phase.
Getting estimate and prioritization should be done almost at the same time. This is a catch-22 situation. On one hand, it is important to know the development effort for each feature in order to define the most productive sprints, but on the other hand, product managers should not be totally influenced by development effort and focus on highest scoring functionalities. Finding the right balance is essential.
Use a prioritization or scoring framework to guide the conversation. Of course, we can’t boil product decisions down to a score, but we can use it as a tool to provide transparency to everyone about how opportunities are evaluated, and then give them insight into our decisions. There are a lot of different ways to prioritize. The one I like and use the most is called Theme Scoring and it is described in the picture below.
First step is to define the classification criteria and its weight, then create the themes. After selecting a theme reference (a solid candidate for the next release), simply compare all the themes with that and calculate the scores. The order of the themes form the highest to the lowest score is basically the product roadmap.
Share the roadmap
It is probably best to keep two roadmaps — an internal one and an external one. Make sure they are aligned but they can be slightly customized based on the audience. The external release date can be different than the internal release dates. For customer views, show the theme of the release and key features in which they will be interested. Internal stakeholders will want to understand the strategic importance, conveyed through goals and initiatives. Use a tool to visualize the roadmap. There are many and each of them has, of course, pros and cons. The ones I have learnt and used are Roadmunk, Product Plan, Aha! and Jira portfolio. Once we have the visualization view we want, we can proudly share it with key stakeholders and easily keeping everyone up to date.
Regularly review and adjust the roadmap
Last but not least, review the roadmap pretty often. If the environment is agile, then change is likely to occur, therefore regularly reviews and updates are necessary. I suggest to do so between every four weeks to every three months depending on how young the product and how dynamic the market is.
In conclusion, creating a product roadmap is the biggest challenge that product managers face. Yet today, most product roadmaps are created “On The Fly” and under pressure when sales or the company execs makes a last-minute “urgent” request. It is up to us, product managers, to change this trend and take a more firm and scientific approach.
Hopefully this post contributes toward that direction and give all of you few items to consider when creating your product roadmaps.