Back in the olden days, we didn't carry around little GPS devices in our pockets. When we wanted to figure out how to get from A to B, we relied on roadmaps. They were big and they were awkward, but they showed you all of the streets and avenues in a given area. When you wanted to navigate around, you found your current location, hunted around from your destination, and then plotted a course.

This was all well and good, until something unexpected happened. (And something unexpected always seemed to happen.) You missed the exit. A road was closed. A new highway was put in. It didn't take much to ruin the whole trip.

Things are much easier now. You can tell Google Maps where you want to go and it calculates the best route to get there. It warns you ahead of time if traffic's going to be bad, or if construction will block the way. If you decide to explore a side street, it automatically adjusts and sets you back on course when you're ready.

If only things were so easy when it comes to product development. Instead, many organizations continue to rely on the older metaphor to help plan and execute their most important initiatives: the dreaded (and dreadful) project roadmap.

Building a road to nowhere

Back when we relied on physical maps, we had to plan our routes out meticulously in advance. We'd need to plan each and every turn before we left the house. Otherwise, we couldn't be confident we'd end up where we needed to go.

We don't need to do that anymore. But that's still how many organizations approach product management.

The roadmap's used to communicate to the organization what they'll be working in the near future. But constructing the roadmap is itself an enormous effort. It might take months of engaging stakeholders, collecting wish lists, and developing business cases. Then there's the inevitable road show, promoting the roadmap to executives and other key decision makers. Sometimes, it feels like as much time and energy goes into crafting the road map as will be needed for the work itself.

And for what?

The output often ends up looking, more or less, like a project list or a Gantt chart. There's a list of teams, each assigned a series of features to build from among those requested by stakeholders. The features line up with certain dates, and everyone feels pretty pleased. They have a plan now. The work's concrete, organized, and predictable. The roadmap gives everyone a nice feeling of security, control, and direction.

Then you hit the first roadblock or detour. There's some unexpected complexity. An urgent request comes in that bumps a bunch of other things down the queue. A key team member quits suddenly, and there's a resource gap. Everyone scrambles to adjust, and the dominos start to fall.

Or, worse.

The team invests time, energy, and money in building the requested features, but it lands with a resounding thud. The market doesn't care. Even though everyone was sure that the shiny new addition to the product would be a difference-maker, it simply doesn't get adopted. Months of work, wasted.

Either way, the roadmap is revealed to be a convenient but fragile fiction.

Two inconvenient truths about product

These top-heavy roadmaps inevitably run into one or both of what Marty Cagan calls the two inconvenient truths about product.

The first inconvenient truth is that most of our ideas aren't going to work out. Cagan suggests that at best half of our ideas are going to fail. Itamar Gilad is even less confident; he suggests that even among the most mature product organizations, just 1 in 3 ideas might yield measurable positive results. Most organizations should be pleased with 1 in 10.

Fixed-date roadmaps rarely leave adequate little time for proper discovery and testing. Instead, they assume that the early ideas will work out. Organizations invest heavily in a small set of big ideas. This puts a heavy burden on those ideas. So much has been invested in the planning process. The sunk cost fallacy kicks in, and before long organizations are spending not to build the best product, but to validate the original roadmap. It's confirmation bias in action.

The second inconvenient truth is that even the good ideas typically don't succeed out of the gate. It takes iteration and ongoing development to reach the desired impact. Unfortunately, with the traditional plan-and-execute roadmap, the crucial period in which the product can be optimized is occupied instead with hurried fixes or delivering features that got bumped back to "day two" after it became apparent that the original timeline was optimistic.

As Gilad argues, we're biased to be too optimistic about the benefits of our effort. At the same time, we underestimate the effort required to bring them to life. There are simply too many unknowns and too much change. Try as we might to ascertain how much effort and impact a feature will require, most of that effort is little better than guessing. As Melissa Perri points out, setting dates ahead of time only forces teams to compromise. They'll either have to release buggy code or reduce scope to meet the deadline, or else push the date back—putting the entire roadmap behind.

Detours and dead ends

The plan-and-execute approach to roadmapping might have made sense when software was shipped annually in physical boxes. Today, it's wasteful, inefficient, and risky.

