More on this book
Community
Kindle Notes & Highlights
Read between
March 29 - April 12, 2022
“No roadmap survives contact with reality.”
David Cancel, CEO of Drift and former head of product for HubSpot, summed up these frustrations well when he explained why he no longer puts together a traditional roadmap: “Either I’m going to disappoint you by giving you exactly what we thought six months ahead of time was the best solution when it’s not, or by changing course and having lied to you.”
“It’s all about solving problems, not implementing features. Conventional product roadmaps are all about output.
Product roadmaps can take many forms, and aren’t necessarily a single artifact or document. In fact, it’s really not about creating artifacts at all—it’s about creating a shared understanding of where you’re going and why.
A good roadmap is not so much a project plan as a strategic communication tool, a statement of intent and direction.
a product roadmap describes how you intend to achieve your product vision.
In the 1980s, Motorola began using the term roadmap to align technology and product development.
The traditional roadmap was so focused on deliverables that it often left out the critical context of why the organization is focused on these specific things at all.
Product Vision Is Your Guiding Principle
We think of a product vision as how a specific sort of customer will benefit from your product when it is fully realized and ubiquitous.
Business Objectives Help You Measure Progress
What are the goals your product will accomplish? The outcomes? What will be measurably different for your organization?
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.
Themes Focus on Outcomes Rather Than Output
“What would need to be true for our product to realize its vision and attain its business objectives?” is the best way we’ve found to organize the work and deliverables of your team.
The Disclaimer Protects You (and Your Customer)
Most roadmaps contain some sort of caveat just to make it absolutely clear that anything in the roadmap is subject to change without notice. This protects you from accusations of broken promises; it also protects your customer by making it clear that change is possible, even likely.
Features and Solutions Show How You Intend to Deliver on Your Themes
Stakeholders seeing labels like “discovery,” “design,” or “prototyping” on a roadmap should understand that the product is in a very early stage of development.
Target Customers
Product Areas
The best roadmaps don’t obscure the core message with a lot of extraneous detail, but home in on the additional context most important to particular stakeholders.
The goal of gathering inputs is to make sure you have all of the relevant information and context you need to make good product decisions.
there are five primary phases of a product’s life cycle: New Growth Expansion Harvesting End of life
user roles focus on jobs and functions.
The user type addresses how a user will interact with your product, or defines a user’s permissions in relation to the product.
A persona is often defined as a representation of a user that embodies the characteristics, feelings, and preferences of a user set.
Roles help us categorize the different customers our product will help, and personas allow us to take our understanding to a deeper level.
A product vision should be about having an impact on the lives of the people your product serves, as well as on your organization.
A mission is not what you value, nor is it a vision for the future; it’s the intent you hold right now and the purpose driving you to realize your vision.
Value, Inspiration, Plausibility, Specificity
A company vision should be about a longer-term outcome that has an impact on the lives of the people your product serves, as well as on your organization. Vision is why your organization exists, and it can be decomposed into the benefits you hope to create through your efforts—for both the world and your organization.
The who, why and how (different)
Values are also intended to guide behaviors.
Your vision is your ultimate destination, and your mission tells you which direction to follow in order to reach that destination.
Product vision clarifies why you are bringing a product to market in the first place, and what its success will mean to the world and to the organization.
The premise of the OKR framework is that objectives are specific qualitative goals, and key results are quantitative measures of progress toward achieving those objectives.
If it takes you longer than one hour to review your data at a high level each week, we would argue you’re trying to track and interpret too many metrics.
“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.”
The risk of an output-focused roadmap often equates to a product team that releases feature after feature, and no tie back to the reason for those features.
“A roadmap is not a release plan. A roadmap is a sequence of stakeholder priorities and requires concept feasibility for delivery. A release plan requires rigorous scope definition and engineering capacity planning.”
Identifying customer needs is the most important aspect of your roadmapping process.
Themes are an organizational construct for defining what’s important to your customers at the present time.
The difference between themes and subthemes is granularity, or level of detail.
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).
it is important to focus most of the roadmapping effort on customer needs and problems because “the viability of a feature may shift dramatically, while the nature of an important customer problem will likely remain the same.”
Some product professionals differentiate between these two types of needs by calling them functional needs (customer-focused) versus technical or nonfunctional needs (engineering-focused).
By asking yourself (or whomever is requesting a particular feature) why, you are attempting to discern the difference between the output requested and the result or outcome desired.
I. Product vision The problem you’re solving, or the change you want to see in the world II. Objectives The high-level goals you want to accomplish in this next version of the product III. Themes and subthemes The customer needs or problems that you are addressing
