15 Best Practices for Product Roadmaps

Product Roadmaps are a central part of every product person’s life: from product managers, to engineers to experienced leaders. Being so central it’s essential to get them right, so this article brings together a collection of product roadmap best practices.

“The secret to success is to do the common things uncommonly well.” – John D. Rockefeller

So let’s get right into the 15 best practices for product roadmaps. 

#1 Get vision and strategy right before you roadmap

Product roadmaps are plans for executing on your vision and strategy. Vision and strategy will guide the roadmap and allow you to make real decisions. 

So, first things first. You need to have a clear vision and strategy before you can create product roadmaps that will be successful. Read up on Michael Porter, and Henry Mintzberg. Then, if you want to take your understanding of strategy even further pickup my favourite book (really could be called a tome) on the topic of strategy Strategy: A History.

You can’t use a roadmap in place of a strategy or vision and a roadmap isn’t your strategy. 

The following diagram puts this into some visual context:

#2 Realise your roadmap(s) are communication tools

The primary purpose of your product roadmaps are to communicate with others. Executives, engineers, your team, your customers, the market and more.

Your roadmaps on their own don’t deliver value for the business, but when they galvanise an organisation in a direction and facilitate deep discussion, they allow the organisation to deliver real value. 

Why do I say roadmaps plural? Let’s get onto the next product roadmap best practice.

#3 Have multiple roadmaps

If you accept that product roadmaps are primarily communication tools, then it naturally follows that you will want different roadmaps to communicate with different audiences most effectively.

At a minimum, John Carter – advisor to Amazon, Apple, Fitbit and others –  recommends every product manager or product team have at least three roadmaps:

1. A Strategic Roadmap – communicates product component of corporate strategy, incorporates P&L and shows relative performance gaps/positioning.
2. An Execution Roadmap – communicates detailed timing of releases, dependencies between initiatives, provides timing to engineering/marketing/sales.
3. A Sales Roadmap – communicates general timing of key releases, key outcomes/benefits being delivered and helps support sales efforts.

You may also want to add many more views of your roadmap, such as an external roadmap for your customers. The sky’s the limit here – add what you need to best communicate with who you need to communicate with.

#4 Choose roadmap items by outcome not feature

The best roadmap items focus the team and stakeholders on the outcome that needs to be delivered. Outcomes could be the benefit to the customer, revenue unlocked, the costs saved or the strategic value delivered. 

Where this all starts is how you name your roadmap items. This might seem pedantic, but a name, though seemingly trivial, sets the frame of people’s thinking and thus makes a huge difference to results.

#5 Carefully consider the right time frame for your roadmaps

The needs of different audiences, different situations and different organisations means that you need to carefully consider the right timeframes (if any) to show on your product roadmaps.

ProductPlan’s 2018 survey of 500 product professionals highlights how different teams, in different industries use different timeframes:

With most product roadmaps having timeframes of between 4 to 12 months: 

Make sure you spend some time thinking about the right time frame for your roadmaps. You might even decide that product roadmap best practice at your organisation, in the situation you are in, will be to have no timeframes. That’s OK, just think it through carefully.

#6 Review + update at an appropriate frequency

Now that you’ve considered your timeframe and seen how this needs to vary depending on your situation, you need to consider the appropriate frequency to update your roadmaps.

Many of the product roadmap tool companies and reading around the internet will tell you “update frequently!” as best practice. But, this is a trap. Frequent updates can create communication chaos. Some customers (like CIOs of large companies) can’t handle and do not want frequent changes to roadmaps. And, finally, frequent updates might be a sign that you don’t have a clear vision.

The lesson in all this is that best practice is to make up your own mind about an appropriate frequency for making product roadmap updates. It might be right that your team does it monthly, you might need to be making it weekly right now but not 2 months from now. You may only want to update it quarterly. 

#7 Systems and processes lead to good roadmaps

Given the roadmaps themselves are tools for communication, you need to make sure you’re investing in systems and processes that ensure your roadmaps are communicated. 

This is almost a topic unto itself, so let’s just briefly summarise some of the processes you want to have in place:

