7 examples of great product roadmaps

A product roadmap can be a powerful tool

A roadmap can communicate your vision for a product and align the organisation around this. Useful roadmaps give insight into the product’s objectives, timelines, and release plans, and should build the team’s understanding of the strategy, as well as their confidence in the product’s leadership.

The intention should not simply be to hit milestones or deadlines, which mainly serves to induce anxiety in the team. Where possible, a focus on specific dates should be minimised in favour of raising awareness of the bigger picture, creating interest and enthusiasm for the end goals, and inspiring teamwork and participation in these.

To go a step further, the aim should be to provide value to stakeholders at all ranks of the business. A roadmap can cater to a variety of your team members and wider stakeholders by showing how their unique needs will be satisfied, for example, by displaying how dependencies will be met.

These differing audiences may require alternative views of the roadmap, depending on the level of detail and variables that they’re interested in. Hence, as we’ll see later, it can pay dividends to adapt the format and style to be appropriate for each discipline and stakeholder type.

Practical actions to take before constructing the roadmap

Envision the why. You should clearly understand the outcomes your organisation wants to accomplish, and the overarching product strategy and themes. The outputs/actions on the roadmap should reflect this.

• Meet with the relevant stakeholders and cross-functional teams and provide them with early sighting of the work. Consider who should be consulted or just informed. Decide the best ways to present the detail to each cohort.
• Use software that allows you to keep it up to date (more on this later) as priorities inevitably evolve. A roadmap should not be a one-time document that is turned into a PDF after pressing save.
• Think about the most appropriate timeline for your roadmap (i.e., week 1, week2, week 3 etc., or now, next, later, etc., or short, medium, long term, etc.). Also consider the level of detail and granularity that the features and functionality on the roadmap should have. These will depend on your roadmap’s audience, time frames, and project objectives.

Which stakeholders are interested in which roadmap types?

As we’ve said, different formats of roadmaps will be better tailored for different stakeholders. Here are some ideas of which types of roadmaps are most appropriate for each type of stakeholder. This is not to suggest that, for instance, an executive would never be interested in a Kanban or sprint plan, but merely that they’re less likely to need to be sighted on this than other stakeholder groups

7 examples of great product roadmap formats

Features timeline roadmap

Perhaps the most traditional and well-known format for a roadmap, the features timeline can track feature progress against specific timeframes, deadlines, and milestones. The timeline should go along the X axis with teams on the vertical axis. This is well-aimed at an audience of technology and development teams, who will actually be delivering the product on the ground. Equally, if the features on the roadmap are mostly customer-facing (for example, they’re front-end development) then this can be appropriate for customers and customer-facing teams.

Objectives timeline roadmap

A high-level approach, the objectives timeline has the same X and Y axis as the features timeline but is purely meant to show business outcomes rather than outputs. This is ideal for senior executive teams or stakeholder management in larger organisations who want a broader view of the product direction and strategy. They do not want the zoomed-in details of individual features.

Release timeline roadmap

In some development environments, there is a sharp focus on the timing and contents of each software release. This is particularly common where there is heavy integration between backend components that may be managed by different teams. The release timeline can show every feature and perhaps every bug fix or piece of functionality (almost acting as a traditional release note) slated for a product’s version deployment. Each release version can be shown against a timeline on the X axis and the contents of each release on the board can be as high or low level as is suitable for the intended audience. Releases across the board can also be grouped based on the objectives or larger Epics or teams to which they are aligned.

Kanban roadmap

Another delivery-centred format that is best for the teams on the ground, a Kanban roadmap is designed to clearly categorise items and initiatives into simple groupings (such as backlog, planned, in progress, in testing, etc.). This allows near-term plans to be showcased and discussed without any commitment to specific dates, which is ideal for fast-paced work environments. It can be presented as a roadmap at first, then used as a working Kanban if this suits.

Now-Next-Later roadmap

Similar to a Kanban, this view displays the delivery items with an emphasis on the near-term and no deadlines set in stone. However, this articulates their priority rather than status. Functionality in the Now column is clearly the highest priority, while the Later items are for the longer term. A similar format is Must Have, Should Have, Could Have, Won’t Have. Additionally, the cards on the board can be further categorised by grouping them under the business objectives that they support and are most relevant to. This shows how the plans are comprehensively aligned to the organisation’s strategy. It is worth noting that a strong prioritisation process is required to keep this board up to date as the environment changes.

Sprint plan roadmap

Comparable to a Now-Next-Later, but with objects categorised under Sprints rather than priorities, a sprint plan is again delivery-focused and can be as granular as needed by you and your stakeholders. The owners and effort scores assigned to each object can also be shown. Swimlanes can provide further context and grouping.  A sprint plan is a useful vehicle for fixing the scope of each work sprint and illustrating the plan to an Agile product delivery team.

Transformation roadmap

This is a zoomed-out version of a roadmap that should interest the whole organisation, but particularly the leadership and executive stakeholders. It depicts the company’s long-term programme. Categories can be functional areas (finance, HR, sales, etc.), offerings (online, app, store presence, etc.) or even product features (training platform, account settings, photo editing, etc.). The text in each portion can be milestones, goals, KPIs, or even major events or releases. There is flexibility here, as long as a clear progression is shown from the current to the future state.

When it comes to creating these, steer away from the traditional formats, such as static spreadsheet roadmaps or boxes on a waterfall-style PowerPoint slide. Modern web-based software presents an easy way to manage your roadmaps like a pro. You can create them in various formats, work on them collaboratively, and export or import data with minimal fuss. See this article for a list of online roadmapping software options. These can truly bring your roadmap to life and allow you to capitalise on the opportunities that great product roadmaps offer.

Jacob Montgomery

Senior Consultant, Capgemini Invent

Jacob is a business analyst with 5 years of experience in digital transformation, having worked for a range of clients on both discovery and delivery projects.