The building blocks of excellent product roadmaps

This piece is an excerpt from “Charting your course: The building blocks of excellent product roadmaps.” For more insights and how-tos on roadmapping, download the full ebook.

Roadmaps aren’t stand-alone documents—they’re the culmination of several Product Excellence best practices, including: 

• An organized system for collecting and organizing feedback from customer-facing colleagues and removing bottlenecks around customer feedback.
• A transparent process for surfacing valuable insights hidden within that feedback.
• An objective method for using those insights to prioritize tasks on the product roadmap.
• A closed-loop system for sharing the roadmap with stakeholders and customers and for obtaining further feedback.

Below, we dive into the building blocks that all good roadmaps tend to have in common. 

Building block 1: Your roadmap should reflect desired outcomes

Roadmaps should reflect the desired outcomes the product is trying to achieve rather than just outputs. What exactly does this mean? Outputs are the stuff we produce for a customer (like car seats for babies) while outcomes are the difference our stuff makes (like keeping kids safe in cars). In an ideal world, the roadmap effectively communicates both outcomes (the why, and the problems we are solving) and outputs (the how). 

Focusing on the “why” in your roadmap instead of just the “what” communicates more clearly where you are headed and what success looks like. An outcome roadmap is more stable over time with only the tactics employed to reach those outcomes shifting as different approaches are tested.

Still not sure if you’re focusing on outcomes or outputs? Here are a few ways to tell, courtesy of Product Roadmaps Relaunched by C. Todd Lombardo.

Focusing on outcomes

Symptoms of shipping only outputs

How to focus on outcomes

Building block 2: Your roadmap is a product of cross-functional collaboration

Collaboration is one of the keys to roadmap success. It is a best-case scenario when stakeholders—leadership, sales, marketing, engineering, and more—understand what is on the roadmap and why. Even better, their needs are considered, and they know why their request has been included (or not). Here’s why: 

• Where the product is headed (and why) impacts everyone in the company. Thus, it makes sense to build a roadmap that considers the needs of cross-functional stakeholders—not just the product team.
• Other departments can offer valuable insights. Stakeholders have knowledge and expertise that stretch outside of the product team’s domain. Unlike sales, customer success, and support, for example, product managers don’t spend their days talking directly to users. Getting these insights from customer-facing teams is essential for creating a roadmap that focuses on real customer needs and concerns.
• You need buy-in from stakeholders. Oftentimes, product managers do not have the authority to push through product decisions without explanation. Instead, they must use influence and soft skills to earn support. Engaging stakeholders from the get-go helps uncover fresh insights and reduce risk, and getting their buy-in early ensures that significant resources and time don’t go to waste.

Stakeholders should be involved throughout the roadmap process. Set up a regular meeting cadence, send emails updating the team about any changes, or give them access to the roadmap so they can self-serve anytime they’d like.

Regular communication about the product roadmap creates an agile product process. Stakeholders involved can course-correct their tasks and projects if they know that there are delays or changes.

Get your copy of “Charting your course: The building blocks of excellent product roadmaps”.