Foreword

They want to improve. They know they need to improve. They usually understand the theory of how strong teams work. But they just don’t have the hands-on experience and knowledge to be able to provide the coaching their people need.

Part I What is Continuous Discovery

Chapter One The What and Why of Continuous Discovery

I’ll refer to the work that you do to decide what to build as discovery and the work that you do to build and ship a product as 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.

The Evolution of Modern Product Discovery

In the early days of software, business leaders owned discovery—they decided what to build. Discovery happened once a year in an annual budgeting process, where projects with fixed timelines were assigned to specific engineering teams.

The authors of the Agile manifesto advocated for shorter cycles with more frequent customer feedback. Second, they proposed working at a pace that could be sustained continuously, rather than furiously scurrying from one milestone to another. Third, they advocated for maximum flexibility—having the ability to adapt to customer feedback quickly and easily. And fourth, they advocated for simplicity.

Leaders struggled to give up ownership of discovery. Even with shorter cycles and more customer feedback, business stakeholders still clung to their original ideas. Most teams weren’t very good at estimating unpredictable work (who is?), and their shorter cycles, aptly named sprints in Scrum, truly became biweekly sprints, killing any chance of finding a continuously sustainable pace. The rest of the business continued operating on an annual budgeting cycle, making true flexibility nearly impossible. When teams learned something wouldn’t work, they were still expected to deliver it on time and under budget. Usability testing was often done too late in the process, making it hard to address the substantial issues that were so often uncovered. User research was often outsourced to design agencies who did project-based research. And finally, teams continued to be measured by what they delivered, not whether anyone used it or if it created any value for the customer or the business.

Who This Book Is for

Throughout the book, the term “product trio” will refer to a product manager, a designer, and a software engineer working together to develop products for their customers.

Each team needs to define the right “trio” on their team to adopt these habits.

The pre-requisite mindset

That means rather than defining your success by the code that you ship (your output), you define success as the value that code creates for your customers and for your business (the outcomes).

We elevate customer needs to be on par with business needs and focus on creating customer value as well as business value.

Rather than the product manager decides, the designer designs, and the engineer codes, we embrace a model where we make team decisions while leveraging the expertise and knowledge that we each bring to those decisions.

The habits in this book will encourage you to draw, to externalize your thinking, and to map what you know.

to do discovery well, we need to learn to think like scientists identifying assumptions and gathering evidence.

My Summary

This first chapter introduces talks about the evolution of product / software development over time. Starting with a more project driven, based on the decisions of few, then going through the agile movement and companies trying to adapt but failing to change the way they work. And at last, with the evolution of product instrumentation companies finding the right spot and culture to achieve better results.

The "product trio" is composed by a product manager, a designer and a software engineer. This is not a static structure each company needs to find the right fit for their product trio.

There are companies failing to achieve the expected results, because they try to copy a framework or methodology without understanding the the whys behind the practices. It's required to cultivate 6 mindsets in order to achieve the continuous delivery:

1. outcome-oriented
2. customer-centric
3. collaborative
4. visual
5. experimental
6. continuous

At last the author differentiates companies who sporadically uses modern discovery practices to companies who have achieve a continuous discovery, then it proposes the following definition:

At a minimum, weekly touch points with customers

By the team building the product

Where they conduct small research activities

In pursuit of a desired outcome

Chapter Two A Common Framework for Continuous Discovery

The company rightly started with a desired outcome: To increase the average number of accounts per customer. However, they didn’t pair this outcome mindset with a customer-centric mindset, that is critical for long-term product success.

by arguing that serving customers is how we generate profit.

Begin With the End in Mind

Rather than obsessing about features (outputs), we are shifting our focus to the impact those features have on both our customers and our business (outcomes).

When a product trio is tasked with delivering an outcome, the business is clearly communicating what value the team can create for the business. And when the business leaves it up to the team to explore the best outputs that might drive that outcome, they are giving the team the latitude they need to create value for the customer.

The Challenge of Driving Outcomes

So, when we shift from an output mindset to an outcome mindset, we have to relearn how to do our jobs.

Ill-structured problems are defined by having many solutions. There are no right or wrong answers, only better or worse ones.

I’ll refer to customer needs, pain points, and desires collectively as “opportunities”—they represent opportunities to intervene in our customers’ lives in a positive way.

To reach their desired outcome, a product trio must discover and explore the opportunity space. The opportunity space, however, is infinite.

two of the most important steps for reaching our desired outcome are first, how we map out and structure the opportunity space, and second, how we select which opportunities to pursue.

We do have to get to solutions—shipping code is how we ship value to our customers and create value for our business. But the right problem framing will help to ensure that we explore and ultimately ship better solutions.

