More on this book
Community
Kindle Notes & Highlights
We shifted away from having lists of metrics to increase and outputs to deliver. Now we have fewer goals, more clarity, and a focus on solving the customer’s problem in ways that drive business value. We shifted away from falling in love with a single idea and building it. Now we come up with many ideas. And we learn faster by testing sets of ideas and running smaller simulations.
We shifted away from discovery and delivery being separate responsibilities. Now there’s more collaboration, with most of the team involved in customer interviews, mapping the customer journey, ideating on solutions, and discussing results. The whole team contributes at key points along the way, and we learn and adjust our course together.
All product teams do a set of activities to decide what to build and then do a different set of activities to build and deliver it. While you’ll learn that these activities can and should overlap and interweave with each other, the work that is required to do each is fundamentally different.
many companies put a heavy emphasis on delivery—they focus on whether you shipped what you said you would on time and on budget—while under-investing in discovery, forgetting to assess if you built the right stuff.
Discovery isn’t a one-time activity. A digital product is never done. It can and should continue to evolve. As we learn more about our market, as our customers’ needs change, as new technology becomes available, good products adapt.
The more folks involved in each decision, the longer it will take to reach that decision. You want to balance speed of decision-making with inclusiveness.
Many teams chase frameworks, tools, and methodologies, hoping that each new innovation will suddenly unlock the door to product success. However, for most frameworks, tools, and methodologies to be successful, it’s not just your tactics that need to change but also your mindset.
Shifting from a project mindset to a continuous mindset is hard. We tend to take our six-month-long waterfall project, carve it up into a series of two-week sprints, and call it “Agile.” But this isn’t Agile. Nor is it continuous.
The opportunity solution tree helps teams take large, project-sized opportunities and break them down into a series of smaller opportunities. As you work your way vertically down the tree, opportunities get smaller and smaller. Teams can then focus on solving one opportunity at a time. With time, as they address a series of smaller opportunities, these solutions start to address the bigger opportunity. The team learns to solve project-sized opportunities by solving smaller opportunities continuously.
some have come to believe that product managers own defining the problem and that designers and software engineers own defining the solution. This sounds nice in theory, but it quickly falls apart in practice.
By visually mapping out the opportunity space on an opportunity solution tree, a product trio is making their understanding of their customer explicit. When a solution fails, they can revisit this mapping to quickly revise that understanding.
Organizational change happens unevenly. Even when a company tasks a team with a clear desired outcome, it can be hard for leaders to let go of dictating outputs.
it’s not enough for a product trio to make evidence-based decisions about what to build; they also need to justify those decisions to key stakeholders along the way.
The tree structure makes it easy to communicate the big picture while also diving into the details when needed. Your tree should visually show what solutions you are considering and what tests you are running to evaluate those solutions.
As you embark on the wandering paths of discovery, your tree will act as your roadmap, helping you find the best path to your desired outcome.
Business thought leaders have been advocating for managing by outcomes for decades. Peter Drucker, a renowned managerial thought leader, wrote about its benefits countless times12.
A fixed roadmap communicates false certainty. It says we know these are the right features to build, even though we know from experience their impact will likely fall short. An outcome communicates uncertainty. It says, We know we need this problem solved, but we don’t know the best way to solve it. It gives the product trio the latitude they need to explore and pivot when needed. If the product trio finds flaws with their initial solution, they can quickly shift to a new idea, often trying several before they ultimately find what will drive the desired outcome.
managing by outcomes communicates to the team how they should be measuring success.
When considering outcomes for specific teams, it helps to distinguish between business outcomes, product outcomes, and traction metrics. A business outcome measures how well the business is progressing. A product outcome measures how well the product is moving the business forward. A traction metric measures usage of a specific feature or workflow in the product.
Business outcomes start with financial metrics (e.g., grow revenue, reduce costs), but they can also represent strategic initiatives (e.g., grow market share in a specific region, increase sales to a new customer segment). Many business outcomes, however, are lagging indicators. They measure something after it has happened. It’s hard for lagging indicators to guide a team’s work because it puts them in react mode, rather than empowers them to proactively drive results.
Assigning product outcomes to product trios increases a sense of responsibility and ownership.
When multiple teams are assigned the same outcome, it’s easy to shift blame for lack of progress.
if you have a mature product and you have a traction metric that you know is critical to your company’s success, it makes sense to assign this traction metric to an optimization team.
We often need to do some discovery to learn how to best measure a product outcome.
It’s perfectly fine to start with a learning goal and work your way toward a S.M.A.R.T. performance goal.
Shifting to an outcome mindset is harder than it looks. We spend most of our time talking about outputs. So, it’s not surprising that we tend to confuse the two. Even when teams intend to choose an outcome, they often fall into the trap of selecting an output. I see teams set their outcome as “Launch an Android app” instead of “Increase mobile engagement” or “Get to feature parity on the new tech stack” instead of “Transition customer to the new tech stack.” A good place to start is to make sure your outcome represents a number even if you aren’t sure yet how to measure it.
To shift your outcome from less of an output to more of an outcome, question the impact it will have.
“If we give each other time to explain ourselves using words and pictures, we build shared understanding.” — Jeff Patton, User Story Mapping
The purpose of customer interviewing is not to ask your customers what you should build. Instead, the purpose of an interview is to discover and explore opportunities. Remember, opportunities are customer needs, pain points, and desires. They are opportunities to intervene in your customers’ lives in a positive way.
Decades of research on investigative interviewing (the kind used by journalists, lawyers, and detectives) has shown that interview participants struggle to answer direct (factual) questions accurately.
we think we understand why we do the things we do. But the reality is, our brains are exceptionally good at creating coherent (but not necessarily true) stories that deceive us.
Too often in customer interviews, we ask direct questions. We ask, “What criteria do you use when purchasing a pair of jeans?” Or we ask, “How often do you go to the gym?” But these types of questions invoke our ideal selves, and they encourage our brains to generate coherent but not necessarily reliable responses.
An opportunity represents a need, a pain point, or a desire that was expressed during the interview. Be sure to represent opportunities as needs and not solutions. If the participant requests a specific feature or solution, ask about why they need that, and capture the opportunity (rather than the solution). A good way to do this is to ask, “If you had that feature, what would that do for you?”
One of the most important elements to capture on the interview snapshot is an experience map
A digital product is never done, and the opportunity space is never finite or complete.
Instead of managing an opportunity backlog, we’ll use an opportunity solution tree (introduced in Chapter 2) to help us map out and understand the opportunity space. The tree structure will help us visualize and understand the complexity of the opportunity space.
“The build trap is when organizations become stuck measuring their success by outputs rather than outcomes. It’s when they focus more on shipping and developing features rather than on the actual value those things produce.” — Melissa Perri
For too long, product teams have defined their work as shipping the next release. When we engage with stakeholders, we talk about our roadmaps and our backlogs. During our performance reviews, we highlight all the great features we implemented. The vast majority of our conversations take place in the solution space. We assume that success comes from launching features. This is what product thought leader Melissa Perri calls “the build trap.”28 This obsession with producing outputs is strangling us. It’s why we spend countless hours prioritizing features, grooming backlogs, and micro-managing
...more
In the Opportunity Mapping chapter (Chapter 6), you learned that, as you work vertically down the opportunity solution tree, you are deconstructing large, intractable opportunities into a series of smaller, more solvable sub-opportunities. The benefit of this work is that it helps us adopt an Agile mindset, working iteratively, delivering value over time, rather than delivering a large project after an extended period of time.
I recommend that teams assess opportunities using the following criteria: opportunity sizing, market factors, company factors, and customer factors.
Viability assumptions: Should we build it? There are many ideas that will work for our customers but won’t work for our business.
Feasibility assumptions: Can we build it?
Ethical assumptions: Is there any potential harm in building this idea?
Many teams ask, “When are we done with discovery? When do we get to send our ideas to delivery?” The answer to the first question is simple. You are never done with discovery. Remember, this book is about continuous discovery. There is always more to learn and to discover.
discovery feeds delivery and delivery feeds discovery. They aren’t two distinct phases. You can’t have one without the other.
Testing in your production environment is a natural progression for your discovery work. It’s also where your delivery work begins. If you instrument your delivery work, discovery will not only feed delivery, but delivery will feed discovery.
Instead of trying to plan everything upfront, start small, and experiment your way to the best instrumentation.
we did not start by measuring everything. We didn’t track every click on every page. We started with our assumptions, and we measured exactly what we needed to test our assumptions.
We weren’t afraid to measure hard things—and you shouldn’t be, either.
we distinguished between business outcomes, product outcomes, and traction metrics as a way to help us set the scope for our product work.
