In today’s agile world, presenting and knowing how to communicate your product roadmap strategy is not an isolated phase of the product lifecycle. You can’t simply move neatly from creating your roadmap to sharing your roadmap to executing your plans. The process is iterative, and communication is part of every step.
Nor is this communication one-way. You will need to update the relevant teams and stakeholders throughout the process to keep everyone apprised of the product’s progress and to ensure everyone is working toward the same strategic goals. But successful product managers know they must also seek out feedback throughout the product’s development from several channels.
Of course, you can’t listen to everyone all the time, or you’ll end up with too many cooks in the kitchen. And you can’t change your plans too often, or you’ll ship a clunky product with no overarching vision.
So who should you talk to, when, and what should you be talking about? This post will discuss how to communicate with stakeholders at each stage of the product lifecycle, as well as how to secure stakeholder buy-in on your roadmaps.
How do You Communicate Your Product Roadmap with Stakeholders Throughout the Process?
Planning
It’s important to work closely with your executives to understand where you’re headed with your product strategy. Develop a clear product vision and identify the strategic goals that are most important to your organization — your metrics might be based on revenue growth, customer acquisition, reducing churn, etc. If you and your stakeholders can agree upfront on vision and strategic goals, there will be less confusion about product priorities later on.
Use a high-level roadmap to talk your executives through a handful of themes that you’ve identified as most important for your upcoming planning period. How far out you plan will depend on your industry, company size, and culture.
Prioritization
After you’ve agreed on your strategic goals and identified a set of themes that will help you achieve them, you can start prioritizing specific initiatives within those themes. This is where open communication with department heads in engineering, sales, marketing, and customer support becomes important. Discuss their top priorities and determine together how those priorities fit into your larger themes and strategic goals. If you can involve your stakeholders in the prioritization process, they are much more likely to be on your side.
Use a structured thought process to evaluate potential initiatives, such as the Effort versus Value model. (You can find more ideas for modeling your roadmap in our free book: Product Roadmaps: Your Guide to Planning and Selling Your Strategy.) The prioritization technique you use is ultimately less important than the conversation you have.
Product managers often ask us how to handle stakeholders who question why particular projects are being pursued over others. In our experience, the root cause of confusion about product direction tends to be a lack of transparency about how initiatives are prioritized. You can stand your ground by walking stakeholders through your thinking process.
Execution
Once you have prioritized initiatives to reflect your strategic goals and reached a consensus among key stakeholders as to what will be included on the roadmap, it’s time to translate product vision into actionable steps. The roadmap you use now must become more detailed. You’ll want to allocate resources for each initiative, assign ownership of initiatives to different team members, and designate release dates.
Make sure each team within the engineering department knows what they are working on and understands how their projects contribute to the bigger picture. You might find it easiest to create custom roadmaps for technical audiences that are more granular than those used at higher levels of the organization. When using multiple roadmaps, make sure the color-coding and tagging are consistent.
You might find that project management tools are best suited to this phase of the product lifecycle. However, project management tools and product management tools are not mutually exclusive. Your developers will benefit from using project management tools, which communicate stories and tasks, in conjunction with product roadmaps, which communicate the strategic direction of the product.
Release
Once plans have been determined, and engineers have been set in motion, it’s important to make sure all parties in your organization are on the same page. Schedule meetings with sales, marketing, customer support, etc., to explain what’s coming next.
Use a high-level roadmap that communicates product direction, and be sure to exclude specific dates when presenting to customer-facing teams. The marketing team should understand the positioning of the new product or feature set so they can successfully bring it to market. And the sales team should understand how the product will solve customers’ problems so they can show prospects its value. As an organization gets very large, it becomes much more logistically challenging to include every single person from these departments, but you should involve the directors and managers so they can then pass the information on to their respective teams.
Providing self-service access to the roadmap is another way to build consensus and get stakeholders on your side. Software like ProductPlan allows you to build and store roadmaps in the cloud, as opposed to emailing around slide decks or spreadsheets that might or might not be up-to-date. With self-service access, teams can check in independently at any time and remind themselves of the current plan. This can bridge a lot of communication gaps, and it also might prevent awkward conversations with stakeholders telling you, “I didn’t know we were doing that.”
Strategies for Getting Stakeholder Buy-in on Your Roadmap
As a product manager, you will have to present a roadmap to different audiences. If your audience is comprised of executives, your goal will likely be to get them to buy into your strategy or green-light your plans. If your audience is some other segment of your organization, your goal will likely be to communicate the product roadmap direction and build consensus.
In either case, you need to be clear and persuasive so stakeholders walk away understanding your strategy and agreeing with your priorities. Here are some tips:
Come Prepared
What exactly does good preparation for presenting a roadmap look like? Creating the document alone is not enough; you should be prepared to tell a convincing story and justify why every initiative on the roadmap deserves to occupy space.
- Structure your presentation: Much like how you go about building a roadmap in the first place, a good presentation begins with the big picture and then narrows down into the specifics. At ProductPlan, we are big fans of the “why, how, what” framework. Start with the “why” — share your strategic goals — before jumping into a more detailed explanation of “how” and “what.”
- Be concise: If you can’t communicate your roadmap concisely, then you probably haven’t distilled a clear enough product strategy in the first place. Make the takeaways from your presentation obvious. Avoid wordy presentation slides and keep your verbal communication clear and direct.
- Anticipate objections: Be prepared to respond to concerns as to why some initiatives are being pursued over others. This goes back to knowing your market and using a rigorous prioritization framework. If your methods are truly robust and data-driven (as opposed to based on your gut feeling), then you should have no problem justifying your priorities to stakeholders.
- Provide specific examples: Specific examples are some of the most powerful tools in your persuasive arsenal; use them liberally. Be able to describe your initiatives in terms of how they will benefit customers or relieve pain. Will a feature you’re building save customers time and money? Cite a customer interview or show data from your analytics tools as evidence.
Know Your Audience
Knowing your audience is a key principle for any type of communication, and roadmaps are no exception. Bottom-up communication, such as presenting strategic goals to executives, follows a very different protocol from top-down communication, such as presenting specific plans to developers.
Tailor the amount of detail shown: In executive-facing roadmaps, focus on high-level themes and strategic goals. Your discussion should be around the market space, customer data, and potential return on investment for new projects. At lower levels of the organization, your roadmap needs to transition from theoretical to actionable. Engineering roadmaps, for example, need to communicate specific tasks, requirements, and deadlines.
Use appropriate language: The language you use on your roadmaps should be appropriate to those who will view it. If your audience is non-technical, use layman’s terms to describe features and title initiatives; avoid jargon or buzzwords. In roadmaps that will be widely distributed, do not use acronyms or abbreviations that are not commonly known outside your industry.
Communicate Status
Roadmaps should generally communicate your high-level strategy, but when meeting with your stakeholders, there is no avoiding some discussion of specific details and deadlines. Your executives will want to know the status of your current projects, how you’re allocating your resources, and how the status of those projects could change if your resources were allocated differently. The reality is that your stakeholders want to see new features released and will be eager to know how close you are to getting there.
- Include the “percent complete” for each initiative on your roadmap: Include the high-level completion status of each initiative on your roadmap. Perhaps the re-design of your billing page is 60% complete, and the launch of your new account management system is 30% complete. By providing these details on the roadmap, you may spark key conversations around how the initiatives are dependent on each other and what can be done to move around resources or reprioritize projects to push them along. Then, as necessary, you can dig in deeper and walk your stakeholders through the specifics.
- Filter your initiatives by status: Another common approach is to use a tagging or color-coding system to layer in information about the status of each initiative without cluttering your roadmap. For example, you may choose to distinguish planned, approved, in-development, and completed initiatives from each other through color schemes or tags. You may also find it helpful to filter your roadmaps along with these parameters, creating distinct views based on completion status so your stakeholders can clearly understand where everything stands.
- Archive older versions of the roadmap: Finally, be sure to save early versions of your roadmap as well as roadmaps from years past. By creating an archive of old roadmaps, you can easily track which initiatives have been completed, delayed, pushed back, or canceled. You can also use this database to analyze how your strategy has changed over time, and if anything goes wrong, you will be better able to identify and correct the decisions that led you off course.
Utilize Visuals
People remember only a small percentage of what they hear, so visual aids are crucial to keeping your audience’s attention and ensuring your key points stick in their memory. Your visuals should supplement and clarify what you say verbally, not present new information. Avoid putting up wordy or complicated slides — they compete for attention and detract from the speaker.
- Use words sparingly: Stick to short titles and descriptions for initiatives, and make sure they’re big and easily legible. Remember, the more text you add, the less likely things are to be read.
- Incorporate color schemes: Use color schemes to show how initiatives relate to one another and to larger strategic goals. Include a legend so people can easily see what colors represent, and be sure to choose colors that are different enough to stand out from one another.
- Show the hierarchy of initiatives visually: Do a certain cluster of updates falls within a particular theme? Are some initiatives part of one release and other initiatives part of another release? Plot these relationships visually by grouping initiatives into containers or swimlanes.
Takeaways
Definitions of product managers’ jobs can vary wildly, but most people agree that a product manager’s primary role is to drive the development of the company’s products. And although it is far less emphasized in job descriptions, an equally important responsibility of a product manager is addressing how to communicate the product roadmap — with all relevant constituencies, at every stage of the product’s lifecycle — to ensure that the product has the best chance of being successful.
After all, no product manager can single-handedly manage every detail and task of a product’s development. Any successful product is the result of a talented, well-informed team working together toward a common strategic objective. With this in mind, a smart product manager should devote at least as much energy and focus to communicating iteratively with their teams and stakeholders as they do to the other tasks necessary to bring their products to market.
