Your Roadmap Isn’t Really a Road Map

Roadmaps are a hotly debated topic these days. I regularly meet CPOs who try to ban this staple of product management altogether. This often worries and confuses the rest of the company. What’s wrong with roadmaps? Why can’t we just go on planning as we did since the 1970s? 

In this highly entertaining talk, Gojko Adzic, the creator of Impact Mapping, explains the issue with an insightful observation— what we call roadmaps may be roads, but they’re certainly not maps.

Here’s a road map:  

The map shows all the roads, paths, bridges, and intersections. It helps us find all possible routes between point A (where we are) and point B (where we want to be). 

This is what a classic roadmap looks like: 


This is a plan, and it shows just one specific path: Release 1→ Release 2 → Release 3 → Release 4 

There are no alternative routes, no plan B, just a clear and decisive way forward. When we commit to such a roadmap we implicitly say: 

  • These are the best ideas
  • This is the right order
  • This is the rough timeline 

Now, I totally understand why we would want to have such a plan. The company can prepare itself for the various launches: we can allocate resources, do Sales training, develop marketing materials, communicate to our customer, hire people, and so on. There’s also a psychological benefit: the roadmap creates a comforting sense of predictability — everyone knows what to expect. Some managers and business folk see the roadmap as a way to keep the product organization “accountable” — a sort of internal contract. 

Invariably, however, the roadmap fails badly at predicting the future. This is what typically happens: 

Projects take longer to ship than we expect (2-3 times is not unheard of), some projects are canceled, others are added out of the blue. Worse, when we ship, the results are often disappointing. In hindsight we can see we didn’t pick the best ideas. 

For many companies this is a sign of ineffective planning or of bad execution (in a very human way the people executing tend to think it’s the plan, while the planners tend to think it’s the execution). These companies often conclude they need to add more processes (OKRs, Scrum, SAFe…) and motivate people to work smarter and harder. It takes some introspection to realize the problem lies elsewhere — we face a lot of uncertainty. There’s too much complexity, too many moving parts, too much we don’t know, to create a solid, immutable plan.  


Sign up to my newsletter to get articles like this (plus eBooks, templates and other resources) in your inbox. 


Choosing A Destination

In the talk, Gojko points out the key attribute of a good plan — it has to be adaptable. He gives the analogy of a GPS navigation system. The navigation program plots a route to the destination, but adjusts it on the fly if a bridge is closed, if it a road gets congested with traffic, or, if the driver takes a wrong turn. It adapts the plan given new information.

The GPS analogy is interesting for several reasons. First it highlights the importance of having a destination. The navigation system is not favoring any particular road, it’s optimizing for the end goal. Most roadmaps I see don’t work this way. We believe that following the roadmap will move us towards our goals, but these goals are not clearly stated or even well understood. Different people may have different goals in mind, and consequently push for completely different ideas. This is why roadmap-building is so hard. It’s like planning a four-day road trip in Europe where the Marketing team wants to go to a big conference in Paris, the Sales team wants to visit an important customer in Prague, and the engineering team wants to stop over in Munich to overhaul the engine of the car. 

In this void of goals, executing the roadmap becomes the goal, which often creates the wrong incentives. The product org is judged on its ability to deliver bits rather than business results. We celebrate launches that lead to no improvement. Doing becomes more important than achieving.

Today we have a firm understanding how to create goals that aren’t about launching this or that, including:

  • Value-based mission — what core value are we creating and for whom. The company should have such a mission, but more broadly, each product division, group, and team can have one too. 
  • Impact and outcome metrics — These measure how much value we create for our customers and ourselves across a metric tree / graph
  • Objectives and Key Results are a good way to combine these qualitative and quantitative goals

Unlike releases, goals can be planned and plotted on a timeline, generating what’s now called an Outcome Roadmap. For example Instead of choosing to launching Single Sign-On by Q3, we can commit to “Help users stay connected and secure” and, more specifically, reduce the number of manual password entries, lock-outs, and login-related tickets. This goal will prevent us from fixating on SSO and open the door to other ideas. 

