Product Roadmaps · Relaunched
Summary at an early stage of ¡A comer!
Chapter 1 · Relaunching Roadmaps
A good roadmap is not so much a project plan as a strategic communication tool, a statement of intent and direction. Product maps are all about creating a shared understanding of where you are going and why.
Product: Whatever form of value that you deliver to your customers.
It all starts with the bicycle. Some of the first roadmaps where created (around the 1890’s) to show how to bike from one part of New York City to another.
Roadmaps should be tied to a compelling vision of the future:
“This is our vision of why we’re here and what we’re trying to accomplish for clients, and here’s the roadmap that’s going to help us progressively get there”.
A roadmap is a strategic document that should offer guidance to your teams on what to focus on.
Chapter 2 · Components of a Roadmap
Primary Components:
- Product Vision: Your guiding principle
- Business Objectives: What kind of product do we need in order to attain those business goals?
- Themes: The key problems that customers face. Themes focus on outcomes rather than outputs.
- Timeframes: Broad Timeframes avoid overcommitment. Focusing on dates as the primary measure of success diverts attention from the iterative and uncertain process of innovation so critical in new product development. Broad timeframes like calendar quarters or even Now, Next, and Later provide guidance while preserving some flexibility.
- Disclaimer
Secondary Components:
- Features and solutions: How you intend to deliver on your themes
- Confidence: Level of confidence you have in your ability to address each item or theme on the roadmap in the next release.
- Stage development
- Target customers
- Product areas
Examples:
Chapter 3 · Gathering Inputs
Understand where your product is in its lifecycle
- New: “Validation”
- Growth
- Expansion: “Product line expansion”
- Harvesting
- End of life
Understand your ecosystem (Lean Canvas):
- Problem and solution
- Value proposition
- Unfair advantage
- Key metrics
- Customer segments
- Distribution Channels
- Costs
- Revenue model
- Key partners
- Key resources
Define the Problem and the Expected Outcome of the Solution
Trying to create a product roadmap without a basic understanding of the product’s domain and its users will leave you groping around in the dark designing for fictional scenarios with biased assumptions.
One very rough way to determine a product person’s level of experience is that the novice focuses on features, while the seasoned pro focuses on problems. The best product pros take this to the next level and ask, “If we solve that problem, what’s the outcome we want to see?”
Gathering Input from Your Customers
One of the most critical parts of the effective product development is to properly identify who your customers are, and then o truly understand and empathize with them — their jobs, wants, needs, obstacles, frustrations, emotions, and more. Validate what the problem is and how best to solve it.
Chapter 4 · Establishing the Why with Product Vision and Strategy
Vision: is why your organization exists. It can be decomposed into the benefits you hope to create through your efforts.
Mission: the intent you hold right now and the purpose driving you to realize your vision.
Values: Intended to guide behaviors. A compass that tells you which direction is north or south, but not which direction to travel; you must make that decision yourself.
Product vision: clarifies why you are bringing a product to market, and what its success will mean to the world and to the organization. It is the destination you plan to reach.
Product Strategy: How you Achieve Your Vision
The bridge that connects your high-level vision to the specifics of your roadmap. For many companies, the product strategy is the main contributor to their overall business strategy.
If your product vision includes meeting the needs of a group of people, then your product strategy simply makes that more explicit and concrete by explaining a bit about how. Usually, this takes the form of objectives. i.e. SpaceX hopes to meet its lofty vision of “make going to Mars a reality in your lifetime”.
Objectives and Key Results
Identifying business objectives that tie to your vision is critical to making that vision a reality.
The premise of the OKR (objectives and key results) framework is that objectives are specific qualitative goals, and key results are quantitative measures of progress toward achieving those objectives.
Here are a few guidelines on OKRs as they apply to product roadmapping:
- Everything on the roadmap must be tied to at least one of your objectives.
- Stick to a manageable number of objectives; from our experience and research, fewer than five seems to be most effective.
- Focus on outcomes, not output.
Think “What kind of product (solution) do we need to attain those business objectives?” For example, work on improved usability will increase customer lifetime value (LTV) by decreasing churn. The goal for the customer is a better user experience; the goal for the product is decreased churn and increased LTV. The duality we mentioned previously is balanced.
The 10 universal business objectives. While every product team has unique metrics, there are some patterns:
Sustainable Value:
- Support the product’s core value
- Create barriers to competition
Growth:
- Grow market share
- Fulfill more demand
- Develop new markets
- Improve recurring revenue
Profit:
- Support higher prices
- Improve lifetime value
- Lower costs
- Leverage existing assets
OKRs: Go in a direction (Business objectives) to reach this specific destination (Key results) by an improvement to this metrics (KPIs)
In the next example, a company expresses its product strategy for the next year in three objectives, each with measurable success criteria:
- Launch new features or services that realtors will pay more money for.
- Improve the feature sets of our existing plans so more users will purchase.
- Improve our team functionality to better meet the needs of team leads.
Each of these themes is tied to an objective that can then be measured by specific key results, and their roadmap reflects this. This internal objectives-driven approach to roadmapping makes direction crystal-clear for internal teams. In this case, rather than being based on customer needs, each objective focuses on a measurable business benefit that work is designed to achieve (higher average sale price or higher renewal rate, for example). This “outcome-based” roadmap makes clear why certain work is important”
How you do know if you have achieved those objectives? You have metrics to track your progress. And who doesn’t love a good metric?
Key results (and metrics)
One of the most important things is to define how the success of that product will be measured, or its key performance indicators (KPIs). These KPIs are often the metrics you are using to measure the key results from your OKRs.
Tying this back to Contactually’s (a fictional company) objective of “improve the feature sets of our existing plans so more users will purchase,” key results here could be “an increase in user base by 5% over the course of a specific timeframe” (a quarter, year, etc.) and feature-specific metrics such as “time to compose and send an email is reduced by 10%,” indicating that the usability of that part of the product has been improved. Note that there can be multiple key results to each objective, as it may take different measures to determine whether an objective is met.”
Outcome versus Output
“Well-known Harvard Business Review blogger Deb Mills-Scofield gives a great example distinguishing what you’re delivering (output) from the reasons why (outcome): “Let’s define outputs as the stuff we produce, be it physical or virtual, for a specific type of customer — say, car seats for babies. And let’s define outcomes as the difference our stuff makes — keeping your child safe in the car.” Her summary is the best way to keep these terms straight: “Outcomes are the difference made by the outputs.”
Books to read on the topic:
- Measure what matters · How Google, Bono, and the Gates Foundation Rock the World with OKRs.
- Radical Focus · Achieving your most important goals with Objectives and Key Results.
- Platform Revolution · How Networked markets are transforming the economy and how to make them work for you.
Case Study: Space X
“In September 2016, Elon Musk, CEO of SpaceX (and Tesla Motors), announced his roadmap to colonize Mars. His presentation and roadmap overview are a great example of how product vision, strategy, business objectives, and themes all come together.
PRODUCT VISION
Let’s start with SpaceX’s published corporate vision statement:
SpaceX was founded under the belief that a future where humanity is out exploring the stars is fundamentally more exciting than one where we are not. Today SpaceX is actively developing the technologies to make this possible, with the ultimate goal of enabling human life on Mars.
This statement contains elements of vision, mission, and values. The distinctions are not important here; what is important is that Musk outlined an aspiration for the company, a reason why it exists, and a clear statement of how we all will benefit if they succeed.
To make the benefit absolutely clear, he pointed out:
The alternative to an extinction event is to become a multi-planet species.
Using the word product somewhat loosely, the first major component of SpaceX’s product vision is to “create a self-sustaining city on Mars.” Why Mars? Tying directly back to the organization’s mission, Elon describes it as: “the best option among nearby planets for a self-sustaining civilization.”
BUSINESS OBJECTIVES
“Musk begins his discussion of strategy by outlining the key problem with getting people to Mars: money. He estimates it would currently cost around $10 billion per person. There is therefore “no overlap between people who want to go and people who can afford to.” To make emigration to Mars market-viable, SpaceX would have to “drive the cost to the equivalent to a house in the US — about US $200,000.” That sounds like a business objective with a built-in key result.”
THEMES
“Musk then asks, for this strategy to be viable, what would need to be true? His team has done the research and defined the themes this way:
- Full spacecraft reusability
- Refueling in orbit
- Propellent production on Mars
- Right Propellant
“These four themes don’t describe the specific technology or solution, but are all subgoals of the affordability objective. Each of these subgoals can also be a theme (we’ll discuss sub-themes further in Chapter 6) that can become part of the roadmap.”
KEY RESULTS
“The key results for the objectives tied to the first theme of “Full spacecraft reusability” could be:
- The overall market cost is $200,000 or lower.
- The reusability of rocket transportation is 90% or greater.
- Tons of propellant can be produced on Mars.
Chapter 5 · Uncovering customer needs through themes
We related the product professional to an executive chef, and compared building products to crafting meals. In this metaphor, the roadmap is equivalent to the chef’s menu; it defines what will be delivered.
Your roadmap helps you match those customer needs with what’s important to your business to thrive and grow. Start by understanding and organizing the most important customer needs first.
Distinction between Product Roadmap and the Release Plan
Your roadmap should be a high-level view of what needs and problems your product should solve, while also helping you confirm why. In contrast, your release plan should detail how you will solve them. The product roadmap should not be about developing solutions or defining what your product will look like. Leave that to the release plan!
We use themes and subthemes to express customer needs. A theme is a high-level customer need. A subtheme is a more specific need. Themes can stand on their own, but they can also represent a grouping of subthemes.
So, again, themes and sub-themes represent the needs and problems your product will solve for. A need is generally something the customer doesn’t have yet, whereas a problem is something that’s not working right (with the existing product, or whatever substitute they might currently be using). Even though these two terms suggest subtle differences, the important point is that both refer to a gap or pain in the customer’s experience. When identifying the themes and sub-themes for your roadmap, remember to consider both needs and problems from all angles.
Themes help teams stay focused without prematurely committing to a solution that may not be the best idea later on.
In our experience many product teams fail to hit the mark with their products because “so many features in today’s products are solutions without a clear problem to solve.” Themes are so important is because they force you to focus on the need before you even start to consider solutions — and then to evaluate how well each potential solution meets that need.
One of the initial problems that Lyft set out to address was that in a hectic urban environment, it was generally hard to find a taxi (Theme) (in addition, of course, to other taxi-related problems, like not accepting credit cards, dirty cabs, unpredictable fares, etc.) (Sub-themes)
Imagine for a second your user is standing on one side of a rushing stream, trying to figure out how to cross without falling in. In order to do so, they need to choose which rocks they will step on, in what order, to land on the other side safely. Not only that, they’ll want to pick the easiest and most efficient path. In this metaphor, you can think of the stream as representing the user’s “problem” and the rocks as the steps in their journey toward solving that problem.
The steps in the journey map give you zones you can zoom into to understand the user at a deeper level. With this understanding, you can start to define each need or job in more detail. Those needs go on your roadmap as themes and sub-themes.”
The key is to focus on understanding “why” a need or problem is worth solving (or not). The user journey map is a great way to do this because it provides context.
When you get a request for a feature, you can employ the user journey map to make sense of where that need fits into the context of the user experience. Is it a critical path item, or simply nice to have? Is the existence of the unsolved need or problem impeding the user’s journey in a significant way?
Once you understand how and where the customer experiences the need, you can work directly with them to validate the problem and test possible solutions.
To use another metaphor, we can compare building a product to constructing a home. The infrastructure or backend of a product is akin to the foundation, framing, rough plumbing, and electrical of a house. These forms and systems tie everything together and make the house functional. The flooring, windows, furniture, and other finishes are equivalent to the frontend layer that the customer sees and interacts with.
Teresa Torres, Product Discovery Coach, Product Talk3, has developed a visualization for this problem that she says has revolutionized the way teams make decisions. She calls them Opportunity-Solution Trees and we’ve found them a brilliant way to distinguish solutions from the problem, need, or other opportunity they are intended to address — while at the same time tying them together logically.
Teresa says it all starts with a clear desired outcome. Remember those business objectives from Chapter 4: examples such as increasing your conversion rate or customer engagement? Those.(Hopefully you can see where this is going.) What Teresa calls opportunities, we call themes. We share the nomenclature of solutions and experiments designed to validate those solutions.
This hierarchy, similar to what we advocate in this book, simplifies decision-making by separating decisions among objectives, themes, and solutions. Each decision is a comparison among a small number of like things. Working down this hierarchy, level-by-level, allows teams narrow their testing and development efforts to solving one problem at a time.
Using Job Stories and User Stories to Support Themes
Themes are about Outcomes, not Outputs
Relating Themes back to your Objectives
With your strategic objectives clearly defined and approved by all stakeholders, the next step is to make sure that every theme on your roadmap relates directly to your objectives. Look at each theme or sub-theme critically with your team. It’s possible for a theme to link to more than one objective, and that’s fine. In fact, it’s great if a theme can inform multiple goals.
One good way to link themes to objectives is to color-code your objectives, and then tag themes with the associated color.
SpaceX example · Theme Card
One key point we’d like to reiterate: stick to needs when defining themes and sub-themes. You will be very tempted, believe us, to start brainstorming solutions or sketching ideas. Avoid this temptation! Stay focused on the needs at this stage. Defining solutions will come next, and developing them will be a whole lot more fun and effective when you’re confident about why they need to be implemented.
Chapter 6 · Deepening your Roadmap
Using Stage of Development
Different industries and individual organizations use their own terms, but commonly there is a discovery, market research, or R&D.
During that workshop, one of Spotify’s lead product managers shared a version of her roadmap. On the roadmap she’d tagged each item as either “think it,” “ship it,” or “tweak it.” In this simple way, her team was able to indicate the stage of each item on the roadmap to all stakeholders. When a stakeholder sees an item labeled “think it,” they know the theme is still being considered or explored.
Another interesting insight about the Spotify example is that status labels also help differentiate between themes and features. Any item labeled “think it” has clearly not been solved for yet, and therefore by definition is a theme. Any item labeled “ship it” or “tweak it” means that a solution has been chosen, and can therefore be considered a feature.
Communicating Confidence
For example, we might attach a 75% confidence to the Now column, 50% confidence to the Next column, and 25% confidence to the Later column. These confidence percentages represent our level of certainty that we will deliver on those items in those timeframes.
Tagging Product Areas
A software product might have areas such as user interface, platform, administration, and APIs. A product like our garden hose might have weather surface, exoskeleton, water channel, and connectors. Each may have separate sets of details such as stage of development, but more important, each must receive sufficient attention on the roadmap to come together into a fully functioning product that meets customer needs. Each may also have separate business objectives.
Chapter 7 · Prioritizing with Science
Why Prioritization is Crucial
You can never get everything done you would like or even might think is minimally required. Resources are limited, priorities shift, executives have ADHD, and on and on. So if you are not going to get it all done, you have to be very sure you get the most important things done before something changes and your resources are redirected.
Law: Always assume you may have to stop work at any time.
This law is a core tenet of the Lean Startup movement popularized by Eric Reis. In his book The Lean Startup (Crown Business), Reis points out that the reason most startups fail is that they run out of money before they find a viable business model.
You ruthlessly prioritize your work so that you get the most important things done first and begin to demonstrate value quickly.
The inverse of (and antidote to) shiny object syndrome is focus. If you focus as an organization on one set of problems for a strategic set of target customers, you minimize the increasing drag of bad decisions and seemingly small diversions.
Popularity
We truly believe that outsourcing your product strategy to your customers is a mistake in nearly all situations. An inexperienced product manager will, with the best of intentions, rank feature requests by frequency or size of customer. It makes sense, initially. Why not give customers what they ask for? The issue with that is customers can’t often articulate what they need from your product. Yes, a seasoned product person will seek to understand customers and their needs — but this is fundamentally different from asking customers what they want.
Steve Jobs is famous for ignoring market research, saying, “A lot of times, people don’t know what they want until you show it to them.” This perhaps oversimplifies the problem a bit but resonates with our experience. A roadmap made up entirely of customer requests generally results in a product with no focus, unclear market positioning, and poor usability. If you understand what underlying problems motivated your endless list of customer requests, you and your team can usually develop a more elegant set of solutions that render that list moot.
Sales Requests
Your job is not to prioritize and document feature requests. Your job is to deliver a product that is valuable, usable, and feasible.” Similarly, asking for input from your sales team is smart — they have insight into how buyers think and what will get their attention — but prioritizing based on what will help close the deals in the pipeline this quarter is short-term thinking. It may help make the numbers once or twice, but successful product people are focused primarily on how to serve a market rather than individual customers.
Critical Path
As we discussed in Chapter 3, a user journey map provides an opportunity for product professionals to tease out various dimensions at each step in the customer’s journey, including their emotions and state of mind during each moment.
Once you’ve identified those critical pain points, your job is to insert your elegant solution into your potential customer’s path at the exact moment when their pain or frustration is highest.
What is the one thing (or set of things) our solution needs to get right?” These are the most painful steps in the process that you have to address or improve in order for the user to be convinced to hire your solution. You might identify numerous negative emotion states in your user’s journey, but the key here is to narrow those down to the “must haves. Linking these key moments together into a critical “path journey gives you a blueprint for creating a great product (or what some would call a minimum viable product).
Kano Model
The Kano model, developed by Dr. Noriaki Kano, is a way of classifying customer expectations into three broad categories: expected needs, normal needs, and exciting needs. This hierarchy can be used to help with your prioritization efforts by clearly identifying the value of solutions to the needs in each of these buckets.
The customer’s expected needs are roughly equivalent to the critical path. If those needs are not met, they become dissatisfiers, and your chosen customer will not buy your product. If you’ve met expected needs, however, customers will typically begin to articulate normal needs, or satisfiers — things they do not strictly need in your product but that will satisfy them. If normal needs are largely met, then exciting needs (delighters or wows) go beyond the customer’s expectations. These typically define the offerings of category leaders.
You must solve for critical path or expected needs (dissatisfiers) at a minimum, but that alone won’t guarantee you success. Nor will you usually have the luxury to develop every satisfier or delighter you can think of. Resource and time constraints dictate that you pick among them and choose the ones that will make the biggest difference first.
One method we’ve used to prioritize potential solutions is to score each idea in terms of desirability, feasibility, and viability.
Chapter 9 · Presenting and Sharing your Roadmap
Inspiration
Your roadmap will paint a picture of a world where your customers are happy and your company is successful, making everyone in the organization want to be a part of it. If your why (aka product vision) is compelling, and your how plausible, you’ve got people hooked, and they’ll be happy to discuss how they can add their particular what to the plan.
The IKEA effect
Why do people love their IKEA furniture? Because they had a hand in putting it together. It’s the same with roadmaps.
The Osborne Effect
Announcing future plans too early can also slow down current sales as people may decide to wait for the next version or upgrade.
Product Roadmap for Engineering (More detailed)
Product Roadmap for Sales and Marketing
Product Roadmap for Executives
