4 best practices for roadmap presentations, from research with 30+ product teams

Our effectiveness as product managers is heavily informed by how well we communicate what we’re building and why it matters.

It can feel like a waste of time to repackage and tailor roadmap updates for different audiences, but as one product leader I spoke with said so bluntly:

“I have really smart PMs who can’t put together a slide deck, and it lowers their impact.”

‍

So what makes for effective product roadmap presentations?

I’ve spent more than a decade building and leading product teams at Google and several high-growth startups. Over the last year, I conducted research with product leaders and PMs across more than 30 companies to inform the product that we’re building at the company I co-founded, Korl.

One of the most surprising patterns I’ve seen is how many great product folks have asked… is there a way I should be doing this?

Inspired by this question, here are 4 best practices for presenting your roadmap. While they are partially based on my own experience, heavy credit goes to the people who graciously shared their approaches with me via research sessions and design partnerships over the last year.

‍

#1 Follow the rule of “80-max-4”

The best product teams I’ve encountered are focused, and this translates to how they prioritize — and position — their roadmap.

A good rule of thumb is that when looking out 1–2 quarters, at least 80% of a product development team’s effort should map to a maximum of 4 key investment areas.

This is not just about driving focus in the planning process (though that is an important reason to go through the exercise of aligning each roadmap item to a strategic pillar for the company).

It is also about providing stakeholders with recognizable guideposts to help them make sense of the roadmap when it’s shared with them.

As an example, the VP of Product at Muck Rack, Mandy, consistently introduces key investment areas upfront in every roadmap presentation. She then highlights how each project maps to one of these areas through the use of color coding or tags in both overview and detailed slides.

‍

#2 Embrace that external positioning never matches internal

Every team has their own terminology for the products and features that they’re building. And it never translates to how you want to speak to customers or partners about those features.

But it’s really hard to get people describing projects internally the way they should be positioned externally. Furthermore, the use of internal shorthand can actually prove beneficial when it contributes to a sense of camaraderie among the team members doing the heavy lifting.

So instead of trying to stop the use of internal jargon, great product communicators accept it and start a practice of explicitly documenting external positioning separately.

In the words of Steven, Chief Product Officer at Ironclad:

“You can either fight that battle, or you can accept reality and realize that development teams have their own way of talking about things. And then somewhere along the way, a PMM or PM translates it to the outside-in view of the world."

‍

#3 Tell them, then tell them again

As product people, we eat, sleep, and breathe what we’re building in our products. Much to our dismay, other people sometimes think about… well, other things.

I’ve found it next to impossible to over-communicate about your product roadmap. You will think you’ve said something a thousand times and that people must be getting sick of hearing it. And then somehow, it still lands as new information.

Product teams who are most effective at keeping stakeholders informed and aligned tend to recap the same information multiple times and in multiple formats.

In addition to sharing what’s coming, they highlight “recently released” features for at least a month after they’ve shipped.

They send a weekly product update via email, hold a bi-weekly product review with go-to-market teams, and report out on the roadmap regularly in monthly all-hands meetings.

‍

#4 Lead with what changed, and why

As every PM knows, the only constant is change. Timelines slip, escalations happen, and what you say you’re going to do is never exactly what ends up getting done.

There is a huge difference in how change is perceived, however, when it’s shared and explained versus when it’s “discovered” by stakeholders.

A best practice is anytime you present to a particular audience, start the presentation with a summary of key takeaways and notable changes since the last review you did with them.

The format we use at Korl is to list projects that have been released, had their release dates shift, and were added or removed since the last update. We also include a few bullets calling out overall takeaways and explaining why these changes occurred.