1. What is a Product Roadmap?

When we think about ditching our timeline roadmap, we first need to start with a basic question – what is a product roadmap? 

A product roadmap is an artifact that communicates the strategy, by outlining the potential steps that could be taken to move towards the product vision. 

You’ll notice that this definition is pretty broad, and doesn’t really tell you exactly how a roadmap should look or be formatted. And that’s okay, because there are lots of ways to articulate a product strategy that would pass as a roadmap. It’s more important that it solves the problem of communicating the product strategy, than it conforming to a specific look and feel. 

The product roadmap is how the product team articulates their understanding of the strategy to other stakeholders in the business.

It’s not meant to be a detailed project planning document that maps out every tactic and move. It’s really more about making sure that everyone is pointing in the right direction and knows which way they are heading. 

A product roadmap is a way to prioritize problems, opportunities, and challenges.

Along those lines, it’s a tool for prioritizing problems. As a product person, your job is to gain an understanding of the key problems, opportunities and challenges that the business might face, and lay them out in a way that people in the team can see and start reacting to.

You use the roadmap to do this.

A product roadmap is a prototype for your strategy

This is why the roadmap can be thought of as just a prototype, but for your strategy. 

Prototyping is such a healthy activity. It’s a way of laying out your assumptions in a low effort way, and communicating them to others. It then allows you to check those assumptions with others, and make adjustments really quickly and easily, without having to expend a ton of effort or use up a lot of resources. This is why the Lean movement talks about prototyping so much.

When you go to build a new feature, you don’t run straight in with a fully designed interface that you put together from scratch and no input. 

You start with some basic sketches on a piece of paper or whiteboard. 

You take that sketch, and you show it to a colleague or a customer, and they give you some feedback. Maybe move that button here, or add some copy there. 

You throw out the first sketch and make a slightly better one, taking on board the feedback that you learned from, and you repeat until you’re reasonably sure you understand how the feature will solve the problems at hand. 

To begin with, your first iteration is pretty flimsy. It’s unlikely it solves the problem in the best possible way. But over time, with feedback and iteration, your prototypes of that solution become more and more robust – much more likely to solve the right problems.

Roadmapping can be similar.

Honestly, if you read this guide and started your first roadmap like this, you can be proud. It shouldn’t be pretty. It shouldn’t be slick.

What you’re really doing is saying: 

As a product person, I’ve listened to all the stakeholders around me, and I’ve heard a series of problems, and I’ve interpreted it as this. 

I think it means we should tackle this, then this, then this. What do you think?

Take these assumptions you’re making to a colleague, and check their opinion. If they agree, you’re on the right track. 

If they point out holes in the plan, then you can start to make adjustments. Maybe you need to add in new problems you hadn’t thought to capture, or change the order of things, or perhaps something you’d outlined as a problem actually isn’t a big deal and can be removed.
That first roadmap helps ground the conversation in real terms around what the business objectives are, and what sorts of initiatives might be undertaken to meet those objectives, and in what order. 

You might think it goes Problem A, Problem B, then Problem C, but your colleague might look at that and point out that you’ve entirely missed Problem D, and that it needs to be solved first. Well that’s really good you had the conversation now, and the roadmap helped you pull that information out, so you didn’t waste time solving the wrong sorts of problems.

The best product people use roadmapping as an opportunity to pull in insights from a wide range of stakeholders, to really understand what’s at play, and sense checks it with others to make sure they’re on the right track.

Roadmapping is a process

The act of roadmapping is more valuable than the roadmap itself. The details on roadmaps change, but by having roadmaps, it enables and encourages healthy and aligned conversations around what is important to the business and to the product strategy, and creates space for stakeholders to share their insights that are valuable in creating a robust strategy. Your roadmap itself will never be fixed in place, but the process in which you reach each iteration of your roadmap is where real value is gleaned.

It’s not your job to have all the answers.

It’s your job to ask the best questions.

One thing that product people should always remember, and it bears repeating for an exercise like this, is that it’s not your job to have all the answers.

As product people, you’re supposed to know less than your colleagues. They are the experts of their domain, whether it’s of the tech, the market, customer-facing challenges, or whatever.

Your job as a product person is to surround yourself with these experts and to ask the best questions. To tease out the expertise and to help the team make the best product decisions based on what you all collectively know. 

Guiding on a solid roadmapping process is one of the most impactful things you can do to set a strong company strategy, if you let the expertise of your team shine through. 

But what we’ve described here doesn’t sound like how many teams think about or show off their roadmap today. The next chapter in this guide talks about traditional product roadmaps – AKA the timeline roadmap – how it came into being, and why it’s no longer fit for purpose.