Thanks to Simon Waldman, ex Amazon, Guardian & Sky for his contribution to this post.
Roadmaps are a core product management tool. They provide visibility on what product teams are up to in an easily digestible format. Done well, they clearly express direction, ambition and progress. However, roadmaps are also a minefield, both because there are so many different formats favored by different people, and because drafted and executed poorly they burn credibility throughout an organization.
This guide provides five product roadmap templates, as well as practical advice on how to use roadmaps to influence and collaborate with those around you.
What are product roadmaps for?
Roadmaps are a communication tool for engaging stakeholders in what you’re up to as a product team. Everyone wants visibility into what your plans are, but why will vary from stakeholder to stakeholder:
- Execs - want to understand what the product strategy is, whether it’s aligned with company strategy, and how well teams can deliver on it
- Marketing and Sales - want to know what features they can and should tell customers about, and which features will assist them to hit revenue goals
- Customer Support - need to know how the platform is changing in case of customer queries, and whether they need to update FAQs or internal processes to take this into account
- Engineers - want to know what they are working on, what platform changes impact their architecture, and of any dependencies they need to be aware of
Broadly there are two levels of detail that people will want visibility on. You don’t want to mix these:
- Strategic - provides 12+ months of visibility, and illustrates the direction and ambition of the product team. At this level you are showing the main themes that will be tackled, and balance of work between them, but not specific features or timelines.
- Tactical - provides up to 3 months visibility on specific features that will be released, with clear timelines that other teams can rely on. Here you can give more certainty on outputs or outcomes, but not both.
Both cases allow people to coordinate their own teams and take action, so product work is tightly integrated into wider company activity. This is critical to make product work successful, and you should see roadmaps as a tool to magnify the value created by features more than admin keeping stakeholders happy.
Good Roadmap / Bad Roadmap
People get very opinionated about what format of roadmap is the best, and there are a lot of options to choose from. Just remember that roadmaps are communication tools. The best format for you will depend on your context, and must be adapted to the situation you’re in. When you’re thinking about the right template for you, consider:
- Who is the audience for your roadmap?
- What do they care about and need to know?
- What do you need from them to be successful?
- Illustrate the product strategy
- Follow on from vision and clarity about what you want to achieve
- Build credibility by showing that product can keep commitments
- Generate buy-in, by showing product is aligned on the most important problems
- Articulate how outputs should generate the desired outcomes
- Vary in level of detail and scope depending on the audience
- Are clear about what is NOT going to get done
- Don’t follow a strategy, and are just a pick-n-mix of features to do
- Start the planning process, instead of finishing it
- Create a false sense of accuracy about what will be built, and when it will be shipped
- Destroy credibility of product teams as a result of this false accuracy
- Focus teams on outputs that are unattached to outcomes
- Are never rarely updated and frequently out-of-date
This article is for paid subscribers
Get access to all our articles, templates and guides by upgrading to a paid subscription