Modern digital product management thrives on agility. With each release, the team collects data that drives each subsequent release. Product development and discovery go hand-in-hand as designers and developers learn from feedback given in response to prototypes and new releases. The product is continually refined.

But the traditional roadmap, with its long-term commitments and assumptions, isn't compatible with these methods. It locks the team in to whatever preconceptions were held in the planning cycle, holding them well past their best-before date and in spite of whatever new evidence is gathered throughout the product lifecycle.

Instead of empowering and enabling the organization, these top-heavy roadmaps constrain development work, creating dead ends where they should be forging new paths into the future.

There's a better way.

Start with the destination in mind

A roadmap needs to not only explain what teams will be working on. It needs to show them why they're working on it. It needs to provide an explanation of where the road will lead. If everything is achieved, how will the world be different?

The roadmap should be a strategic document, not an operational one. Far from outlining a plan of action, it should provide strategic context for the journey ahead, and inspire the teams who will bring the strategy to life.

This means that the roadmap needs to begin with a clear vision of the future. And, everything on the roadmap needs to contribute to making that vision a reality. Too often, the roadmap is more of a wish list, populated with odd requests that may or may not be prioritized based on expected value or need. Each item is treated as a discrete deliverable rather than a building block of something greater.

Use the vision as a filter. Most likely, you'll never find yourself short on ideas to put on the roadmap. A clear vision gives you criteria for what should go on the roadmap and what shouldn't. It's a simple test: does the feature get you closer to the vision? If not, it shouldn't be on the roadmap.

Think in outcomes

With the vision in place, you can start to populate the roadmap. But instead structuring it around solutions, organize it around problems. Shift your perspective: instead of allocating a quarter or a year to a specific feature, allocate that time to a key challenge or opportunity the organization is facing.

There are a few ways to do this.

Melissa Perri suggests creating a problem roadmap. This is divided into two phases: 1) discover and experiment, and 2) build and validate. In the discover and experiment phase, the team will engage in research that is focused on validating that a problem exists, and work toward creating an MVP that can be tested. Notably, Perri positions the MVP not as a final output, but as part of the discovery process: it’s created to help the team learn. Then, the team can move onto the build and validate phase, focusing on the continual delivery of increments that make and measure progress agains the core problem.

Perri suggests creating this document by first listening and prioritizing the top problems facing the organization. Each team is assigned the problem and given a KPI; when the problem is solved, they can move onto the next one. If they validate that the problem exists, they can move toward solving it. Each quarter, the organization should revisit the list of problems, determine if more investment is needed, and reprioritize the list.

Itamar Gilad, on the other hand, proposes what he calls the GIST framework. This method starts by defining a series of goals—that is, desired outcomes—that the organization is looking to achieve. From there, the product teams comes up with a list of ideas that they believe will help them achieve the outcome. These are in turn translated into step-projects—smaller steps and experiments that will contribute to achieving the larger goals. These decompose into tasks, the day-to-day work the team undertakes each sprint cycle.

Finally, C. Todd Lombardo and his co-authors of Product Roadmaps Relaunched make the case for “thematic” roadmaps. This approach positions the roadmap as a vision for communicating how the organization will achieve its strategic goals. From the vision, product leaders define business objectives and set broad timeframes around achieving them. From there, each team focuses on outcome-focused themes that organize their work. For instance, a company building hoses might spend a quarter focusing on “indestructibility,” with a couple of teams each working on some facet that the organization believes will contribute to that broader goal.

The shared bottom line among these approaches is that the focus is never on executing a wish list of features. Rather, the focus is on creating meaningful outcomes for the organization. They leave the team room to discover and execute the most effective solution, rather than the one that was thought of first.

Folding up the roadmap

When we used to rely on physical maps to get around, we'd have to plan our routes far in advance. Today, Google Maps makes things much easier. We just tell Google where we want to go, and it gives us options. We can avoid tolls, or even take a longer route if we want. It can help us avoid traffic. It warns us about construction ahead, and can even advise us on the best time to leave the house. And most importantly, if we veer off that route, it doesn't fold on us. It simply helps us get back on the right path.

We don't have Google Maps for product management. But we can get a heck of a lot closer than the traditional roadmap allows.