General tip: as we plan our goals we should push hard against any attempt to discuss ideas. Mixing the two doesn’t work. 


I teach many of topic covered in this article in-depth in my Lean Product Management Workshops. These workshops regularly sell out and are highly rated. Secure your ticket now or contact me to organize an in-house workshop.


Creating Maps

The other important point about a GPS system is that it’s aware that there’s always more than one way forward and it’s willing to evaluate and compare them against eachother.

We should do the same. For any goal we should identify multiple potential ideas. If we’re extremely lucky, one idea is all it’ll take to accomplish the goal, but often we’ll need a few — some may fail, and some may only take us part of the way. This suggests a tree-like structure that connects each goal to multiple ideas. Gojko Adzic advocates using Impact Maps, Teressa Torres recommends Opportunity Solution Trees, and I like the GIST Framework (Goals, Ideas, Steps and Tasks).

Unlike a GPS, we don’t never have a detailed map, and perfect roadside information. This means we need to test our ideas and discover which ones takes us in the right direction. This means the plan keeps changing from one week to the other. Ideas that don’t work are dropped, ideas that do work are iterated, new ideas are added. You simply cannot present all of this with a classic roadmap. Here’s what such a plan might look like if you use GIST — the GIST Board

OK, But What Are We Going To Release, And When? 

The desire to have predictable launches is not going away. People still want to plan ahead and want to have a comforting sense of certainty. Due to business realities, from time to time we will have to commit to launching something specific on a particular date (what Marty Cagan calls High-Integrity Commitments). That’s ok, as long as these launches are a rare exception. 

One way to avoid the trap of committing to specific ideas too early, is to transparently and regularly communicate which ideas you’re testing and how much confidence we have about them. Confidence is derived from one source —supporting evidence. I created the Confidence Meter to help you calculate it (here’s an example on how you use it).

As you communicate, for example via bi-weekly newsletter, you can bucket ideas into these groups: 

  • High confidence ideas — these are ideas we’re fairly certain are good and there’s a high likelihood we’ll launch them by a specified date. 
  • Medium confidence ideas — these are ideas that show promise, but we need to further validate them. No commitment yet. 
  • Low confidence ideas — Evidence is still scant. We need to test these ideas further to say anything concrete about them. 

The High/Medium/Low confidence scale should serve as a traffic light for the folks that need to prepare. They can treat low-confidence ideas as an FYI, should start looking closely at medium-confidence ones (although this may end up being throwaway work), and should be fully on-top of high-confidence ideas. In a sense it creates a roadmap with shades of gray rather than definite yes/no per idea.

Final Thoughts 

The name Roadmap was a clever bit of marketing for release plans. However it’s clear that this tool, whatever you call it, has run its course. Today we know it makes no sense to commit months and quarters in advance to specific product/business ideas based on opinions, consensus and weak evidence.

Those folks who try to put an end to release planning in their companies, often struggle to explain why, or to offer satisfactory alternatives. I hope this article offers some help, but I also assume this will be an ever-evolving topic. Over time I hope to see adaptive planning go mainstream. But don’t wait — now is the time to put your classic roadmap to rest. 

Photo by Brecht Denil on Unsplash

Share with a friend or colleague

3 thoughts on “Your Roadmap Isn’t Really a Road Map”

  1. yes maybe the word Roadmap “has run its course” however I like the roadmap for ideas and say I want to target that idea for that time period. You can with this give a sense of time criticality and where to focus on, however it should help orientation but not prevent changes.

  2. Great article, thank you Itamar!

    $0.02 from my side:
    Many org cultures strongly support the current status quo around roadmaps. There is a lot of appetite for certainty, especially at the C-level. So when you put something that is called “low-confidence _____” into an internal newsletter, you don’t look so good. You don’t look like someone who has things figured out, someone who’s an expert. You look bad compared to the other PMs who have “solid” roadmaps and use confident language.

Comments are closed.

Tired of Launching the Wrong Things?

Join my Lean Product Management workshops to level-up your PM skills and align managers and colleagues around high-impact products.