Roadmaps vs backlogs: What’s the real difference and why does everyone keeps using these terms interchangeably when they mean different things?

Product roadmaps and backlogs serve different purposes, and using the terms interchangeably (or incorrectly) can lead to confusion and misalignment among the product team and the wider organization.

With that in mind, let’s tackle a few questions!

Summary of roadmaps vs backlogs comparison

• Understanding the difference between a product roadmap and a backlog is crucial for product managers.
• The purpose of a roadmap is to communicate direction, intention, and influence while remaining flexible throughout the product development process.
• A good roadmap tells a story, outlines the outcomes that a product team is looking to achieve, and the strategic moment when decisions will be made.
• On the other hand, the purpose of a backlog is to assess opportunities, run discovery on them, and use that evidence to implement solutions.
• It’s important to separate the product and development backlogs into two separate streams, allowing you to be dual-track.
• Instead of putting features on roadmaps, an outcome-based approach should be used to focus on the questions to be answered, not the final solutions.
• Product backlogs give you the opportunity to assess and understand problems further and allow the product team to be more discovery focused.

Everyone knows the difference between a roadmap and a backlog… right?

A few weeks back, a conversation started on Twitter about the difference between roadmaps and backlogs.

Before I continue writing this, I do want to say I am not here to point out who was wrong or right (I don’t believe in public shaming, that’s an ugly thing to do) – but the conversation did raise quite a bit of concern.

Too many product people quoted incorrect facts about what each artifact means, so I thought it’d be worth it to tackle the topic and clear some misunderstandings.

What is a roadmap?

The term “roadmap” is quite a convoluted term and tends to come with its own perception of what it means. This is generally because many people are familiar with timelines in product development, and attach the meaning to product roadmaps as well.

So first things first – roadmaps are not timelines.

A roadmap is a document of direction, intention, and influence. It helps product managers communicate the steps they are looking to take to reach the product vision and fulfill their strategy while remaining flexible in case there are any bumps on the road.

In addition, it helps product managers tell a story, that is, the story of where they’re heading and why. With a clear roadmap, one is able to bring others on board with how things are unfolding, and give more confidence and trust that you’re making the right decisions.

Many people like to put features on roadmaps to outline what they will be working on. I generally advise against this, as it’s important to remain flexible throughout the product development process.

Instead, I usually try to refocus the conversation from:

“Here are all the features we are going to build.”

….to

“These are the questions we’re looking to answer, and the ones we have more clarity on.”

Structure of a product roadmap

By now the idea of outcomes should be pretty clear.

However, focusing on outcomes doesn’t mean we let go of output – which is important to keep in mind!

What it does mean is that when approaching a new problem, we don’t set off with the solution (eg, we will build a Slack integration), but rather with a question about what the user need is: How can we better support team communication apps?

By asking those questions first and putting user value at the forefront, we’re able to better serve our market and build products that serve a purpose.

Now, next, later approach

When laying it all out on a roadmap, I like to use the Now, Next, Later approach.

• Now – Things we have committed resources to. These can be framed as solutions because, after all, you should know what you’re doing.
• Next – Things going into discovery or already in discovery.
• Later – Within the scope of the strategy, but no definition of what that might be yet.

As you can see, I like to write outcomes in the latter column in the form of questions. This enables the team to remove themselves from the solution and focus on what the problem is, while also removing any bias they might have.

But what about dates and timelines on a roadmap?

Contentious subject, I know. While many product managers are still using timelines, it’s important to keep in mind what you’re actually trying to communicate when you do so. Even more so, there is a distinct difference between timeline, deadline, and timing.

• Timeline: A timeline visual sequencing of chronological events, with start and end dates.
• Deadline: The due date for a project or event.
• Timing: In a product, timing is the strategic moment when you decide to look at something — be it starting discovery, or executing it.

Your roadmap should communicate timing (Why this, why now?).

Maybe at times, it will have to communicate deadlines (let’s be honest, we can’t always avoid those).

What your product roadmap shouldn’t be communicating is a timeline. Your roadmap is not a delivery plan, it is not a list of tasks to do, nor is it a list of features you will build.

Think of your roadmap as a list of potential questions that need to be answered. You can only answer them as you gather evidence, and once you have an answer, you can talk about it more openly.

Also not all those questions have to be answered, and some may get answered as you’re working on something else. It’s like playing a super exciting trivia game that requires lots of science and research, and you have to keep communicating with everyone about the information you’ve gathered.

With that, let’s move on.

What is a backlog?

Often people will refer to a backlog as a list of tasks that need to be completed. That’s true within reason, but let’s dig into that a bit further.

As product people, we often run discovery to understand problems further. As part of the process, we might decide whether a problem is worth solving or not, and move it through discovery, design, testing, and eventually an implementation process.

Check out how Susan Stavitzki, Senior PM at CarMax uses discovery.

Moving on, it’s usually a good idea to separate the product and development backlogs into two separate streams, allowing you to be a bit more dual-track.

That is, you have a discovery track, dedicated to understanding problems, and a development track, dedicated to implementing the solutions to those problems.

When an item lands on the product backlog, it does not immediately become a “task to do.” Instead, we should look at it as an opportunity to assess.

Not everything on your backlog will make it to development or even to the roadmap, and it’s up to you to gather evidence and make decisions about what happens to that opportunity.

On the other hand, a development backlog is a list of specific tasks or user stories that need to be completed to achieve a product goal or milestone. It is more detailed and granular than your product backlog, as you will have already done the research on what needs to be done and why. With a development backlog, you can more closely track progress and use a release plan to outline how work is coming along.

How do roadmaps and backlogs relate to each other?

Here’s the magic question.

I am going to give two statements that may sound somewhat contradictory, but stay with me here.

But first, let’s review:

• Roadmap = A high-level plan that outlines the direction of the product.
• Backlog = List of opportunities that will help you answer questions in your roadmap.

Your roadmap will distill into various ideas and opportunities in your backlog. On the roadmap level, you can absolutely show the ideas that are linked to the various problems you’re looking to solve to provide more context.

Not all items on your backlog will be on your roadmap. So if your roadmap is made up of backlog items, does that mean that all backlog items belong on the roadmap?

Absolutely not.

Your roadmap is a strategic document. You should really only use it to communicate strategic decisions you’re making. If there are opportunities in your backlog that don’t fit that requirement, you do not need to include them on your roadmap.

As an example, you might have a small improvement that is a great opportunity for your team to take on. It’s a quick win, low effort, but big enough impact that you’re willing to add some development effort into it (like making sure that all buttons fit the design system your team has put together.) An initiative like this does not need to be added to the roadmap unless it fits a larger strategic move to rebrand and redesign the product.

What about bugs? Do they go on your roadmap or the backlog?

Bugs should never appear on your roadmap. Again, your roadmap is for strategic items – it is not a delivery plan.

If there is a bug that requires a lot of time, people, and resources to fix – you and your engineering partner must make the decision together.

Either the bug must be fixed, or there is a larger strategic initiative at hand to rebuild that area of the product. If it is the latter, then it goes into your roadmap.

Conclusion

There you have it. I hope this brief overview shed some light on the main differences between a roadmap and a backlog.

The important part to remember is that the product you build must embrace a true vision and offer value.

If you’re looking to improve your product, Userpilot can help you get relevant insights from your users with contextual surveys and product usage data. That way you truly understand where the value is and can build your product roadmap to build a product your users will love.