The Underlying Structure of Discovery

It starts with defining a clear outcome—one that sets the scope for discovery. From there, we must discover and map out the opportunity space—this is what gives structure to the ill-structured problem of reaching our desired outcome. It’s the all-important problem framing that opens up the solution space. And finally, we need to discover the solutions that will address those opportunities and thus drive our desired outcome.

opportunity solution tree (OST).

OSTs Resolve the Tension Between Business Needs and Customer Needs

You start by prioritizing your business need—creating value for your business is what ensures that your team can serve your customer over time.

Next, the team should explore the customer needs, pain points and desires that, if addressed, would drive that outcome.

OSTs Help Build and Maintain a Shared Understanding Across Your Trio

When a team takes the time to visualize their options, they build a shared understanding of how they might reach their desired outcomes.

OSTs Help Product Trios Adopt a Continuous Mindset

We tend to take our six-month-long waterfall project, carve it up into a series of two-week sprints, and call it "Agile".

With time, as they address a series of smaller opportunities, these solutions start to address the bigger opportunity.

OSTs Unlock Better Decision-Making

When you bounce from tactic to tactic, it's easy to forget what you've learned and what decisions you need to make next.

The first villain is looking too narrowly at a problem.

The second villain is looking for evidence that confirms our beliefs.

The third villain is letting our short-term emotions affect our decisions.

The fourth villain is overconfidence.

But one tactic we'll rely on over and over again throughout this book is their advice to avoid "whether or not" decisions.

Good discovery doesn't prevent us from failing; it simply reduces the chance of failures.

However, most of the decisions that we make in discovery are reversible decisions. If we do the necessary work to test our decisions, we can quickly correct course when we find that we made the wrong decision.

OSTs Unlock Faster Learning Cycles

As they explore potential solutions, they learn more about the problem, and, as they learn more about the problem, new solutions become possible.

OSTs Build Confidence in Knowing What to Do Next

The depth and breadth of the opportunity space reflects the team's current understanding of their target customer.

OSTs Unlock Simpler Stakeholder Management

As a result, 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

When sharing your discovery work with stakeholders, you can use your tree to first remind them of your desired outcome. Next, you can share what you've learned about your customer, by walking them through the opportunity space.

My Summary

Chapter two starts talking about the conflict between businesses needs and customer needs and uses the Wells Fargo company which was fined $185 million by the Consumer Financial Protection Bureau, because they didn't balance the outcome mindset with the customer centric mindset. Then proceeds arguing what generates profit is the customers being served correctly.

You should focus on outcomes not outputs. You should focus on what's the impact that your deliveries causes. The outcome is a business responsibility and the product trio explore the best opportunities that will become outputs, which will drive the outcome.

When shifting for a culture of outputs to outcome is common that you'll face difficulties. You should look for ill-structured problems, which is a problem with many solutions. There are no right or wrong, only better or worse. To find a ill structured problem, the most difficult part is to frame the problem itself, what we call opportunity spaces.

Opportunities is a better way to refer to customer needs, pain points and desires. Problems infer that you need to fix something. so it doesn't encompass desires neither customer needs.

Because the opportunity space is infinite structuring the opportunity space is so important as well as choosing the opportunities from the opportunity space.

Discovery Structure:

1. Define a clear outcome
2. Discover and map the opportunity space (ill structured problem)
3. Discover solutions that will address and this drive our desired outcome

Opportunity solution tree is a visual representation tool to help to achieve your outcomes:

• Resolve the tension between business needs and customer needs
• Build and maintain a shared understanding of how they might reach their desired outcome

• Adopt a continuous mindset

  • Solving smaller opportunities eventually solves bigger opportunities

• Unlock better decision-making

  • Avoid whether or not decisions. Use compare and contrast mindset.
  • Avoid the analysis paralysis by doing reversible decisions in discovery.

• Unlock faster learning cycles

  • The problem space and the solution space are intrinsically intertwined
• Build confidence in knowing what to do next

• Unlock simpler stakeholder management

  • Use the OST to communicate learning and help to align with stakeholders.

Part II The Continuous Discovery Habits

Chapter Three Focusing on Outcomes Over Outputs

Teams tasked with a new outcome often have no idea how to measure that outcome, how to impact it, or even if it's the right outcome to be pursuing.

Lagging indicators like 90-day retention make it hard to measure the impact of fast experiment cycles.

Product teams often have to do some discovery work to identify the connections between product outcomes (the metrics they can influence) and business outcomes (the metrics that drive the business).

Why Outcomes?

When we manage by outcomes, we give our teams the autonomy, responsibility, and ownership to chart their own path.

