A Product Roadmap is an overall view of the product’s requirements and a valuable tool for planning and organizing the journey of product development. Roadmaps revolve around desired goals and outcomes and help to communicate both your big picture narrative—that pie-in-the-sky vision—and the series of steps you anticipate will help you meet that vision over time.
Before we dive into techniques that help with defining, discussing and presenting a strategic product roadmap, and how to translate it into an actionable plan, let’s talk about what makes a good product roadmap.
There are numerous definitions of what a product roadmap is – from detailed feature/function/timeline-oriented documents to high-level vision papers and presentations focused on themes and metrics.
Looking at this list, it’s clear that we need to stop thinking of roadmaps as only feature lists and Gantt charts.
A great roadmap is a strategic communication tool for all stakeholders involved in the process. As such, it’s essential to not only get the content right, but also the presentation – which should be crystal clear and accessible for everyone.
Remember: your marketing and support teams need to plan their work based on the roadmap, too!
A product roadmap is a powerful tool to describe how a product is likely to grow, to align the stakeholders, and to acquire a budget for developing the product. But creating an effective roadmap is not easy, particularly in an agile context where changes occur frequently and unexpectedly. Below are 4 steps for creating an actionable agile product roadmap:
When you first create your product roadmap, you likely will start with large, high-level requirements at two different levels:
Themes are “a promise to solve problems, not build features,” says Jared Spool, founder of User Interface Engineering. Think of themes as organization-wide focus areas. What do you want to focus on over the next quarter, 6-months, year? Where do you want to spend time and resources? Do you want to spend them on performance, user experience, security, new competitive features, or a combination of all these? Of course, most of us want to focus on everything, but there’s always those two pesky realities – time and money. Setting your high-priority themes and features will help you focus your time and energy to do a few things really well.
When you start creating requirements at the theme and feature level, it can help to write those requirements on index cards or big sticky notes. Using a physical card that you can move from one category to another and back again can make organizing and prioritizing those requirements very easy.
After you identify your product requirements features, you work with the development team to group the requirements under the themes you identified. A stakeholder meeting works well for grouping requirements, just like it works for creating requirements. You can group features by usage flow, technical similarity, or business need.
In this stage, you’ll begin to populate your Product Backlog by breaking down the work required for each larger initiative into more consumable pieces, like epics. This will give you a granular view of all of the steps required to achieve your initiative and will help you with the next, and arguably most important, step in this planning process: estimating.
After you identify your product requirements and arrange those requirements into logical groups, you should order the requirements according to priority.
To order requirements, you must first estimate a score to represent the value and effort for each requirement. To order your requirements, you also want to know any dependencies. A dependency is a requirement needed before another requirement. For example, if you have an application that needs someone to log in with a username and password, the requirement for creating the username would be a dependency for the requirement for creating the password, because you generally need a username to set up a password.
Estimating, or scoring, requirements on value and effort is a key first step to ordering those requirements. You work with two different groups to score your requirements:
Scrum teams often use the Fibonacci sizing sequence for creating requirement scores. The Fibonacci sequence goes in a progression in which each number, except the first two, is the sum of the prior two numbers — 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, and so on.
Use your scores relatively. Choose a requirement that the project team can agree has a small value and effort, score it, and use that requirement as a benchmark. To score other requirements, decide whether other requirements have more or less value than your benchmark requirement and whether they are easier or harder than your benchmark requirement.
You may use two benchmark requirements, one for value and one for effort. In the end, the relative score, not the absolute score, matters.
After you have your value and effort scores for your requirements, you can calculate the relative priority of each requirement. Relative priority helps you understand how one requirement relates to another in terms of value. When you know the relative priority of your requirements, you can order them on your product roadmap.
Calculate relative priority with the formula: Relative priority = value/effort
For example, if you have a requirement with a value of 89 and an effort of 55, the relative priority is 1.62 (89/55 = 1.62), which you could round to 2 — in fact, you can round all fractional results to the nearest whole number.
Using this formula, a requirement with high value and low effort has a high relative priority. For example, if the value is 144 and the effort is 3, the relative priority is 48. A requirement with a low value and high effort has a lower relative priority. For example, if the value is 2 and the effort is 89, the relative priority is 0.0224. This formula usually produces fractional results. If you want, you can round those to the nearest whole number.
Note the relative priority for each requirement. From here, you can review your requirements simultaneously and prioritize them.
To determine the overall priority for your requirements, answer the following questions:
Using the answers to these questions, you can place the highest-priority requirements first. Your prioritized list of user stories is called a product backlog. Your product backlog is an important agile document, or in agile terms, an artifact. You use this backlog throughout your entire project. With a product backlog in hand, you can start adding target releases to your product roadmap.
When you first create your product roadmap, your time frames for releasing product requirements are at a very high level. The traditional planning triangle shows that a plan has three variables: scope (what you want to do), time (how long it will take to do it), and resources (who can do it). Now that you have an estimated backlog, releases, and teams with a velocity, you have all the data you need to create a realistic forecast, or roadmap.
This is where the expertise of your product managers really come in to play. By looking at similar efforts in the past, you can get a good idea of what it takes to complete each epic.
Also, because estimating requires knowledge of past efforts for similar epics, it makes it even more important to store your information in one place. That makes looking back much simpler and your estimates more accurate. At a later date, you’ll take the final roadmap to the team (developers, etc.) where they’ll scope it out with even more accuracy.
For the initial roadmap, choose logical time increments for your sprints/iterations, such as a certain number of days, weeks, months, quarters (three-month periods), or even larger increments. Using both the requirement and its related priority, you can add requirements to each increment of time.
Take your new, shiny roadmap back to your team and validate it. Let the team break down the epics into stories and give their best estimations for how long the work will take. Use these outside players to validate and adjust your assumptions to make your estimates, and the steps needed to complete your epics, more accurate. You should run your roadmap by key stakeholders as well, especially if their approval is needed to move forward on certain steps.
With Agile, no project is ever done. Continuing to deliver value through incremental improvements is what drives innovation and competitive edge. Use your roadmap to inform and optimize future roadmaps, get customer feedback, and keep testing and improving on a frequent and regular basis.
Focus on goals and benefits: Whenever you are faced with an agile, dynamic environment, you should work with a goal-oriented product roadmap, sometimes also referred to as theme-based. Goal-oriented roadmaps focus on goals, objectives, and outcomes such as acquiring customers, increasing engagement, and removing technical debt. Features still exist, but they are derived from the goals and should be used sparingly. Use no more than three to five features per goal, as a rule of thumb.
Do the necessary prep work: Describe and validate the product strategy—the path to realize your vision—before you create your roadmap and decide how the strategy is best implemented. Many teams like to use tools such as Product Vision Board to develop a valid product strategy. The board captures the vision, the target group, the problem to be solved or the benefit to be provided, the key features of the product, and the business goals.
Tell a coherent story: Your product roadmap should tell a coherent story about the likely growth of your product. Each release should build on the previous one and move you closer towards your vision. Be clear who your audience is: An internal product roadmap talks to development, marketing, sales, service, and the other groups involved in making your product a success; and external roadmap is aimed at existing and prospective customers. Keep your roadmap realistic: Don’t speculate and don’t oversell your product.
Keep it simple: Resist the temptation of adding too many details to your roadmap. Keep your roadmap simple and easy to understand. Capture what really matters and leave out the rest by focusing on the goals. Keep the features on your roadmap coarse-grained and derive them from the goals. The details, including the epics, user stories, scenarios and UI designs, belong in the product backlog and not on your roadmap.
Actively collaborate with stakeholders to ensure 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 you to leverage their ideas and knowledge and creates strong buy-in. Running a collaborative roadmapping workshop is a great way to engage everyone and create a shared product roadmap.
Have the courage to say No: While you want to get buy-in to from the key stakeholders, you should not say yes to every idea and request. This would turn your product roadmap into a feature soup, a random collection of features. “Innovation is not about saying yes to everything. It’s about saying no to all but the most crucial features,” said Steve Jobs. Use your vision and product strategy to make the right decisions. Have the courage to say “no.” Remember: Collaboration requires leadership.
Know when to show dates: Some people recommend to never show dates on a product roadmap, while others always include them. We recommend using dates or timeframe on your internal roadmap that coordinates the work carried out by the internal stakeholders, such as, the development team, marketing, sales, and support. This is particularly important for date-driven products like smartphones that must be ready for Christmas sales or a travel app that has to be updated before the summer holidays start. But when you use an external roadmap that is shown to customers and users and often used as a sales tool, then we recommend not showing any dates or timeframes.
Make your roadmap is measurable: When using a goal-oriented roadmap, ensure that every goal is measurable. This allows you to tell if you have met the goal or not. If you don’t state a target, it will be hard to tell if you have met the goal or not. Make sure, though, that you state a realistic target, and that the goals on your roadmap are realistic. Then select the metrics that will help you determine if a goal has been met and if a release has delivered the desired benefit.
Regularly Review and Adjust the Roadmap: Last but not least, if the environment you’re in is agile, then change is likely to occur. You should therefore regularly review and update your product roadmap—between every four weeks to every three months depending on how young your product is and how dynamic the market is.