Do you ever feel like breaking up with your roadmap? In his talk from #mtpcon San Francisco, C. Todd Lombardo takes on a topic that is emotional to most of us as product managers – the product roadmap.
Why do we ship the wrong thing?
In modern product management, we have multiple frameworks and tools designed to help us understand what to build. We have lean startup methodologies that teach us to “Build, Measure, Learn” but somehow we still ship products that don’t gain traction. C. Todd points out that while we like to think we’re following these best practices, what actually happens in most teams is “Build, Ship, Build, Ship.”
The roadmap gets a lot of blame for this culture. Whether people think the roadmaps themselves are bad, or think they are good tools that are simply misunderstood or misused, it is pretty clear that there is something wrong with roadmaps.
What a roadmap isn’t
A roadmap can be many things. But more important than what it is, is what it is not. A roadmap is not a release plan. It is not a listing of product features. C. Todd told the story of a company called Wodify, who posted their roadmap publicly. They listed all of their features and the dates they would be released on their website, and quickly started having trouble meeting those commitments. After many missed dates and slipped projects, they finally removed the dates from their roadmap.
What a roadmap Is
A roadmap is more about communicating your product strategy than it is about communicating features and dates. It is a statement of intent and direction – like a literal road map for traveling, it states a destination we’re headed towards and provides options of a path to get there. A roadmap also tells us how we will realize our product vision. Your roadmap tells you about the outcomes you’re trying to achieve. Your release plan tells you the outputs that you’ll ship along the way.
A product roadmap is a prototype for your product strategy. Janna Bastow
The 5 components of a roadmap
Vision
Your product vision tells us how a future world will benefit from your product when it is fully realized. A product vision should align with the company vision—and in a startup it probably is the company vision—and we as product managers own what that vision is.
Read: Beating the drum of your product strategy tune by Megan Murphy
Business objectives
Clear business objectives should flow from your product vision. Objectives and key results tell what your product will accomplish, and how it will be measurably different as you fulfill your roadmap.
Timeframes
The third component of a roadmap is timeframes. Timeframes should allude to prioritization, give sequencing and guidance on timing, but should be broad to allow for flexibility. While a roadmap shouldn’t have delivery dates, showing a clear priority and broad timeframes helps frame the conversation.
Disclaimer
A disclaimer detailing the constraints and the likelihood of change is an incredibly important part of the roadmap, and shouldn’t be left off. The disclaimer protects you from accusations of broken promises, and makes it clear that change is possible, even likely.
Themes
At the center of your roadmap are themes. Themes are an organization of work-areas for your product, outlining the customer or business outcome you are trying to achieve They are not just a listing or grouping of features.
What are themes?
Themes are typically a combination of problems, needs, and objectives. But when looking at the problems, C. Todd recommends really digging in and asking “Why?” He gives a simple example of water on the floor. If you stopped at solving the problem of water on the floor, your solution would be to mop it up. But if you keep digging and understanding how the water got there in the first place, you’d realize what you really had was a problem with infrequent maintenance on a pipe and focus on adjusting your inspection schedules instead. That is a very different solution than mopping up water.
Every theme on your roadmap should have a problem, an objective, and even some potential ideas you have to solve those problems. In practice, this changes how your roadmap looks. Rather than being a list of features, it might start from an objective of reducing support costs, and then show themes that might help reach that objective such as improving invoicing options or expanding payment types. By removing the details of what features will be built to fulfill these themes, it gives the team the freedom to figure out how best to solve the problems presented.
So what are we going to build?
To understand where features fit within a roadmap, you have to understand that there are three key elements: outputs, outcomes, and impact.
- Outputs are what you produce. They are the features.
- Outcomes are the behavior change you are trying to drive. What problem does that feature solve? If we solve that problem, what is the outcome we want to see?
- Impact is the business metric you are looking to increase or decrease with this outcome. How do we know we’ve actually done what we wanted to do?
When you combine the outcomes and the impact, you get your objectives and key results. At that point, your theme becomes a headline for your problem or need.
Listen to outcomes Over Outputs – Josh Seiden on The Product Experience
All of these elements fit into a strategic hierarchy. Your business vision produces your product vision. Your objectives show how you are going to achieve that vision, and themes followed by features tell how you expect to reach those objectives. But while you may have features and experiments on a release plan, your roadmap contains the vision, objectives, and themes.
Once you understand the inputs of a roadmap, you can start building it. C. Todd shared simple steps on creating your roadmap.
- Gather inputs from all of your different channels: support, sales, internal teams – there are a variety of places to get the data
- Organize and prioritize the data into themes
- Place themes into timeframes – Q1 / Q2 / Q3, Now / Next / Later, or whatever horizons you choose
- Map the highest priority themes into a sprint plan or release plan
Gaining alignment like a crisis negotiator
Getting alignment on your roadmap between all of the different stakeholders can be a difficult task. They all want different things and it can be hard to get everyone to the table. C. Todd recommends using a tactic called shuttle diplomacy: rather than pulling everyone into the same room to battle it out, map out your stakeholders and work one on one with each one to understand their needs and objections. Once you have a handle on all of their ideas, opinions, and motivations you can draft your roadmap, and then bring everyone together to finalize.
C. Todd offered a few additional tips to help you get alignment with your stakeholders
- Say “no” without saying “no.” Ask “How are we going to do that?” instead
- As you work through items, aim to get to the point where your stakeholders can say “that’s right.” “That’s right” is better than “you’re right” – it isn’t about you.
- Forget getting to “Yes” – get to “No” first. Getting stakeholders to say no will help you see what roadblocks might exist, and every “no” will help you understand what you need to do to get to “yes.”
Separate the outcomes and the outputs
C. Todd finished by demonstrating the difference between and output and an outcome, and reminded us that outputs are easy. We can ship features all day long. But achieving outcomes is much more difficult. Product management is not project management. We have to separate the outputs in a release plan from the outcomes we want to drive in our roadmap, and as product managers those outcomes are much more important. Because at the end of the day, you might finish a project or a sprint, but your product is never done.
Slides from C. Todd’s talk are available here.
Comments 2