What is a product roadmap?
A product roadmap is a strategic plan that displays workflow and milestones of the pipeline. It clarifies the product strategy implementation through milestones – epics and features. The scope usually includes engineering, marketing, hiring, and so on. The product roadmap allows you to establish and track the order in which things are to be worked on.
A product roadmap is a high-level plan that displays workflow and milestones of a strategy-based pipeline
It is vital to differentiate roadmapping from lower-level planning approaches like a backlog. The product backlog is a task board for a product team. It contains information about current iteration, tasks for the next iteration, and icebox. Here, the focus is made on technical aspects of the pipeline. The product roadmap is a strategic planning tool with a focus on user needs. It sets out the main job to be done within the product development. In some cases, the backlog may be a part of the roadmap.
What is a product roadmap for?
Antoine de Saint-Exupéry said that a goal without a plan is just a wish. Roadmapping allows you to plan things that will contribute to your pipeline. The agile product roadmap is a living guide for the team during the development journey. With it, you know where to move and when to pivot if you’re heading in the wrong direction. Here are some other benefits or reasons to use this high-level plan:
Building a development team. The product roadmap process provides data transparency within the team. Also, the team members get shared ownership of the strategy.
Goal setting. The plan lets you focus on achievable goals and avoid scattering. Thus, a winning product strategy rests on specific areas with the best performance. You can point out realistic objectives and recognize weak points from the outset.
Information sharing. A good product roadmap is a concise yet content-rich data source. It gives a clear vision of where the workflow is heading. Also, it serves as an adequate source of data for clients and stakeholders. You can use the roadmap as a framework for setting partnership relations. The document can also be a bargaining chip in negotiations.
Driving resource efficiency. One of the product roadmap benefits is workflow prioritization. This, in turn, allows for enhancing the efficiency of resource usage. Knowing the order of features to implement lets you distribute your investments properly.
Cross-functional planning. Creating a product roadmap is not about one focus area. It involves cross-functional planning. The roadmap incorporates all the supplementary areas required to build a product. The objectives of engineering, design and other areas are to be recognized in the roadmap. This provides a long-term perspective on the pipeline.
Roadmapping gives you evidence of strategy. You should not take it as just a list of tasks to be done. It is a plan based on product vision and strategy that lets you define the tactic for product development.
Product roadmap structure
The product roadmap format typically looks similar to a Gantt chart but differs in the gist. Gantt charts assume a linear delivery of tasks. And they are directly dependent on one another. In most cases, this type of document excludes any schedule modification. A product roadmap is an agile tool. Hence, it’s mutable and assumes both direct dependency and loose coupling among tasks.
Roadmaps can have many structures and forms due to the scope and purpose. Simple formats may contain lots of information. They are useful to provide the big picture. Conversely, roadmaps with complex structures are more informative despite the sparse context. They also provide the full picture and map out many details. Both simple and complex formats mostly have a two-axis structure:
- A horizontal axis is responsible for timing. The product roadmap extends to the right for a certain time period.
In no-dates roadmaps, there is no specific schedule. Instead, you rank tasks by their state like Next Up, Prepare, Done, etc.
- A vertical axis usually depicts product roadmap prioritization. Here are some approaches you can use for that.
Top-to-bottom: the most important or valuable task/ideas are always on top.
Feature-driven: the focus is to be made on building and releasing features. You classify tasks as Core, Actual, Augmented, and so on. This approach suits best to mature products with a stable market.
MoSCoW: you classify tasks according to their importance. The categories include Must-haves, Should-haves, Could-haves, and Won’t-haves. Read how we use MoSCoW for different activities.
It is not necessary to use a Gantt chart view for your product development roadmap. You may opt for an advanced Kanban board or another visualization template. The roadmap has to cover the entire strategy of your product.
Timeline and no-dates product roadmaps
Timing is an integral element of the product roadmap and strategy or is it? Railsware opts for both timeline and no-dates planning. The choice usually depends on product goals.
Roadmaps without deadlines
The timeless approach is useful for early-stage products. No-date product roadmaps provide flexibility to frequent updates. Your progress is mostly defined by finding a footing for further development. Strict long-term planning is no fit here.
If you are in search of product-market fit and first users, deadlines are not an option. Instead, you may use different state categories like IN PROGRESS, BLOCKED, TO DO, etc. Here is how we do that.
Roadmaps with deadlines
The majority of product roadmaps are time-based. That’s what the guys from Roadmunk, a roadmapping tool, claim. Indeed, products with a focus on evolution, marketing, and sales need pinpoint planning. Besides, deadlines show the long-term vision of your activities.
After the go-to-market stage, your product roadmap agenda should rely on dates. Scheduling is required for a proper growth strategy. First, you may operate deadlines on a quarterly or monthly basis. Later on, your timing can have a longer-term horizon. Take a look at the following example of a time-based product roadmap provided by another planning tool – ProductPlan.
How to build a product roadmap?
We don’t want you to do roadmapping like this:
Choose a tool
Lay out the timeline
Prioritize epics and features
Our product roadmap guide will help you launch and execute product development. So, you need to investigate the content for the roadmap first.
Inputs and content
In this context, inputs belong to the problem space. They include strategic objectives, value propositions, improvement ideas, and other factors. The identified inputs will help you set epics and features by priority on the roadmap.
The roadmap content should be clear for stakeholders. Do not overfill the plan with detail. Jeff Bezos once said: Be stubborn on vision but flexible on details. The best advice here is to have roadmap clean and tidy to know what you are working on and what you could do next.
Roadmap type
At Railsware, we leverage different types of roadmaps. The choice depends on the scope and purpose. You are free to tailor your own one to a specific framework (e.g., Jobs to be done), team, and so on. Here are some options to consider:
- Audience-based
The thing here is to take into account the audience to share the roadmap with. Two categories are used – internal and external. The internal audience includes in-house stakeholders. These are sales, engineering, and other teams. Take a look at the following example of our internal roadmap.
Product roadmaps for external audiences do not contain specific information and timing. Their purpose is to introduce high-level data to the public. Hence, the emphasis is made on visual appeal of the content.
- Purpose-based
Will a product roadmap for startups and stable products differ? They will due to different purposes. For example, here is a template you may enjoy to roadmap your startup product.
When your product has passed the nascent stage, or you’re handling multiple products, a portfolio roadmap may be your option.
The product roadmap taxonomy is not strictly set. So, certain inputs, as well as other factors, are crucial to take on board. Once you have them on, you can pick the format of content to build the roadmap.
Roadmap format
- Goal-oriented
It is a commonly used format. A goal-oriented or GO roadmap has the data encased around the goals. Each goal explains why you need it and what benefit it can bring. The planning rests on goals and does not interfere with your product strategy.
- Theme-based
This format is a derivative of the GO. In this context, a theme is an area of focus or a problem to be solved. The idea is to explain why you need a particular feature or task. Theme-based roadmaps, also known as lean product roadmap, focus on several goals in one go. The major parts include the time horizon (Current, Near Term, Future, etc.), objectives (reduce churn, revenue, etc.), and the scope of what to be done. Additionally, you may specify product areas like sales, marketing, discover, and so on.
- Feature-based
A feature-based roadmap resembles a backlog. Both provide lower-level detail. In this case, a feature acts as a key point for planning. Benefits include higher user-orientation and increased flexibility for engineering decision making. At the same time, the roadmap targets a narrow group of stakeholders. It might look like this:
Product roadmap metrics
You need to pick specific success metrics to estimate the progress of your workflow. But, do not confuse them with product metrics. The latter measure the critical accomplishments within the product development only. Roadmap metrics allow you to estimate the efficiency of your operation. They stretch across the product strategy and vision. Let’s take a quick look at some agile key performance indicators:
Velocity
This metric defines the scope of work accomplished within a sprint.Sprint/release burndown
It defines the leftover scope of work before the end of a sprint or a release.Cycle time
This metric defines time expenses on a task or feature.Cumulative flow
Cumulative flow is usually a diagram of tasks distribution at different stages.Flow efficiency
This metric contributes to the one above. Flow efficiency shows the distribution of time between actual work and standby periods.Code-centric metrics
These metrics allow you to measure code quality.Code coverage shows the number of executed code lines during automated testing. The higher, the better.
Code complexity estimates the code maintainability and risks of bugs during tests.
Code churn is a chart visualization of code modifications. It shows added, removed, or changed code lines at different stages.
Customization
Check out the following product roadmap best practices to customize your plan:
Color-coding
Use different colors to categorize tasks by priority or status. This approach lets you increase the informational density of the roadmap. Readability also goes up.Progress bars
Use bars of different length to display the progress of each task. For example, a task at the outset can have a short progress bar. It will stretch according to the level of task completion.Arrows → and lines ─
Use arrows and lines to display interrelations or dependencies among tasks. Use a dotted vertical line in the roadmap to display the current point of time.Diamonds ♦ or rhombs ⋄
Use diamonds or rhombic symbols to pinpoint product roadmap milestones. Diamond is a traditional sign for Gantt charts to indicate key project checkpoints.
Who is involved in creating a product roadmap?
The product roadmap is not a one-person job. It requires teamwork or even the collaboration of several teams. A product manager puts the information together in the final roadmap. He or she is also a liaison with stakeholders contributing to roadmap creation. A list of stakeholders may include engineers, designers, marketing & sales specialists, and others. Data provided by them is crucial for setting priorities and deadlines.
With a roadmap, the product manager directs the pipeline. So, this document must be insightful and clearly defined. In some cases, the manager can go by several roadmaps of different purposes. For example, a separate product roadmap can be built for external stakeholders.
Working with a product roadmap
Once your roadmap is ready, things have just started out. This document requires recurrent attention and time costs to work with. So, we decided to share our hands-on experience of the product roadmap development process.
We do roadmapping if:
There is some area with a number of problems
A new client project is to be launched
We start with product inception and use the BRIDGeS framework throughout this stage. BRIDGeS is a versatile ideation and decision-making framework that allows for multi-context analysis. To utilize it, we organize sessions (usually virtual) where team members collaborate on coming up with solutions to identified problems.
At the end of a BRIDGeS session, we have a list of nested epics and tasks ready to be transformed into a roadmap. We then transfer this information into our preferred tracking tools: Jira or Trello. BRIDGeS is something we have used for every single one of our products and we find it especially helpful for navigating the transition from idea generation to roadmapping. Compared to creating roadmap tasks from scratch, BRIDGeS should save your team lots of time and energy during the early stages of product development planning.
Since the product roadmap is a living document, we update the data at iteration planning meetings (IPMs). These are recurrent events that usually take place once a week. That’s how a regular IPM flow looks:
checking the current state of tasks
reviewing the requirements and/or the implementation plan of tasks
making corresponding updates
rechecking prioritization
Today, you can benefit from numerous roadmapping tools that offer you ready-to-go templates. At the same time, you are free to tailor a product roadmap on your own using Google Sheets or the old but reliable Excel. Let’s check out the most reputable options.
Product roadmap tools
Aha!
Aha! is a company that aims to create a world of lovable software. So, they do their best to make people enjoy the entire lifecycle of a product. Roadmapping is a part of their services. Aha! offers six visual templates for writing a product roadmap. Besides, you can integrate it with 30+ development and support tools like Slack and Trello.
ProductPlan
ProductPlan is in the toolbox of many great teams including Microsoft and HubSpot. With this tool, you can build and share your roadmap with a few clicks. A plethora of ready-to-use templates are available for versatile purposes. Integration support is also huge and includes GitHub, Jira, and so on.
Roadmunk
Meet another powerful tool for visualizing strategy through roadmapping. Product teams of Amazon, Mastercard, and many more companies use Roadmunk. The tool offers 35+ ready-to-go templates. You can find product, agile, portfolio and other types of roadmaps.
Jira
This software development tool is quite renowned among agile teams. Jira provides Scrum and Kanban boards to organize the pipeline. Roadmapping in Jira is available through a built-in feature in next-gen projects. It is not as sophisticated as the tools above. At the same time, it can be a perfect supplement to your project activities in Jira.
Trello
Trello also has roadmapping capabilities. For example, we use this tool for planning within the Mailtrap project. In our case, it is an advanced product roadmap Kanban with a top-to-bottom prioritization of tasks. If you prefer the Gantt chart view, you can use the Elegantt add-on. Trello provides many customization options via custom fields, power-ups, and other add-ons.
This is a short list of web-based solutions. Among others, we would also recommend Smartsheet and Airtable to power planning activities.
Michael Porter, one of the founders of Monitor Deloitte (former Monitor Group), asserted:
The essence of strategy is choosing what not to do.
First and foremost, your product roadmap must lead to the key goal of your product strategy. That’s the path to success, and we wish you the best in achieving it with your product.
Thanks for reading this article, originally posted on Railsware's blog. Let me know what you think!