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.
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:
The hacks you choose should align with the goals you are trying to achieve with your roadmap.
The following are the most common audiences (or “users”) of Product Roadmaps:
The following are the stages of Product Roadmap development. Each stage will require a roadmap communication with a different level of detail and audience.
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.
What Executives care about:
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.
Audience: Engineering and Customer-Facing Teams (Marketing, Sales, Customer Support)
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.”
Audience: Customer-Facing Teams (Marketing, Sales, Customer Support)
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.
Audience: Everyone (or team-specific boards if there is room)
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.
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.
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.
An information radiator used by SAAS company Panic
Audience: All Teams (Can be team-specific if there is room)
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.
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.
Audience: Any Team (Team-Specific. Common for Engineering, Product, & Marketing)
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 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.
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.
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).
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.
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.