The key distinction with this strategy over traditional roadmaps is that we are giving the team autonomy to find the best solution.

A fixed roadmap communicates false ceratinty

We know we need this problem solved, but we don't know the best way to solve it.

Exploring Different Types of Outcomes

If we choose the wrong outcomes, we'll still get the wrong results

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.

(about lagging indicators) They measure something after it has happened.

We want to identify leading indicators that predict the direction of the lagging indicator.

As a general rule, product trios will make more progress on a product outcome rather than a business outcome.

we can increase the accountability of each team by assigning a metric that is relevant to their own work.

When multiple teams are assigned the same outcome, it's easy to shift blame for lack of progress.

(first situation where appropriate to assign traction metrics) assign traction metrics to more junior product trios. Improving a traction metric is more of an optimization challenge than a wide-open discovery challenge and is a great way for a junior team to get some experience with discovery methods before giving the more responsibility.

(second situation where appropriate to assign traction metrics) 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 align this traction metric to an optimization team.

The key is to use a traction metrics only when you are optimizing a solution and not when the intent is to discover new solutions.

Outcomes Are the Results of a Two-Way Negotiation

The key is that the leader should not narrow the scope so much that the team is tasked with a traction metric.

The trio should not be required to communicate what solutions they will build at this time, as this should emerge from discovery.

the product leader will need to understand that more ambitious outcomes carry more risk.

the product trio will need some time to learn what might move the metric. This is why a stable product trio focused on the same outcome over time is so critical. Every time we mix up the team or change the outcome, we take a learning tax as the team gets up to speed.

teams who participated in the setting of their own outcomes took more initiative and thus performed better than colleagues who were not involved in setting their outcomes.

Do You Need S.M.A.R.T Goals?

It's perfectly fine to start with a learning goal and work your way toward a S.M.A.R.T performance goal.

A Guide for Product Trios

When your product leader assigns a new initiatives to your product trio, ask your leader to share more of the business context with you.

Why do you think that initiative will drive that outcome?

Avoid These Common Anti-Patterns

Pursuing too many outcomes at once

The goal is for the product trio to collaborate to achieve product outcomes that drive business outcomes.

a team needs to monitor health metrics to ensure they aren't causing detrimental effects elsewhere.

My Summary

When changing to use outcome based product development, the initial step is going to be hard. How to define the right outcome? How can you measure it? can you impact it? is this the right outcome? Even harder when using lagging indicators like 90 day retention, which takes long time to measure.

Road maps:

• Specifies a fixed list of features and dates which should be released
• Conveys a false sense of certainty about knowing the future

Outcomes:

• Gives the team responsibility, autonomy and ownership to define how to achieve the outcome
• We acknowledge that we know what is the problem we want to solve, but not the best way to do it

Different types of outcomes:

Business outcome: Measures business value. Financial (revenue, grow, costs), strategic (increase sales in a region). Usually a lagging indicator. Example is retention.

Product outcome: Measures how well the product moves the business forward. It's within the span of control of the product trio.

Traction metric: Measures usage of a specific feature or workflow in the product.

Type of indicator:

• Lagging Indicators - Already happened.
• Leading Indicators - Predict the direction of the lagging indicator.

Teams should avoid use lagging indicator as a guide, because put them in react mode and depending on the time period doesn't allow short cycles of experimentation (90 days retention). Therefore, is required to look for leading indicators that predict lagging indicators.

Teams should receive a product metric rather than a business outcome. A business outcome might be out of control of the team to improve it. It's better to assign for each team a product outcome so they can create a sense of responsibility and ownership.

There are two cases where it might be a good idea to assign a traction metric to the team

1. Junior product trio. So they can focus on optimization while gaining experience in the discovery process
2. Mature product trio and the traction metric is key to the company success.

Traction metrics are good for optimization, not for discovering new solutions.

Setting a metric is a two way negotiation with the CPO and the product trio. The product leader identifies which product outcome derived from the company outcomes the product trio can work on. Then the product trio brings customer and technology to determine how much they can move the metric.

When faced with a new outcome, it's okay to first have a learning goal, and then once you learned it the performance goal.

Anti-patterns to avoid:

• Pursuing too many outcomes at once.
• Ping-ponging from one outcome to another.
• Setting individual outcomes instead of product-trio outcomes.
• Choosing an output as an outcome
• Focusing on one outcome to the detriment of all else

Discovering Opportunities

Chapter Four Visualizing What You Know

Chapter Five Continuous Interviewing

Chapter Six Mapping the opportunity space

Chapter Seven Prioritizing Opportunities, Not Solutions

Discovering Problems