So if you want to start a fight among product managers, throw out the word “Roadmap” and then just step back. People seem to have incredibly strong feelings about the value and necessity of Product Roadmaps.

The Argument for Why Roadmaps are EVIL:

From what I’ve seen, those in the camp of “roadmaps are evil” come at it through the lens of past traumatic experiences. At one point, they lived in environments where the culture was held hostage by the content of the all-powerful Roadmap. In these cases, the Roadmap absolved people from making decisions and was a sacred, unchanging source of truth. If asked what was going to done by a team and when, people were pointed at the Roadmap. In turn, the dev teams and product managers were evaluated on their ability to deliver against the Roadmap.

Regardless of the market dynamics, customer reactions, or the fact that assumptions in January are different than facts in June, the Roadmap was an unwavering, unchanging artifact.

If I lived in that sort of environment, I probably would never want to use a roadmap again either. You are setup for failure because you are penalized for learning, adapting and improving.

My guess is that the Roadmap isn’t the only “evil” thing affecting the product teams. Most likely, Jira is hated as well and they have probably burned through a few “transformations” where they tried out Scrum and then Kanban, JTBD, Lean UX, and any other framework-of-the-moment. These are places that love dogma and where tools and frameworks are brought in to define behavior vs. improve outcomes. In these places, there are probably more pervasive cultural issues, like the old saying goes “a poor workman blames his tools“.

The Right Way to Treat a Roadmap – A Tool to Help Manage Change

I am convinced, when used properly, the Product Roadmap is an incredibly useful tool and one of the key foundational artifacts in a healthy product culture. Before you build a product roadmap, you need to have an articulated product vision and strategy. These are the “what we are trying to accomplish and why”. The product roadmap then provides you the “how”.

Like any tool, it doesn’t solve every problem, but when used properly, it can help everyone in the company understand:

• What are the most important customer problems we are trying to solve (by team).
• The sequence of problems we are going to focus on.
• The estimated effort it will take to build these solutions.
• Level set the company on when we will be able to solve particular customer problems.

What’s important to point out to everyone is that the Product Roadmap will CHANGE because its always a perspective based on a specific point in time.

When you build your roadmap, you have to include the set of assumptions and priorities the company had at the time of it’s creation. Simply put, the roadmap is your company saying “Based on what we know TODAY, this is what we think we will do in the FUTURE.”

With that statement, you acknowledge that the moment after you define your roadmap, it is subject to change. As you learn more through product discovery, as your sales team works with more prospects, as your competitors develop additional features, as the economy changes, those assumptions you made are also changing. By having a product roadmap, you can take each one of these changes and hold it up against your roadmap and ask the following questions:

• Does this new piece of information change one of our assumptions? If so, what is the new assumption/fact?
• Does this new idea help us achieve our goals faster, better, easier than what we have on our current plan?
• If we say yes to the above, what will we stop doing to accommodate the new thing?

In this world, the Roadmap is a living, ever changing document – a record of learning and adapting vs. a list of stuff to be done.