You’re Probably Getting Product Management Roadmaps Wrong

Though most Product Managers still use them in their day-to-day, there is heated discussion among Product thought leaders around the right way to deploy Product Roadmaps.

Why are Product Roadmaps getting so much heat? It’s because they exemplify a larger debate on what the role of a Product Manager should be. Questions surrounding them—should Product Roadmaps be a list of features and timelines? Or should they be based on vision and outcome? Should they exist at all?—are not just a fight over a specific Product Management framework. They’re a continuation of the Waterfall vs Agile debate, and show growing concern that Product Roadmaps have been co-opted by “evil” Waterfall processes. Have they?

Well, kind of. But there’s still hope. You heard it here first! Product Roadmaps are not a lost cause! They’re just misunderstood. Let’s demystify what Product Roadmaps are, how they’ve been misused, and how we can course-correct.  

What is a Product Roadmap?

highway stretching into distance in the desert

A roadmap is not an actual map, but it acts like a map in that it helps you define where you are, where you’d like to go, and how to get there. Roadmapping is not timetabling. It’s about aligning expectations and communicating the strategic vision of your product.

This is the official definition of Product Roadmaps in the book “Product Roadmaps” by Bruce McCarthy:

“A Product Roadmap describes how you intend to achieve your Product Vision. It focuses on the value you propose to deliver to your customer and your organization in order to rally support and coordinate effort among stakeholders… It’s about creating a shared understanding of where you’re going and why [emphasis added].”

The Wrong Way to Do Product Roadmaps

Imagine you’re going on a roadtrip with friends. You get in the car with an idea of how the trip is going to go: doing Route 66, hitting the top US national parks, driving from Canada to Argentina.  A vision, if you will. But you don’t know every last detail: the rest stops, detours, and flat tires.

The debate around roadmaps comes from exactly this. Product Managers make highly detailed roadmaps, and stakeholders and leadership then hold them to these roadmaps as if they’re set in stone. 

Going back to the roadtrip, it’s as if you wrote out a list of potential restaurants and meals to try, only to have your friend get mad at you for eating a salad at Jimmy’s Roadside Diner instead of a sandwich like you said. Who cares? As long as you still make it to Vegas, it’s all good.

a close-up of a sandwich against a white background. The sandwich is on ciabatta bread with tomatoes, cheese, and leafy greens

Roadmaps are misunderstood as being about deadlines, features, and tasks, but they’re actually about vision and milestones. A roadmap is not a promise, precisely because a vision is not a promise. It’s a direction. 

But many stakeholders take Product Roadmaps as promises and suggestion boxes. They hold Product Managers to the roadmap timeline, while simultaneously force-feeding them feature suggestions. This is how the roadmap becomes a release plan, and how your Product Team becomes a feature factory. 

A roadtrip like this would be all sandwiches, no Vegas. It doesn’t even matter if you make it to Vegas, as long as you ate as many sandwiches as you could on the way to…wherever you end up. To top it off, your family and friends keep calling with sandwich suggestions, and insist you drive out of your way to try them. Now you’re in Canada, and everyone has a stomach ache.  

Lack of focus on vision means your Product Team won’t effectively solve business or customer problems, no matter how hard you work. Churning out features and hitting deadlines without direction means your product and company will just end up…wherever. 

The Right Way to Do Product Roadmaps

“Your job is not to prioritize and document feature requests. Your job is to deliver a product that is valuable, usable and feasible.”

Marty Cagan

Product Managers who want to reclaim Product Roadmaps have to be ready to push back against the long history of them being misused as Project Management tools. Here are some ideas on how:

The Outcome-Based Product Roadmap

There have been various attempts to fight against the flood of rigid timelines and never-ending feature requests. From opportunity solution trees to OKRs, proposed alternatives to roadmaps all have one thing in common: they focus on outcome over output.

Outcome-based Product Roadmaps integrate this into roadmaps. They start with the Product Vision and work down to the specific items that will see this vision through. These items can be delivery-based (features) or discovery-based (experiments). 

