What is a Product Roadmap?

Audio version

Listen to this article below.

When I was still a kid, I was always so excited to sit in the front passenger seat on holiday trips. You see, there were no navigation devices yet, and thus we had a physical roadmap. My dad frequently knew the route from memory, but I was eager to follow along on the map (and point out when we could find a quicker or alternative route).

My excitement for maps has not gone away. It's not coincidental that I'm currently writing about roadmaps in another, similar, sense—product roadmaps.

In general, the power of a map is to help you get to a destination. But how we create and use product roadmaps is essential. It is a process that is both creative and analytical.

In this series, I aim to guide you through everything you need to know about creating the ultimate product roadmap. In this first installment, I aim to explain what a product roadmap is and why it's such a great tool.

What is the purpose of a product roadmap?

Let me first tell you what I feel is a good definition of a Product Roadmap, which will help us frame the rest of the points in this guide.

"A product roadmap is a high-level visual summary that maps out the vision and direction of your product offering." - ProductPlan

We're going to break down the definition step by step, so we understand what it entails.

"high-level"‍

This means we don't go into the details of a product vision too much (that's what backlogs are for). We need the roadmap to stay on a strategic level where we can use it to set the course over the long term. To illustrate: think about a ship sailing to some destination. A captain on the vessel needs to look out over the horizon for direction. In contrast, an engineer on the same boat takes care of the machines in the engine room: both necessary for the end goal, but very different levels of focus.

"visual"‍

This means the product roadmap, like a land roadmap, can be understood without needing to read it (apart from titles, notes, names, etc.). Visual representation helps make the roadmap easier and quicker to understand, which is necessary to get buy-in from everyone involved. It helps you to "sell" the vision.

"summary"‍

This is similar in the "high-level" part we saw earlier. (Not focus on all the details.) But it does drive home the point that the roadmap should simplify, but definitely not leave out critical parts of the vision. Doing this is hard, especially when a product is big. Note, summarizing is a continuous process.

"vision"‍

This means the "why" of a product. Why create the product in the first place? What goal does it have? What is the value proposition for users? What is the incentive for the business to create this product? Tip, don't spend a lot of time creating a product roadmap before your vision is crystal clear.

"direction"‍

This means the execution part of getting to a finished product. It is "how" you go from nothing to providing the value intended. Do I need to say this is important? Well, yes, it is; it is essential. In the execution plan, you find most detail (and struggles) while creating and updating the product roadmap. After you formed a product vision (hopefully in line with your customers and your company!), most stakeholders don't sway from that idea. The route to that goal, however, is a bumpy and complicated road. (I'm almost getting ahead of myself in wanting to talk more about this here, but there will be multiple sections where we'll get into the details of this!)

"product offering"‍

This means "what" you'll eventually end up creating—the finished product. The whole reason you create a product roadmap is to offer a valuable product to the end-user, your customer.

An interesting aside. Maybe you're already familiar with the last three parts from the definition (vision, direction, and product offering) but under different wording. Simon Sinek talks about the "why, how, and what" (vision, direction, and product offering, respectively). He calls it the "Golden Circle" by his book with the same name.

What does a product roadmap look like?

A product roadmap can take many forms, feature-based, goal-based, time based, release-based, and a few more. But good roadmaps have a few things in common.

They are timed based (be it specific dates or timelines).
They have more detail for near term (higher priority) items than for later (lower priority) items.
They have 'themes' as the highest level (like "increase customer retention for yearly subscribers"), not features.

Here's an example of a roadmap (source)

In the next article, I will walk you through the details of an example product roadmap. As well as listing the different types of product roadmaps that are possible to make. First I'll tell you a bit more about how you can use your roadmap.

How can you use a product roadmap?

Ok, so now you know what a product roadmap is supposed to do and what it looks like. Right? Well, on a high level, yes. But the utilization of a product roadmap becomes even more evident in the specific cases you use it.

These are all about people, social dynamics, collaboration, and communication. You can use a product roadmap

as a reference document for the (Scrum )team.
to get stakeholder alignment.
to provide options for planning and conversation.
to prevent someone from 'hijacking' your sprints.
to tell a story to your customers.

These five uses all come down to the most important reason for creating a product roadmap. To set the narrative of your product vision and execution.

A Product Roadmap is a narrative tool.

With a product roadmap you can tell a story of intent. The intent to build a product towards a certain goal. This narrative is essential to get others to work with you in creating great products.

There is one crucial point I want to drive home. A product roadmap is a living document. The things you plan are not set in stone. The product you're building is undergoing iteration upon iteration. Thus your roadmap should reflect the latest findings and details, especially in the age of Agile and Lean (software) development.

Closing thoughts

Hopefully, you're now familiar with the idea of what a product roadmap is, why you should use one, and what it looks like.

If you have any questions, thoughts, or feel something is missing, please do shoot me a message on Twitter.

Bonus!

Say you're building a product, be it software or hardware (or innovative alien technology), you may need a product roadmap. Why? It helps you set out the vision, strategy, and goals for what you're creating.

It doesn't matter if you're working on your startup as a solo founder or work in an enterprise as a product manager, business analyst, or project manager. Yes, the detail and format may change somewhat depending on where and how you work. I mean, it could be that you work in an Agile environment or are the decision-maker, or maybe you need stakeholder 'buy-in' from lots of people. No matter, a good product roadmap helps a ton.

In the list I made below, you can review if you took into account some crucial points.

So without further ado, I present to you the 'Epic Product Roadmap Checklist!'

The Checklist

Do you really know what the audience of your product needs?
Make sure the strategy for your product is correct before spending time defining features and metrics.
Don't fear to say no (in a kind way) if stakeholders want to push in irrelevant features.
Don't try to put everything in the roadmap. Remember, you still have a product backlog for detailed user stories.
Did you get buy-in from everyone involved? Development team, marketing, sales, sponsors, etc.? Involve them in the creation. It is not a one-man-show.
Is the timeframe for the milestones realistic? Not too long, not too short.
Make sure it is clear what you prioritize on. Time, Budget, or Goal.
Are your users ready for the release schedules? Is the cadence steady and right for them?
Remember, goals > features.
How does the product(roadmap) fit in with other products and their release schedules?
Do ask others for input. You did that, right.
Determine and update the metrics you track for measuring your goals.
Tell a story through the roadmap that is both convincing and achievable.
Is the roadmap laid out contextually? I.e., communicate every important decision that you made in creating the roadmap.
To get better buy-in, did you address doubts of influential stakeholders beforehand?
Did you gather all requirements?
Are all requirements cut up into manageable and logic parts?
Don't tell others HOW to do the work of what they need to do (in the roadmap). Only show WHY and WHAT.
Have you made a good business case for everything on the roadmap? Is the value clear? Is it measurable?
Don't go overboard with the details when the roadmap is for a (small) startup. On the other hand, a place to do this is in enterprise-grade businesses.
Don't hide unknown-unknowns. Keep researching until you at least have the potential scope failure of a (sub)product.
Take into account what your teammates can achieve. Don't provide unrealistic milestones.
Document the process of how you came to creating the roadmap.
ABU. Always Be Updating (your team members and stakeholders). Don't let people work with old info.
Don't surprise stakeholders during a presentation. They should have been up to speed before you present your roadmap.
Talk about details with (for example) the engineering team, so that you can better schedule feature releases.
Do you know what is essential for the stakeholders? I.e., what you need to prioritize?
Watch out for big clients swaying feature priorities!
Don't write too much. Only the minimum needed to transfer the message.
Don't try to predict the details of everything in the product roadmap. Only go into super detail for the first 10% - 20% of the roadmap.
Be honest. Don't say things that you're unsure of.
Use good tools for both creating and presenting your roadmap.
Do your best storytelling in all communication.
Add both short-term and long-term goals in the roadmap. It keeps a steady cadence of wins.
Technical (and security) debt is real. Do make time for it in the roadmap.
When presenting your roadmap, make clear what the intention and goal of the presentation are.
When creating your roadmap, take into account who is consuming the document(s). Executives likely need a different view than a Scrum team.
Build your roadmap based on objective findings, not your gut feeling.
Present your roadmap with confidence, verbally, non-verbally, written. Any way you can.
Make sure you talked to all relevant stakeholders before finalizing your roadmap.

Software list

I also thought of listing some product roadmap tools. Some specifically meant for roadmaps, others that you can bend to the use-case somewhat (which are mostly free).

(Oh, and no, these are not affiliate links.)

In no particular order: