I have a confession—I’m a Product Manager who likes roadmaps.
I’ve always created and/or had roadmaps in my product organizations. I phrase this as a confession because roadmaps get a bad rap. With a modest amount of Google searching you’ll find plenty of posts talking about the perils of roadmaps, like this one. This is especially true in the Agile community. Prior to the newer “scaled” agile processes, like SAFe or DAD, the notion of a roadmap was completely absent from the agile lexicon.
The truth is that this negativity towards roadmaps is the product of people abusing the concept. Sadly, I often see roadmaps used as a weapon instead of a tool. Here are a few ways I see roadmaps being misused:
1. Roadmap as a “project plan”
Most roadmap styles look like Gantt charts—they have horizontal bars set across a time period. Despite similar appearances, roadmaps are not meant to manage project status and reflect specific dates. Roadmaps that are too refined, or have specific dates (like 12/17), can be construed as concrete commitments. Because roadmaps reflect the future (6-18 months forward), sharing a specific date is irresponsible and unwise. Until work is better elaborated and discussed with developers, it’s impossible to know an exact date.
2. Roadmap as a catch-all
“It’s on the roadmap.” This is one of the classic phrases you’ll hear from product managers. It’s meant to instill a sense of assurance to the customer. It’s akin to “I got this.” It’s very simple to say and generally has an instant positive impact. Yet, in many cases these items haven’t been estimated or architected. They are not ready to be built. So, while this provides a short-term sense of assurance, it creates a large long-term expectation that will only lead to worse things when the expectations are unmet. How often have you been told something is on the roadmap but it never seems to get delivered?
3. Roadmap as a inspiration and guilt-inducer
“It’s on the roadmap that we’ve shared with customers, so now we simply must do it” is a cry I’ve heard in the past. When said, the leader is trying to inspire and rally troops. It implies that something herculean needs to be performed—more hours, on more days, above and beyond the norm. Unfortunately, in this case the root cause is poor planning and over-promising from leadership, and the team ends up absorbing all of the pain. Candidly, this sucks and is one of the top reasons people hate roadmaps.
So why use a roadmap?
For me, a roadmap is a communication tool, and it’s a good one. A roadmap reflects our best guess of what is going to happen today, based on our best information and current priorities. Honestly, it’s a different view of the force-ranked backlog—that’s it. It always needs to include the words “SUBJECT TO CHANGE.”
I typically have two goals in sharing a roadmap: 1) explaining the “why” and 2) collecting feedback. #1 is critical. Too often roadmaps are shared with no explanation or reasoning. Generally a lot of thought goes into the prioritization, so it’s imperative to explain it. No, this level of detail is typically unable to be included in slides, so it is part of my talking points.
As practice, I never support sending roadmaps to anyone via email—I require discussions when I’m asked for a roadmap.
As for #2, the reason I require discussions is that I want the feedback. Each roadmap discussion is a huge opportunity to gain feedback into the priorities—which will only improve the prioritization over time. In the past I’ve received feedback ranging from “looks good, but I’d add XYZ” to “you’re completely missing my top items” to “I never thought you’d be going there.” While these may not immediately cause you to adjust your priorities, it’s good input regarding how your work will be perceived by the market, and by your customer base.
For more discussion and tips on building product roadmaps, watch the Pendo and ProductPlan on-demand webinar Building Data-Driven Product Roadmaps.