A chart showing the path from product vision, to objectives, to key results,, to opportunities, to ideas, to solutions, to potential features and experiments
Product Vision > Objective > Measurable outcome of the initiative

A Product Roadmap like this isn’t set in stone. It doesn’t make any promises on what it will deliver. It’s more of a way to communicate hypotheses and come up with starting-point actions that move towards the vision, uncovering what the Product Team will work on to find new product opportunities and getting to the core why behind potential features.

If you’re curious about how an Outcome-Based Product Roadmap looks in action, check out our Product Roadmap Template, where we cover 4 different types of Product Roadmaps.

Cancel Timelines, Use Time Horizons

Timelines and deadlines are important, but they’re not the job of a Product Roadmap, and enforcing them isn’t the job of the Product Manager. 

This isn’t to say that roadmaps shouldn’t include any mention of time. Timeframes provide a general outline, which can be helpful to situate the project in reality. But instead of creating deadlines and clinging tightly to them, Outcome-Based Product Roadmaps use time horizons instead.

Time horizons cover current, near-term, and future plans. This is also known as the Now, Next, Later framework:

  • Now: 1-2 months
  • Next: 3-6 months
  • Later: 6+ months 
example of an outcome-based roadmap

Your roadmap will be more detailed around Now, and become increasingly fuzzy as you move into later. Remember, a Product Roadmap is about direction, not commitment. 

You’ll notice in the example that the goals are broad, with little instruction on exact steps to get there. By focusing on the larger strategic objectives of a business, giving a loose timeframe, and setting your Product Team loose, you let them be problem-solvers instead of feature robots.  They know the big-picture goals, and can come up with the best solutions on how to reach them.

When your team has used the roadmap to better define the product and requirements, that’s when you meet with engineers, design, and Project Management to set concrete dates and timeline—in a document completely separate from the Product Roadmap.

Death of Feature Roadmaps?

At this point, you might be thinking, “But wait, I use Feature Roadmaps all the time! Are they really that bad?” Yes, and no.

They aren’t “bad” per se, but they’re dangerous because more often than they lead to miscommunication. Feature Roadmaps can create value, but only at the end of discovery, and only if you make it clear to stakeholders that it’s a vision map, not a to-do list.

As their name would imply, Feature Roadmaps are feature-focused, not outcome-focused. They often jump to the solution without fully going through the Product discovery process, resulting in features that don’t move the needle towards meeting customer or business needs.

There is a time and a place to communicate features, and that’s when you fully understand the problem that you’re solving. Unfortunately, however, many treat Feature Roadmaps as to-do lists; all of the items that need to be delivered by a certain date (the epitome of what all the nay-sayers hate about Product Roadmaps). When your team and stakeholders see a list of features, it’s only natural that they’re used and interpreted as a project plan. 

Tl;dr: Feel free to continue using Feature Roadmaps where appropriate, but be aware of their limitations and downsides.

Can Communication Save the Roadmap?

Roadmaps can be valuable tools to 1) align the Product Team with company goals, and 2) provide engineers and designers structure and goals without telling them exactly what to do.

But because there is such widespread misunderstanding and misuse of Product Roadmaps, it’s tempting to ditch them entirely. Even if we move away from Feature Roadmaps to Outcome-Based Roadmaps, and from timelines to time horizons, old habits die hard. 

The answer is communication, recommunication, and communication again. And remember, there are two sides to communication; It’s the responsibility of the Product Manager to talk to stakeholders, and it’s the responsibility of stakeholders to listen. The message: Product Roadmaps aren’t to-do lists, and timeframes aren’t set in stone.

PMs also have to take into account that roadmaps are flexible. Each time you update the roadmap, make sure to update stakeholder expectations. It can help to put the roadmap in a place where all relevant stakeholders can easily access it. 

Make the objectives as simple and clear as possible, and communicate how you’re defining these objectives. Are they outcome-led? Experiment-led? What is the goal you’re working towards, and what does success look like?

These practices can help us reclaim Product Roadmaps and consistently communicate their proper usage to stakeholders, leaders, and other Product People so they can continue to be powerful vision-setting and alignment tools. 

Enjoyed the article? You may like this too: