This blog post discusses what an agile product roadmap is. It covers the information such a roadmap should contain, the benefits it provides, when it makes sense to employ a roadmap, how the product roadmap and the product backlog relate, and who should own the product roadmap.
What is an Agile Product Roadmap?
A product roadmap is a high-level plan that describes how the product is likely to grow. It allows you to express where you want to take your product, and why it’s worthwhile investing in it. An agile product roadmap also facilitates learning and change. A great way to achieve these objectives is to employ a goal-oriented roadmap – a roadmap based on goals rather than dominated by many features.
Here is a sample agile product roadmap that shows the anticipated development of a dance game app for kids:
The roadmap above states the date, the name, the goal, the key feature, and the metrics for each product version. It is a goal-oriented product roadmap, and it applies the GO roadmap template, which is explained in more detail in my post “The GO Product Roadmap”.
The benefit of a goal-oriented roadmap is that it shifts the conversation from arguing over features to agreeing on shared goals. This mitigates the conflict between viewing roadmap features as commitments and agile teams who only commit for next few weeks.
What Benefits does a Product Roadmap Provide?
A product roadmap can provide the following benefits:
- Provides a continuity of purpose and communicates how you see the product develop over the coming months.
- Facilitates stakeholder collaboration and helps the individuals understand how they can contribute to make the product a success.
- Helps with prioritisation; allows you to state if and when a benefit will be provided or a feature implemented.
- Unburdens the product backlog; you can focus the backlog on the next major release / product version, as I explain in more detail below.
- Helps acquire a budget by stating the benefits the product is likely to create.
- Supports portfolio management and makes it easier to coordinate related products.
When should You Use a Product Roadmap?
I usually create a product roadmap once I can confidently look beyond the next major release. If you cannot look further, then do not employ a roadmap! What’s more, I want to ensure that the assumptions about the target group, the needs to be addressed, and key aspects of the business model have been validated, as the picture below illustrates:
In the picture above, the market and business model assumptions are captured on a Product Vision Board. But you can also use the Business Model Canvas or Lean Canvas to state and validate your ideas. While they are helpful tools, they not tell us how the strategy will be executed. This is where the product roadmap comes in.
Using a product roadmap can benefit your product backlog . Here is why: As the roadmap takes care of the strategic product planning aspects, it frees the canvas/backlog to focus on the tactical work, as the picture below illustrates.
Say you release a new product version every three months. I would then suggest that your product roadmap should capture the next four major releases, while your Product Canvas or product backlog focuses on creating the next product version.
The following table summaries the differences between the product roadmap and the product backlog:
|Product Roadmap||Strategic product planning||Major releases with goals or benefits||About 12 months||At least once per quarter|
|Product Backlog||Product development||Epics, user stories, and other artefacts||About three months||At least once per sprint|
Who Owns the Product Roadmap?
As the product roadmap captures decisions about the product’s futures, the individual responsible for the product success should own the roadmap. In an agile context, the product owner should hence manage the product roadmap. The team members and stakeholders contribute, as the following picture suggests.
Having one person in charge of the product roadmap and the product backlog unites the strategic and the tactical product planning aspects, and establishes clear authority and responsibility.
This post was last updated on 13 February 2017.