How and When to Share Your Product Roadmap

Successful product managers know how important it is to share their product roadmap with internal stakeholders. Sharing the roadmap with different internal teams such as sales, executives, marketing, and developers is part of the job. You need to get alignment across the organization about what you’re working on and why. But how can you tailor your product roadmap presentations to each audience you’re presenting to? Let’s take a look at some pointers…

When Executives Ask to See the Product Roadmap

Let’s say your executive team schedules a meeting for you to discuss your product’s progress and plans for the future. Their invite also asks you to “be prepared to share your product roadmap with us.”

Chances are you’re going to need to make some adjustments to that roadmap. Or, at least review it carefully, taking into account what your execs are and aren’t going to be interested in. You’ll need to ask yourself, for example:

  • Do you want to remove some of the deadlines on the roadmap and present just a broad estimated timeframe for your initiatives?
  • Do you want to share timelines on your roadmap at all for this meeting?
  • What level of detail and granularity should you present to your executives?

If your product roadmap lives as a static spreadsheet or presentation file (and why, oh why, would you do that?), you’ll probably need to create a unique version of the roadmap for this meeting. The good news is that you can then maintain and update this version (call it “ABC-Roadmap–ExecView.xlsx”) for future meetings with your executive stakeholders.

But what this little thought experiment also points out is that you’ll probably want several versions of your product roadmap. One for developers, for your sales and marketing teams, for your web team, and maybe even a semi-public product roadmap for your customers and prospects.

Of course, that’s a lot of spreadsheet files to create and update. So one practical solution is to move to a purpose-built roadmap app that lets you create custom views of your product roadmap for various audiences. Like this:

But we’re getting ahead of ourselves. Before we talk about how to switch roadmap views, let’s review when and why you’ll want to do so for various teams or audiences.

How You Share Your Product Roadmap Depends Entirely on Context

As we say to anyone who will listen, your product roadmap should be entirely strategic. Everything about the roadmap should be strategically designed to advance your product toward success—and that includes how and when you share it with your organization.

Tweet This:
“Everything about your product roadmap should be strategically designed to advance your product toward success.”

If you’re sharing your roadmap with your developers, you need to know why you’re doing so. What’s the strategic goal of sharing it with that team (either by granting them access to view your roadmap on their own, or presenting it to them yourself)?

The same goes for your executive stakeholders, or your sales department. You need to have a clear strategic purpose behind sharing your roadmap with these groups. That purpose will help guide you in creating a custom view of the roadmap for that specific audience.

Read the Product Roadmaps Guide ➜

Here are some examples to help explain further.

Sharing your product roadmap with developers:

Your development team spends much of its time focusing on the ground-level details. They have tasks set for them that go only a few days or weeks out—small stories, bug fixes, minor tweaks, testing, etc.

It’s easy for these teams to lose focus on the product’s bigger-picture objectives, and that can mean you’ll lose some of the unique perspectives these professionals can bring to your product.

So when sharing your roadmap with your developers, you’ll want to help lift their gaze up every now and then to see the big-picture strategic view.

You might say to your developers, “I know we often talk about the tactical-level stuff that usually goes no farther out than one quarter, but I wanted you to see our product’s 18-month plan.”

At the same time, developers will want more detail. Timelines and dependencies help them prepare resources, prioritize items, and assign tasks.

Your developer-focused roadmap view should include some higher-level strategic information. But it also needs enough tactical detail that they understand what they’ll be working on in the near or medium-term.

Sharing your product roadmap with executive stakeholders:

With your execs, you’ll probably want to go in the opposite direction. You’ll want to help lower their gaze a bit from the big-picture visionary stuff they focus on all the time, so they can see the work that needs to get done in the medium-term to realize their long-term vision.

You might say to your executive team, “As you know, this is our five-year vision for the product. And we’ll get there. But let me walk through what we’re planning to accomplish in the next year. We are working both to generate revenue today and to move us closer to that longer-term objective.”

Of course, even at this one-year view, you’ll want to use details sparingly. Your executives probably aren’t going to be interested in hearing about your plans for resource allocation or your internal estimates for smaller initiatives or the dependencies among these smaller initiatives. So keep the tactical details to a minimum here, and present just enough information to visually walk your execs through the key milestones slated for the coming year.

Sharing your product roadmap with your sales team:

Your sales team’s focus is always on how your product is going to help them make sales.

They won’t care about which development teams are assigned to which epics or features. Or how much initiatives are going to cost to develop. Leave these details out of the sales custom view of your roadmap.

Instead, when you share your roadmap with sales, you’ll want to focus on upcoming features—and you’ll want to include right on the roadmap itself your strategic reasoning for every feature you’ve prioritized.

If you can explain that you’re working on a feature right now because surveys or other research indicates it will be popular with users, great. Your sales reps will be happy to hear it.

Caution: One word of warning, though, is to be careful about dates. Your sales reps like knowing exactly when you plan to have a new feature. Because that could help them with prospecting and making pitches to potential new customers.

But when you include a date on a product roadmap—even if you clearly explain it’s an estimate only—at least some of your reps are going to treat it as an implied promise. So be careful about including dates on your sales-focused custom view roadmap.

Share Different Roadmap Versions with Different Stakeholders

Whatever format you choose to make roadmaps in, you should create and maintain multiple versions of your product roadmap. You’ll always have quick access to the right roadmap view and the appropriate level of detail for a given audience.

You never know, after all, when someone will ask you to share your product roadmap with them. And when they do, you want to share the most relevant information in an easy-to-understand manner.