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—before bringing it to the meeting. 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—for developers, for your sales and marketing teams, for your web team, and maybe even a semi-public version 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 a head 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 Roadmap Should Depend 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.
“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, and that purpose will help guide you in creating a custom view of the roadmap for that specific audience.
Here are some examples to help explain further.
For your 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 perspective 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, when you do dip down into the details to discuss what you need for the next quarter, your developers are going to want to see more detail—such as timelines and dependencies (so they can better prepare resources, prioritize items, and assign tasks).
So with your developer-focused roadmap view, you’ll probably want to include both some higher-level strategic information but also enough tactical detail that they feel like they have an understanding of what’s going to be expected of them in the near- or medium-term.
For your 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 quickly walk you through what we’re planning to accomplish in the next year—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.
For your sales team:
Your sales team’s focus is always on how your product is going to help them make sales.
So they won’t care about which development teams are assigned to which epics or features, when you’re planning a given sprint, 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, for example, that you’re working on a feature right now because your 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 are also going to be very interested in seeing 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.
There’s No Such Thing as a Single-View Product Roadmap for Everyone
Whatever format you choose to do this in, you really should be creating and maintaining multiple versions of your product roadmap, so you 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 you’re going to get that invite to “be prepared to share your product roadmap” from your execs.