Product Roadmaps: What Are They Good For?

A Few Things, Actually--So How Can We Build Good Ones

It may seem nostalgic or retro, but there was a time when we actually had to use roadmaps to get to places when driving. Especially when taking road trips. You’d have to unfold a massive map, find where you were, and then trace out the roads to get to your destination. No GPS or navigation, except for your co-pilot handling the map.

Those were much tougher days, and getting lost was much easier. Which is why every car always had a road map. You might not need it, but just in case.

Fortunately, now many of us have GPS available whenever we need with a few taps. But the idea of a roadmap is still relatively similar—directions and guidance for getting where you’re going.

---

A few years ago, I wrote an article about product roadmaps called Product Roadmaps: Love, Hate, and Hate.

In it, I talked about unaliving product roadmaps because of the problems they create. Not everything about product roadmaps is bad, but they are often misunderstood, misinterpreted, or misused.

So I suggested ending them.

Not really, though, because they are important. We can’t get rid of roadmaps, both on road trips and in our products. But we need to do a better job understanding the principles of a roadmap, what inputs we need to create one, and then its ultimate use.

What is A Roadmap?

A product roadmap is a visual representation of our product prioritization and strategy. So we need few inputs before we can create a good roadmap, along with some guiding principles.

Principles:

• A roadmap is not a project plan, it is a strategic document

• A roadmap isn’t a list of features, it is outcomes we want to achieve

• A roadmap is a tool for communication and alignment

• A roadmap will change

These are key principles for creating product roadmaps, along with using roadmaps in our product teams, our organizations, and with our customers.

Inputs:

Before we can create a roadmap, we need some key inputs that will inform our product roadmap.

Vision and Strategy

We need to start with a product vision and strategy.

If we were taking a road trip, using our old school roadmap discussed above, it would only be helpful to us if we knew our destination. Otherwise, the map just shows us everything around. We need to know where we’re going in order to determine how we’re going to get there.

For our products, we need to understand where we’re going if we’re going to create a roadmap to get there. This vision is the destination we want to get to and it should guide everything we’re doing on the roadmap in order to achieve our goals. The roadmap is part of our strategy to achieve the vision.

Objectives and Prioritization

Next, we need to prioritize the biggest problems we’re going to tackle.

Prioritization needs to be more than just stack-ranking priorities, or using a value-to-effort matrix. It is a cycle of understanding, visualizing, prioritizing, and aligning. I wrote about this recently as well.

Product Prioritization

Once we prioritize, we can put our priorities into our roadmap as objectives we’re trying to achieve, along with the execution/features we will use to achieve those objectives and outcomes.

Objectives are a critical part of our roadmap. If we go back to our principles, a roadmap is strategic and not a simple project plan. It isn’t a list of prioritized features, but need to focus on why we’re working on those features and the outcomes we hope to achieve with them.

Timeline and Execution

Understanding that this isn’t the project plan, we can create the right timeline for our roadmap.

At a high level, our timeline could be Now, Next, Later. And we could put our prioritized objectives and features into each of those categories.

As we do more research, we could group objectives into months or quarters, being more specific in the immediate future and more general as we get further out.

It is critical as we assess our timelines and execution that we don’t fall into the trap of creating a project plan out of our roadmap. Project plans are great, and you should have one. But it shouldn’t be your roadmap.

Outcomes:

Once we’ve gathered and assessed our inputs, we can put it all together into a roadmap.

A product roadmap can take many forms. If you’re just starting out, it may be as simple as slides or a document or a Google sheet. As you and your business grow, there are a number of software tools tailored for product roadmaps. I’ve tried many of them, and they all offer some great functionality with specific nuances that may be important for your team.

Regardless of the form your roadmap takes, you’ll be using it primarily to drive some key outcomes:

Communication

Once we’ve created our roadmap, we can then use it to communicate our priorities and how they align with our overall strategy and vision.

Communication is key.

We can get feedback, generate discussion, and use this document as a tool for guiding what we do and re-prioritizing as we get new information.

Alignment

We can also use our roadmap as an alignment tool.

Every product and company has many stakeholders, including (but not limited to) executives, marketing, sales, support, legal, and other product teams.

So we can use our roadmap to align all of our groups and stakeholders around the vision, the strategy, and how we’ve prioritized our upcoming work.

Once we’ve aligned, we can work through dependencies, coordinate with marketing, sales, support and other teams for the timing of launches and other communication, and prepare our organization for what is coming up.

---

Product roadmaps are a critical part of any product and organization. If you’re just operating out of Jira, delivering features, with only a rough idea of why, then you may be missing the opportunity to really deliver the best value to your company and users.

A roadmap won’t fix everything (and is often the source of its own problems), but having a product vision and strategy that you can communicate, prioritize against, and ultimately deliver on through your roadmap, will make you a much better product manager and a better product organization.