Why Car Roadmaps Are Not the Same as Product Roadmaps, Part 1

Several of my clients have various roadmap problems. They want a single product roadmap to serve all these purposes:

1. Focus the team's work for this specific product for the short term. That includes some look-ahead to see the next bit of upcoming work when the team has more capacity.
2. Show customers where the company thinks the product is headed. (The overview of which problems the company plans to solve for which customers.)
3. Share the future with salespeople and other internal folks. (The more specific overview of when salespeople might expect new features or new products.)
4. Forecast when management can expect the team to finish some specific work. (What management thinks they want. Too many managers want a “guarantee” of when the team will finish which features.)

That's an awful lot of work for one visualization, especially since each of these sets of people (users) needs something different from that map. Yet, many of my clients want this ideal integrated roadmap. I suspect that's because we see integrated roadmaps all the time—for car travel. But with all these users and the various levels of detail, I have yet to see a useful integrated roadmap for software products.

Instead of one visualization, I recommend that product leaders create more visualizations based on what the various users need. Just as user stories help us create the product for the ideal user in this context, we can use each user's context to create useful roadmaps.

First, let's discuss integrated roadmaps and why we want them.

Integrated Roadmaps Do Exist

I have seen an integrated roadmap before. Before we had GPS-capable phones, we used paper maps in our cars. And when my folks took us on vacation, we used AAA's TripTik maps. I remember an overview of the route (where we thought we were going) with step-by-step instructions for how to get from local Point A to Point B (focus the driver's work). However, these TripTiks were not just “go this way and take this long.” The TripTik offered alternate routes and interesting possibilities, especially if you wanted to get off the highway.

(Our GPS-equipped phones can do the same thing.  Although, I don't see too many “consider this alternate route for cool sightseeing” on my various map apps. Maybe I have the wrong apps.)

All of these roadmaps have these built-in assumptions:

1. The roads will not change their location.
2. However, the route might change.
3. If the route changes, the timing from any given Point A to Point B will change.

Do people make the same assumptions for your product roadmaps? I don't think so.

And we have the other problem—IWBNI (It Would Be Nice If) we could use just one visualization.

Why We Want Integrated Roadmaps

So why do so many product leaders want to use the same visualization for all these users? Because we think we have all the data. And that with all this data, we can create a zoom-in for the teams, a zoom-out for customers and internal people, and a zoom-out-out for management.

We have a problem with our first assumption, that we have all the data.

We don't have all the data—especially the sizing and duration data. Sure, we have some of that data. But the farther out the details are, the less accurate information we have. (See The Case for and Against Estimates, Part 3 or Predicting the Unpredictable for more details.)

Even if you think you have all the data, ask yourself these questions:

• Have you ever had to re-estimate “the rest of the project” because Something Happened partway through that effort?
• How long did it take you to define those requirements and size them?

My experience is even when I tried to define and size “all” the requirements up front, Something Happened and I needed to replan. Every single time. Worse, if I try to predict too much of the future, it takes way too long and costs too much time.

Projects change. If we optimize for change, we can define a few requirements (stories), see that they are a reasonable size, finish them, and go back for more. The shorter that feedback loop, the more agility the team has.

When we drive, we always optimize for change. We can decide in the moment when we want to take an exit, a detour, or a totally different route. Or, to stick with the plan.

That's not true for most product development. We can't tell when we want to get off this road, take a totally different route, or even wait for our customers to offer us feedback. We don't know.

I don't see very many roadmaps that reflect that not knowing.

While we use the same word, “roadmap,” we need different sets of information.

Product Roadmaps Differ From Highway Roadmaps

Product roadmaps, especially if we want to use agile approaches, ask us to consider these concepts:

• The route (where we're headed for the product) can, and often will, change.
• We make small tactical changes for the product every time we modify a story or change the backlog.
• Assuming we use product minimums, and because we finish stories often, we can then make strategic decisions for the product itself, and possibly the product and project portfolios. (Yes, the corporate strategy.)

All of these decisions can change where we're headed and how long it will take us to get there.

The point of this series is to examine the needs of the users and roadmaps that might work better for them. We'll see if I destroy my own argument and suggest an integrated roadmap to rule them all, but I don't think so.

The Series:

• Why Car Roadmaps Are Not the Same as Product Roadmaps, Part 1
• Choose How to Visualize Your Product Roadmap for a Team's Product Focus, Part 2
• Help Your Customers React the Way You Want with These Roadmap Options, Part 3
• What Senior Managers Want & Need from Roadmaps: Predictability and Options, Part 4
• Consider Innovation and Personas When You Create Roadmaps, Part 5