Debunking the Parable of the Product Roadmap

Last year I went on a speaking tour across the United States. During that time, I attended many Agile conferences, meetup groups and private company meetings. At these events, I kept hearing the same parable over and over. I heard it so much that I believed it, and since then, I’ve been spreading that story myself. It’s a shame, since I now believe it’s actually more harmful than it is productive.

It’s an inspiring anecdote that challenges the way we think about product roadmaps. In the early days of software development, product roadmaps were equivalent to those of massive construction projects. They involved heavy resource planning, critical paths and often were visualized using Gantt charts … And if there’s one argument that Agile aficionados would go to the mattresses over, it’s for the death of Gantt charts.

They have fire in their eyes for a legitimate reason. The project plans of Yore were infamously inflexible and unable to gracefully respond to even the slightest deviation from course. Projects which were running over budget were coined “death marches,” a situation which ended nearly as badly as they sound.

This parable, an analogy relating software roadmaps to literal travel roadmaps, was the perfect anecdote to illustrate the problem as well as a simple solution. The story usually goes something like this:

You are packing up your house in New York and driving a moving truck to your new home in sunny Los Angeles, California. The plan is to turn in your old keys on Friday morning and pick up your new keys the following Saturday, on the other side of the country. Can you make it in time?

To answer that question you’ll need to make some preparations. You pull up some online maps and evaluate possible routes. The southern route looks like a nice drive, but if you take the northern route through Omaha, Nebraska, you’ll be greeted by a 6 foot bronze statue of Chef Boyardee. Who can pass up the chance to visit the king of processed pasta product? Not you, decision made.

After some quick math, you estimate how long it will take to drive the 3,000 mile trip and you start to plan in a bit more detail. First you determine the legs of your trip and what hotels you’ll inhabit along the way. You might research road construction and traffic congestion to determine the optimal starting and stopping times each day. And if you’re really detail oriented, you might even plan where you’ll stop for meals and fuel.

When the day arrives to turn in your key and start the trip, your plan takes on a new responsibility to provide a series of benchmarks that you can use to gauge your progress. As long as you make your hotel reservations each night on time, you are on pace to meet your realtor in LA.

By Monday morning you are making good progress. After dwelling over your thoughts in the car the past few days, you realize that the whole Chef Boyardee thing actually kinda creeps you out. Since you’re ahead of schedule, you make a hard left turn and aim for Vegas. After all, a walk down the strip and a show or two just might loosen up those stiff legs. Plus there’s a pawn shop down there that doesn’t actually pawn anything.

You make it to Los Angeles with a few less dollars than you expected, but with time to spare none-the-less. It’s because of your valiant planning that you were flexible enough to change plans in the middle of the trip. The only unfortunate consequence is an angry hotel concierge and that stubborn cancellation fee on your Visa.

This is a fun story, and it does illustrate the value of a flexible plan quite well. But, the story has one serious fundamental flaw. It assumes that there’s a finite distance between the starting point and the destination.

In geography, this assumption is undeniably true. There's no getting around the 3,000 mile divide between the cities, and it’s going to take time to traverse that distance. Because of this, you only have a few limited options if you are running behind:

• You can press the pedal to the metal, and keep a keen eye open for cops;
• If you possess Donald Trump-like resources, you can charter a helicopter or plane;
• Most commonly, you could change the expectation of when you’ll get there.

But no matter what, there’s just no way to shorten that distance.

However, on software projects, this distance is squarely in our control. Our business needs are no longer tightly bound to our requirements. We have the power to change our destination without changing the desired outcome.

Just as with our mythical road trip, we draft a plan for our project and then start building. But a few days later when confronted with being over budget, having spent 25% of the budget and only delivered 15% of the results, we aren’t beholden to the same failures that we are in the analogy.

For example, our outcome may be to “automatically distribute invoices to each customer monthly.” At the start of the project we planned to do this by sending an email with the invoice attached. But, given a tighter budget, we could choose to remove the complexity of attaching the invoice and deliver the invoice content in the email body itself. By allowing our plan to change, we were still able to satisfy the need.

And thusly, this analogy no longer makes sense. When we live and breathe the meaning behind this story, we live and breathe a lie. When we use that lie to justify our decisions, we make poor choices. Despite our best intentions to correct the situation we often end up making things worse.

When times got tough on a project, our team used to feel like our only option was to “buckle down and get it done.” Instead, by giving ourselves many opportunities to adjust our plan along the way, we can be more confident in meeting our goals within the time constraints we originally set.