Product management interacts with many parts of the organization on a regular basis, but it’s usually either asking for specific information or soliciting input on very discrete items. One of the few times a product manager really gets to take center stage and show the fruits of their labor is when they’re presenting the product roadmap.
Roadmap presentations are the culmination of weeks, months, or possibly years of work. They sum up your entire vision for the product in a single visual, which represents the go-forward plans for developers, testers, marketers, salespeople, etc. All of this while aligning the strategy of the executive team with specific product releases and features.
A compelling roadmap can inspire the company and set a positive tone for the future. On the other hand, a roadmap with gaping holes, false assumptions, or confusing priorities can torpedo your credibility in the most public of forums. And when shown to customers, a roadmap can either help close a deal by painting a bold vision of the future or leave your audience unimpressed.
With so much on the line, it’s good practice to avoid as many missteps as possible when sharing your product roadmap with others. So, here are five mistakes you want to avoid.
1. Not reading the room
Not all roadmap presentations are created equal, even when you’re presenting the same roadmap. Although your audience shouldn’t change the fundamental elements of your roadmap, the things you focus on and emphasize should be tailored to the particular people you’re presenting to.
Executives want to stay at a high level, with a focus on big features and themes that support the overall corporate strategy. Meanwhile, sales want to know what new goodies they’ll be able to talk about to prospects.
Engineering will focus on technical implications, while marketing will want to know how the product stacks up against the competition and what kinds of content and outbound activities they can plan around coming releases.
Customer support wants to know if common pain points are going to be addressed and finance wants to see what the revenue and expense implications may be.
And, last but not least, your customers want to feel confident they’ve bet on the right horse with your products and see if their wish list items are included. And, since not all customers care about the same things, you’ll want to highlight the upcoming items most relevant to them specifically. You might even want to edit the version you show them to remove items they don’t care about so they don’t try to “jump the line” with their particular favorites.
“Roadmaps are a point-in-time capture of the current plan,” says Rich Mironov. “Different audiences have different (often opposing) goals and incentives, which we need to understand and anticipate. That should shape our presentations focus on and how we describe things.”
So keep in mind who you’re talking to and make their concerns the primary focus of your verbal narrative. You might even re-spin the content of the roadmap itself for the particular audience to avoid information overload and distraction.
2. Diving too far into the details
A product roadmap is a high-level vision for where your product is headed and the main steps you’re taking to get there. But painting this vast picture of strategy and direction means you can’t spend too much time on the details.
First of all, excursions into the weeds will harm your narrative flow; you’re telling a story and the main plot points are key. The point of a roadmap isn’t to discuss implementation, UX or dependencies; it’s about concepts and themes.
Additionally, any time you spend on the small stuff opens yourself up to being challenged and derailed by skeptical audience members that want to nitpick over nuances. There will be plenty of time to debate the merits of a given feature, but the purpose of a roadmap presentation is getting buy-in for the high-level aspects of your plans for the product.
Depending on your audience, you might even be able to get away with a roadmap that doesn’t call out specific features or releases at all, sticking instead to overall themes and vague delivery windows (i.e. near term/medium term/long term). But the most important thing is delivering a roadmap presentation that includes the minimum amount of detail required to secure overall approval and convey the general direction and priorities of the product.
“This approach allows you to have the flexibility to switch around projects in projected time horizons, without having to rejig your entire roadmap,” says Janna Bastow of Mind the Product. “Each time you have to realign and re-communicate a new roadmap, you need to instill understanding and buy-in for the latest changes–this will often kick off drawn-out discussions.”
3. Not doing your homework
Anything in your roadmap is open to questioning and challenges, so you must be confident that everything on there exists for a reason. Having the rationale for every item at the ready will enable you to quickly quash any probing attacks into your diligence and keep people focused on the high-level vision.
As a product manager presenting this plan, you will inevitably be forced to justify all the decisions made to get to this point, so you’d better be prepared.
“Technical teams need context for why you are building something on a roadmap,” says Martin Suntinger of Atlassian. “Engineers need to see evidence for why you see demand for a feature. Let data speak, but also tell a powerful story from the perspective of your users. Use personas, and talk about some alternatives that you’ve excluded, and why.”
By coming to the table with a solid basis for every tradeoff, compromise, and priority, you’ll be able to maintain your composure and confidence, which is critical to have so many different parties place their trust in your plan.
4. Ignoring what’s NOT on the roadmap
No realistic roadmap will include every single possible thing your product could potentially include, and it’s highly probable there are items missing that received a good deal of attention, consideration, and discussion. Thinking you don’t need to discuss any of these will put you on the defensive when a missing feature is inevitably raised by someone in the audience.
So instead of waiting for someone to ask you why something didn’t make the cut, be sure to proactively cover the top items you didn’t include as part of the presentation. You can briefly explain why they’re not part of the immediate future plans and hopefully snuff out any dissent quickly.
Although this won’t make everyone happy, it’s better to illustrate that these items were given fair consideration and excluded or delayed for a particular reason.
5. Dating yourself
What’s worse than presenting a roadmap to customers that don’t leave them excited for the future and confident they’re working with the right company? Promising to deliver key features and functionality by a specific date when you didn’t intend to.
All product roadmaps should come with giant asterisks and banner headlines proclaiming “Subject to change” and “All dates are estimates,” but that might take away from the visual aesthetic you were going for. However, one of the key messages everyone (particularly customers) should walk away with is some version of, “This is our current long-range plan, however, we don’t know exactly when things will be delivered and new information or events may cause a shift in priorities.”
But beyond those qualifying statements, you can avoid some drama by simply taking the dates off your roadmap completely, instead of using your roadmap to paint a linear narrative without a particular timeline. For example, instead of showing Single Sign-On support in Q1 and Automatic Backup in Q2, you can remove the Qs altogether—this still shows the audience that SSO comes before Automatic Backup without locking you into a specific, self-imposed deadline.
Showing roadmap dates and commitments can be extra dangerous for customers. They may simply assume this is when things are definitely going to happen and start getting very cranky when July rolls around and they don’t have the widget you’d projected would arrive during a roadmap presentation six months ago.
But a roadmap with dates presented to your sales organization can be just as troublesome. They might run with your planned roadmap and start making promises to prospects, who then sign on with the explicit understanding that some features will be available by a particular date.
Even if it’s boldly labeled “for internal use only” there’s nothing stopping an eager sales rep from boasting about what’s in the development pipeline to help them close a deal. And while some sales opportunities are worth making those kinds of commitments, that should happen intentionally and with lots of internal discussions, not just because a particular salesperson was oversharing.
Takeaways
Remember, a product roadmap is a vision of the future presented at a specific moment and will probably be outdated soon. It is not set in stone nor intended to be viewed as a contract between you and your audience. Applying caveats judiciously and making presentations interactive can limit the tendency to view them as absolute plans, as can soliciting feedback during the presentation to reinforce the idea that things could change.
And while there were earlier warnings about using dates on roadmaps, there’s one date you should always include—the date of the roadmap itself. This will keep any old versions that might be floating around from being mistaken for the latest one you’re currently presenting.