1. A process for including and engaging the stakeholders that need to provide input in order to create the roadmap. 
2. Once you have your frequency set checkpoints (e.g. meetings), processes to make these reviews and updates happen systematically.
3. Processes for communicating the roadmap with stakeholders.

#8 Choose a fidelity/granularity based on outcome

This best practice is about looking at the outcomes your roadmap is delivering and choosing the fidelity for each item/outcome based on that. 

This is about considering each item and thinking about what you want to communicate with which audience rather than providing some generic and useless rule of thumb like “at item should be X weeks” or “an item should be X man days effort”.

In practice, this means you may have extremely technically simple items that take a week to do called out in flashing attention grabbing text on your roadmap up against longer running, chunkier initiatives because that small, simple task is of high importance to your audience (like your customers).

#9 Assign appropriate timelines to roadmap items 

Following on from the point above, your roadmap items need to have broad enough timeframes to allow flexibility but enough specificity to help people be accountable. And it really depends on the roadmap item itself.

“The level of detail on your roadmap needs to leave room for innovation and agile responsiveness,” says Cliff Gilley, technologist and product manager of The Clever PM. 

This means paying attention to the outcome your roadmap item is aiming to deliver. Sometimes this will mean roadmap items that don’t really have set finish dates (e.g. we can’t move on until we know this is delivered) or sometimes it might be a hard finish date because the market demands it by a date (e.g. their is a particular event like the end of the tax year). 

#10 Focus stakeholders with themes

People can only remember so much, they also have a lot more going on than thinking about your roadmap.

An effective way to communicate with your audience, capture their attention and get them aligned is through the use of themes. Developing themes that group together components of your roadmap can go a long way to making people productive and getting great results.

Examples of themes might be:

1. For the month of August we’re focus on Customer Activation and nothing else
2. This year is all about retention
3. We’re going to keep going with better serving the XYZ customer segment until we’ve got it right.

The wording of my example themes needs some work but hopefully you’ve understood my point.

#11 Your roadmap is not your backlog

A common trap teams fall into, especially those driven by engineering, is to use their backlog as a roadmap or create a roadmap that directly translates into a backlog.

Backlog items are usually features, bugs, design tasks, technical tasks and more. Backlogs necessarily need to be at a level of detail that someone can undertake and complete the task. And, if you’re running agile, you’ll already know that this shifts daily and weekly in order to do the right things – and so it should. 

This level of detail is at odds with the outcome focus that your product roadmap needs. It can also become overwhelming to your audiences, especially if your customers are businesses. 

#12 Avoid bug fixing and ‘necessary to do business’ items on your roadmap

Along a similar line, don’t put tasks that are just part of doing business into the roadmap. 

This means don’t put bug fixing in. Don’t put other tasks like interviewing, maintenance, user support in.

Sure, allow for the fact that it needs to happen when creating your delivery/execution roadmap but these don’t need to be items on the roadmap. 

#13 Don’t use roadmaps for research

While we’re covering what to avoid on roadmaps, customer research and similar tasks are not roadmap items. The output from research is the inputs into your roadmap, it’s only through research that you can know the outcome you’ll deliver.

If you’re being asked to roadmap customer research, scientific research or data analysis, then you really need to be using alternate planning methods like project plans (yes, I know they aren’t cool anymore) or other forms of budgeting and governance.

#14 Use data to inform your roadmap

You need to be able to support the items on your roadmap with data: market research, competitor research, customer insights, product analytics and more.

If you don’t have this information ready, then you might not be ready to finalise your roadmap or you might be setting yourself up for a bad outcome.

#15 Don’t worry about tooling

The question of tooling is almost always top of mind whenever I talk roadmaps. The problem is, people jump to the tool as the solution before they’ve walked through the other practices outlined above.

If you’re stressing about tooling when it comes to product roadmap best practices, then you’re probably stressing about the wrong thing.

I’ve personally seen highly effective product managers and development teams succeed with excel and powerpoint slides. I’ve equally seen highly ineffective teams fail with the best tools money can buy.

Get the other practices right, then choose what you can afford or enjoy using. Make sure you evaluate how effective it will help you be at applying these best practices.

---