How to Communicate Your Product Roadmap to Stakeholders

As a Product Manager, the Product Roadmap is your greatest tool for tracking and communicating both long-term strategy and short-term objectives. Just like with any other product, though, we want to maximize the value our roadmap creates for its users without unnecessary time or effort. To that end, we will look at 7 hacks Product Managers use to effectively and efficiently communicate their Product Roadmaps to the organization. Before we jump in, let us define the main goals of a Product Roadmap and who the users will be.

Goals of the Product Roadmap

A survey of Product Managers was done in September 2015 by Jim Semick’s team at ProductPlan that revealed the following top goals of Product Roadmaps:

1. Communicating Product Strategy
2. Planning & Prioritizing Products and Features
3. Reaching Consensus on Product Direction
4. Communicating Milestones
5. Managing Product Backlogs

The hacks you choose should align with the goals you are trying to achieve with your roadmap.

Users of the Roadmap

The following are the most common audiences (or “users”) of Product Roadmaps:

1. Executives
2. The Product Team
3. Engineering
4. Customer-facing Teams (Sales, Marketing, Customer Support)
5. Customers (Typically in Enterprise software)

Stages of the Roadmap

The following are the stages of Product Roadmap development. Each stage will require a roadmap communication with a different level of detail and audience.

1. Planning - Executive and Product teams align on strategy, goals, and high-level themes for the roadmap.
2. Prioritizing - The Product team gathers inputs from other teams and prioritizes initiatives on the roadmap.
3. Executing - Engineering and other teams use a more detailed roadmap to track tasks, deadlines, and progress.
4. Releasing - All teams use the roadmap to understand overall context and plan for go-to-market, customer-facing, and other release initiatives.
5. Reviewing - Executive teams and the rest of the organization use roadmap reviews to understand changes to the roadmap and the outcomes of previous releases.

Understanding what each team wants at each stage will help you choose the best and leanest method of communicating the Product Roadmap to that team. The following are seven strategic hacks organized by medium. They include the stage of Product Roadmap creation, the audiences they will address, and what those users want.

Product Roadmap Presentations & Meetings

Simple Executive  Roadmap Presentations

Audience: Executives

‍Stage: Planning/Review

‍What Executives care about:

• High-level strategy & vision
• Progress against high-level targets
• Data validating customer interest, market size, and market positioning

What to use: For Roadmap Planning meetings with executives, use a simple PowerPoint or Keynote presentation highlighting the main Product Roadmap themes, the high-level goals about which you need alignment on, and high-level supporting insights from data.

TaskRabbit’s product team creates weekly product review presentations to the executive that is shared with the rest of the company. According to Andy Jih, TaskRabbit’s former Director of Product, “[at the meeting], we review how the various products are performing with regards to our business goals, present the Product Roadmap, and then dig into analyzing how features performed.”

‍What NOT to use: Avoid spreadsheets, text-filled slides, or cluttered visuals. Having research data in spreadsheet charts or appendices slides on-hand is great to answer questions in the meeting, but keep the core presentation very sparse. Visuals should reinforce what you are saying, not add to it as that can become distracting.

Short Team Engagement Meetings

Audience: Engineering and Customer-Facing Teams (Marketing, Sales, Customer Support)

‍Stage: Prioritizing

‍What these teams want: Transparency in product prioritization and to feel engaged in the prioritization process.What to use: In addition to collecting data and feature requests from the different teams, set up short, to-the-point, 10- to 15-minute meetings with key stakeholders from each team. Run through the product features being prioritized, the 2-3 key data points supporting each feature, and identify potentially overlooked positive and negative impacts for the team. Short meetings ensure teams do not run-on arguing their points, but will still clarify decision inputs and get them engaged in the process.

‍What NOT to use: Avoid committing to prioritizations in the meeting. Avoid run-on meetings or polished presentations. Keep things simple and to the point. The goal is to quickly receive input and show high-level decision criteria from other sources they may not have considered. This helps when you have to say “No.”

Simple Release Presentations

Audience: Customer-Facing Teams (Marketing, Sales, Customer Support)

‍Stage: Releasing

‍What Sales cares about: Benefits and competitive comparisons they can share with customers and prospects

‍What Marketing cares about: Product positioning and main stories for new products/features

‍What Customer Support cares about: Specifics on current release history and potential breaking changes in the future

‍What to use: For pre-release meetings with customer-facing teams, use a simple PowerPoint or Keynote presentation to get the basic information each team needs to execute the launch and post-launch. Show a short demo (pre-screen recorded if you can) as early as possible - a demo is worth 1,000,000 words. Keep presenting short and leave more time for questions. Links to reference documents (PRDs, Wikis, etc.) with more detail will help avoid getting bogged down in ultra-specific individual questions.

‍What NOT to use: Avoid overloading with information above the basic talking points and specific action items each team needs. A longer Q&A period is better than a long presentation before knowing what information the teams actually want.

Office Visual Product Roadmaps (Information Radiators)

Wall Roadmap: Sticky Notes/Markers on Wall/Whiteboard

Audience: Everyone (or team-specific boards if there is room)‍

Stage: Building/Release

‍What to use: To keep the roadmap easy to update and understand, colored sticky notes or markers on a whiteboard are the quickest to update regularly. For the general roadmap board, the point is to communicate the very high-level, overarching product roadmap with simple, easy-to-understand visual cues about progress, priority, and release orders. User stories or feature/product titles can be placed on the sticky notes for quick reference.

‍What NOT to use: Avoid stating specific expected release dates, since these will likely change and Sales or Customer Support may communicate these to customers, thinking they are committed. Using more vague date markers such as quarters or months is possible, but still ensure that there is a distinction between committed and expected release dates.

