Product management owns the roadmap. They spend more time than anyone in the company poring over this important strategic blueprint. But that doesn’t mean the roadmap is an internal document for the product team’s eyes only. If they want their products to succeed, product managers need to share their roadmaps with other teams across the company.
That means your roadmap needs to be more than well-thought-out, strategically sound, and supported by data. It must also be so clear and intuitive that anyone can grasp it at a glance. Even people in your company who don’t know the difference between an epic and a theme.
We’ve discussed how to share your roadmap with different teams in a previous article. So in this post, let’s go over a few tips for making roadmaps so clear and intuitive that your non-product teams members have no trouble understanding them. While we’re at it, here are 37 tips for building a roadmap that aligns stakeholders.
Download The Product Roadmap Strategy Playbook ➜
1. Keep out acronyms only your team knows.
Let’s say you’re presenting your product roadmap to your executive staff. Will they know that the item you’ve tagged as a “CAR” is a client-actionable request?
If that’s not a term your company uses outside the product management department, don’t use it.
When they’re looking over your roadmap, even a second’s worth of confusion or frustration could turn an exec off. That could make them harder to persuade.
2. List benefits, not features.
This is a rookie mistake, but a lot of seasoned product managers make it. It’s hard to blame them.
Product managers can get so focused on reviewing data and debating priorities that they forget to write out the roadmap in a way that’s clear to non-product people.
“New back-end self-serve module” won’t mean much to your marketing or customer success teams. So you don’t want to present a roadmap to them loaded with features like this. Instead, frame these initiatives as benefits: “Improve the prospect’s free-trial experience.”
3. Keep your roadmap’s contents at the strategic level.
Your roadmap is not a to-do list of product-related tasks or a list of planned work you have for the future. That’s what your product backlog is for.
In a roadmap presentation, you want to show your audience (execs, the marketing team, developers, etc.) your high-level strategic objectives and plan for the product. This is not the time to get into a detailed talk or debate about specific tasks or action items.
Don’t list tactics or tasks. Include only strategic-level items: “Add Secure Data Protection,” “Complete Regulatory Certification,” “Roll Out Mobile App,” etc.
Also, if you can, include your strategic reasoning for each of these items on the roadmap as well. We’ll discuss this point next.
4. Include the strategic basis for including for each item.
For each strategic-level item on your roadmap, you should have a brief “why” explaining your choice to include it.
You’re why might be a short phrase: “Customer surveys indicate a high interest in this functionality.” It might be a number: “Weighted score of 71, second-highest of all proposed initiatives.” It might simply be that you’ve color-coded an item as green, which your roadmap’s legend shows as an item that will “Increase Revenue.”
Whatever method you choose, make sure your roadmap audience never has to guess why you’ve chosen to include each item.
5. Explain clearly how each item supports one of your business goals.
Your product doesn’t exist in a vacuum. The work your team is trying to get done on the product, and the budget and resources you’re asking for to make that happen, must support your company’s larger objectives.
In fact, each theme or epic on your roadmap should also support one or more of these organizational goals—or else, why include them?
These objectives could include growing market share, increasing revenue, or improving visibility among your industry.
You can do this with a short phrase under each item, or simply with a color-coding scheme tied to these various objectives. The point is, when presenting your roadmap, make a clear connection between the work you’re planning and how that work will benefit the entire company.
6. Make the roadmap visually intuitive and easy to follow.
Even if you’ve done all of the things we’ve outlined so far, your roadmap could still be confusing if you don’t present it in the right visual way.
You need color. You need filters. You need a legend. You need the ability to instantly jump to different views or to drill into specific details to make a point. This is why it’s very difficult to present a clear and compelling roadmap using the wrong tools. (Sorry, Excel and PowerPoint—you’re terrific at what you do, but roadmaps just aren’t your thing.)
And it’s why you’ll find this process so much easier with a purpose-built product roadmap app.
7. Talk strategies and plans, not epics and swim lanes.
The way you’ve grouped your roadmap’s items into epics, themes, and swim lanes means nothing to your non-product audience. Those are details about your team’s internal processes.
Instead, talk about strategies, priorities, and plans. Tell your audience what you’re planning to work on, why you chose one initiative over another, and what you envision this work is going to do for your business. That’s what matters in a roadmap presentation.
8. Communicate priority levels visually (especially if you don’t use dates).
Even if you’re presenting an uncluttered, visual roadmap with only a handful of strategic-level items, your audience might have trouble understanding at first glance which things you plan to do first. This is particularly true in cases where you present your roadmap without timelines—as you might do, for example, when sharing your roadmap with the sales department.
To help your non-product audience easily grasp the sequencing of your planned work, find a way to visually convey priority level. If you’re not showing dates on your roadmap, you can use color to communicate either level of priority (“medium,” “high,” “must-have”) or the way you’ve ordered dev work on various items (“now,” “soon,” “later”).
9. Make clear who’s responsible for what.
For internal product roadmaps, you’ll want to make clear which teams have ownership of which initiatives. This is particularly valuable information if you allow coworkers to view your roadmap online anytime. Here’s why.
Say one of your customer success reps takes a call from a user who’s having trouble with a bug in your company’s software. If your roadmap is accessible to teams across your org, and you’ve listed in that roadmap which teams are handling which aspects of the product, that customer success rep can find out immediately which developers are most likely to have the answer to this user’s problem.
10. Have data ready to explain and back up your decisions.
As we pointed out above, the non-product viewers of your roadmap are going to want to know why you’ve chosen the items they see on the roadmap, and why you’ve prioritized those items the way you have.
Whenever possible, we recommend you include some sort of supporting evidence or reasoning (a weighted score, a short explanation) right alongside the item on your roadmap. This way your audience can see your strategic thinking for prioritizing an initiative at the same time as they see the initiative itself.
But if you have more detailed evidence to support your roadmap’s plan, you should also have that handy during your presentation. You never know when an exec, investor, or other stakeholder is going to ask for clarification on your strategic reasoning.
This supporting evidence might be a summary report of your product’s usage data. It might be the highlights of a recent customer survey. Or it could be the detailed results of your cost-benefit analysis of competing for product initiatives.
Whatever method of analysis you used to make your roadmap’s decisions, be ready to explain and defend them when you present the roadmap to other teams.
Conclusion
When you share your roadmap with non-product team members, your goals are to communicate the strategy you’ve planned for your product and to persuade your audience to help you bring that strategy to reality.
To boost your chances of both, you first need to make sure anyone in your organization will easily understand your roadmap. The last thing you want in a meeting like this is to confuse or frustrate your colleagues.
So as you craft your roadmap for a presentation to non-product team members, always ask yourself, “Will someone viewing this for the first time understand it without needing to ask a bunch of questions?” If the answer is yes, go ahead and call that meeting!
