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 wants 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.
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.
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.”
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 doesn’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 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 with 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 feature 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 discussion, not just because a particular salesperson was oversharing.
This roadmap will self-destruct in five seconds…
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.