Roadmaps

“Roadmap” is the most overused word in product management because everyone asks for one. Every stakeholder wants a roadmap because it addresses different needs for different people. Executives want to know the strategy, sales want to know the timeline, and what no one seems to realize is that a roadmap doesn’t solve a problem or deliver a requirement.

Roadmaps are one of the top pieces to the puzzle in product management—everything boils out of a roadmap. What’s interesting about them is that there is no science to creating one. There’s no secret sauce.

But at the end of the day, a good roadmap is focused on the high-level goals, themes, user stories, and blocks of information you need to complete a project.

The challenge is that sometimes you need to build a lot of them. The number-one use for a roadmap is to present to the vision of your product, service or solution to management.

As a product manager, you’re going to do all the things you’re supposed to do—use tools to get a sense of the market, what people want, what problems can be solved—and eventually you will come up with a high level roadmap.

In my experience, the best roadmaps fall in the middle. You can easily go down a rabbit hole with a detailed roadmap, but the key is that it answers your top questions and steers you in the right direction during development.

Based on this, can roadmaps really fail? Honestly, it’s subjective and difficult to quantify.

What I can say is that roadmaps should evolve. As product managers, you monitor and adjust roadmaps as you go along, and if it was well thought-out and planned, it’s just going to change less than one that wasn’t. Change is good because the market dynamics and story may have changed. Here, you’re adapting to current conditions.

To me, not changing is failing. The success of a roadmap is going to be in what you were actually driving down from that roadmap. In other words, how well that roadmap led you to the final product, and more importantly, how well all the pieces came together during development, testing and launch.

I use what I like to call the “smell” test. If a roadmap smells bad, it probably is.

If people can’t understand the process from the roadmap, then you haven’t defined the story well enough or you don’t understand the market or your internal constraints well enough.

The success of the roadmap is defined by the success of the product and the company. You should understand your roadmap, know where it’s going, articulate it without seeing it and tell the story in an elevator pitch. If you can’t do that, you don’t have a valid roadmap. Roadmaps fail when they fall short of this standard.

How do you use roadmaps? Do you think they fail or succeed, or fall somewhere in the middle.

Leave a comment and let us know.