Example Wall Product Roadmap 1: Aconex’s “Zoom-level hack”

It can be difficult to manage different levels of detail on the roadmap, and multiple boards can be tough to update or reference. This board from Ben Birch at Aconex posted on Agile Board Hacks allows the team to track the progress of epics (larger features/stories) along the outside, with the smaller user stories/features for the current sprint on the inside.This format avoids the need for multiple boards for the roadmap and sprint, making it easier to update and reference.

Example Wall Product Roadmap 2: Manual + Online Board

According to TaskRabbit’s TechRabbit blog, the team syncs their main board to an interactive Trello board online where anyone in the company can subscribe to updates. The manual roadmap board is a quick reference, while the Trello or other task management board (see software tool hacks below) lets teams dig in for more detail.

Digital Information Radiator

An information radiator used by SAAS company Panic

‍Audience: All Teams (Can be team-specific if there is room)

‍Stage: Executing/Releasing

‍Requires: Large Display Monitor or other signaling device

‍What to use: This will depend on the tools you use for roadmapping, project management, and the skills of your tech team. Even if you already track your roadmap on Trello, Unfuddle, or another Product Management Tool , displaying the overall roadmap on a physical monitor is an easy way to communicate progress to the team without having to write it out manually.

You will want to ensure that only the information needed is shown, that color-coding is used to clarify progress and feature groups, and that the necessary information is easy to read. If your tech team is more skilled, they can develop an internal dashboard and roadmap visualization that is automatically updated based on the systems you use for project management (i.e. JIRA, Unfuddle, Trello, etc.).

‍What NOT to use: Avoid showing unnecessary or potentially confusing detail, such as specific release dates if customer-facing teams have access, or sprint assignments and ticket information if it is for teams outside of engineering.

‍Sales/CS and Release Dates: If the Sales or Customer Support teams want to be able to communicate roadmaps to customers, a color-coding or badge system could be used with this or the manual map to indicate that a release is 100% committed rather than just expected. This will help with sales and support and help prevent confusion and disappointment from customers who were promised something that couldn’t be fulfilled.

Word of caution: Don’t go overboard

There are plenty of visually compelling information radiator boards out there (see above), but if your main objective is to communicate and drive buy-in for your Product Roadmap with minimal setup and maintenance, an automated simple tool or ready-made SaaS solution is probably best.

Product Roadmap Software

Using Product Roadmapping/Project Management Software to Communicate the Roadmap

Audience: Any Team (Team-Specific. Common for Engineering, Product, & Marketing)

‍Stage: Prioritizing/Executing/Releasing

Product Roadmapping Tools

These tools allow you to display Product Roadmaps visually with multiple custom views of the roadmap for different teams or purposes. Typically, these tools are cloud-based and can integrate with your current ticket tracking, customer feedback, analytics, customer support and other tools for automatic updating and reference linking.

There are many tools, but each is better for different levels of detail, integrations, or focus. For example, Uservoice links ROI, revenue, and customer satisfaction data to product prioritization, while Trello is a very simple card-based board for assigning tasks and organizing by teams or projects. Other tools focus on visualization or integration with JIRA, CRMs, and other tools from your Engineering and Marketing teams. Which one you choose will depend on your needs and the integrations you want to use.

Project Management Tools

Project management tools focus on resource allocations, task dependencies, and schedules. Although they are important for managing and executing roadmaps, and they can be used for visualization, they are often overkill for roadmap communication. These tools include traditional tools, such as Microsoft Project, as well as more modern cloud-based tools, such as Basecamp or Mavenlink.

According to the 2015 survey on how product roadmaps are built, spreadsheets like Excel were the most commonly used tools for roadmaps after presentations (e.g. PowerPoint). Most people know how to use Excel, but spreadsheets typically provide too much unorganized information in a less-digestible format than simple roadmap visualizations.

‍What to use: Use products with simple visualizations that can be tailored for each team. Pick ones with links and integrations that make sense for your current tools, and only those that make life easier for updating and tracking.

‍What NOT to use: Avoid tools that create more work and have many required fields that do not communicate information needed by the teams.

Fun Ways to Communicate the Roadmap

Celebrations, Bells, & Launch Parties

Communicating your Product Roadmap does not have to be so formal or data-centric. Emotion and morale are important drivers of long-term buy-in and engagement with your team’s product strategy and decisions.

Try taking a tip from sales teams

While working at HourlyNerd, after every sale, a bell was rung by the sales rep who closed the deal, hitting the bell once for every thousand dollars in the project. Larger deals also had a song specific to a sales pod played after the bell. This instantly boosted morale and provided everyone with an ongoing pulse for how the project rates and sizes were doing. When it was quiet for a while, we knew something was not working. When that first 100-bell ring hit, we knew something was definitely working.

It does not need to be a bell, but a nice ring or notification for a deployment or metric being hit towards an OKR is a quick and fun way to show that your product releases are tracking against the roadmap to the rest of the organization. Tying this to an information radiator dashboard can help as well (a nice celebratory song or video on the dashboard can help give acknowledgement to the teams responsible).

Celebrate big launches and milestones

Larger product launches or metric milestones are opportunities to communicate progress and reinforce the product strategy is working. Especially after engineering teams sprinted for weeks to hit a release date, a celebration can turn that experience and future sprints into positive experiences. Celebrating this with the team and the broader organization can boost morale, but they also are opportunities to refocus the organization on the reasons for the current product strategy or even on changes if new opportunities arise.

Conclusion

If you understand your main stakeholders, what they need and want to know, and what tools you have available, you can leverage  these hacks to get your roadmap out there as quickly and efficiently as possible.  Mastering these strategies is a big accomplishment - after all, half of the job of a Product Manager is communicating and aligning the organization with the product strategy. Better get hacking.

‍