Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value
Created time
Dec 29, 2022 07:01 AM
Author
Teresa Torres
URL
Status
Genre
Book Name
Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value
Modified
Last updated December 26, 2023
Summary
Continuous Discovery Habits by Teresa Torres is a powerful book that offers practical guidance for product managers, designers, and researchers. It helps you analyze customer needs and develop high-quality products with sustained customer value and business growth. It will teach you how to:
• Continually understand customer needs,
• Create experiments to validate product possibilities,
• Build a culture of data-driven decisions, and
• Adopt a growth-oriented mindset.
This book is ideal for techies in their mid-20s who are interested in design, data, architecture, urban planning, philosophy, or mobility. It will provide you with a roadmap to reduce risks and gain the insights to build successful products. If you're looking for other books on this topic, you should try Releasing the Product Within – An Agile Product Management Primer and Agile Product Management: Box Set (2 in 1).
✏️ Highlights
PART 1: WHAT IS CONTINUOUS DISCOVERY? Chapter One: The What and Why of Continuous Discovery Chapter Two: A Common Framework for Continuous Discovery PART 2: THE CONTINUOUS DISCOVERY HABITS Chapter Three: Focusing on Outcomes Over Outputs 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 Solutions Chapter Eight: Supercharged Ideation Chapter Nine: Identifying Hidden Assumptions Chapter Ten: Testing Assumptions, Not Ideas Chapter Eleven: Measuring Impact Chapter Twelve: Managing the Cycles Chapter Thirteen: Show Your Work PART 3: DEVELOPING YOUR CONTINUOUS DISCOVERY HABITS Chapter Fourteen: Start Small, and Iterate Chapter Fifteen: What’s Next?
Working in a product role is hard. There is huge pressure to solve customer problems and drive business value. Everyone is looking to you for answers.
Most books promise a whole lot—plenty of the “what” but little of the “how.” You are often left wondering what to do next.
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.
As the years go by, the more I credit luck for my good fortune, and the less I credit any particular skills I might possess.
I was mentoring a young designer whom I had known since she was nine years old—the daughter of a good friend of mine. I encouraged a young engineer, a recent math major from the University of Washington, to get up to speed with machine learning.
I was relying on him to help us realize our product vision and was thrilled that, as a company, we were investing in young talent. I loved coming to work each day. And then one day, I walked in and quit.
By the time I joined, the company had grown out of the speed-at-all-costs startup stage (if it ever had one).
I was tired of having to convince my colleagues that a relentless focus on customers was a better strategy than obsessing about our competitors.
As an undergraduate, I was exposed to human-centered design at Stanford University.
With time, I came to view my coaching curriculum as a product in and of itself, and I started to measure the impact of how I coached. I tracked cohorts, I measured where teams got stuck, I iterated on my methods. Over time, my curriculum got better, and, as a result, the product teams that I worked with got better. Today, teams walk away from my 12-week coaching program equipped with an arsenal of continuous discovery habits that help them discover, iterate, and refine products that deliver value for their customers
With time, I came to view my coaching curriculum as a product in and of itself, and I started to measure the impact of how I coached. I tracked cohorts, I measured where teams got stuck, I iterated on my methods. Over time, my curriculum got better, and, as a result, the product teams that I worked with got better. Today, teams walk away from my 12-week coaching program equipped with an arsenal of continuous discovery habits that help them discover, iterate, and refine products that deliver value for their customers in a way that drives value for their businesses.
The world needs better products. It’s up to us to make that happen. This book will teach you how.
How do you know that you are making a product or service that your customers want? How do you ensure that you are improving it over time? How do you guarantee that your team is creating value for your customers in a way that creates value for your business?
In this book, 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.
many companies put a heavy emphasis on delivery—they
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.
continuous discovery framework that enables teams to discover brand-new products and to iterate on existing ones.
continuously discover unmet customer needs and the solutions that will address those needs.
Sometimes a product manager translated business needs to product requirements, but not always.
in 2001, a group of engineers got fed up, went into the mountains, put their heads together, and came up with the Agile manifesto.
The authors of the Agile manifesto advocated for shorter cycles with more frequent customer feedback.
they advocated for simplicity. They were concerned with how much of what they built was never used or offered limited value and instead advocated for teams to ruthlessly limit what they built. You’ll see these four principles infused throughout the methods in this book.
We saw a rise in the adoption of Scrum and Kanban, two popular Agile frameworks, to manage delivery work. In parallel, we saw the growth of
We saw a rise in the adoption of Scrum and Kanban, two popular Agile frameworks, to manage delivery work. In parallel, we saw the growth of user-experience design and user research as means for collecting customer feedback.
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. However, it wasn’t all bad news.
Teams did shorten their delivery cycles. Companies iterated from annual releases to quarterly releases to monthly releases. Today, many teams work on a weekly or even daily release schedule.
This book was written for product people (product managers, designers, and software engineers) who want to build products that their customers need and love. It outlines a collection of habits that, when deployed continuously week over week, lead to better business outcomes and better customer outcomes. These habits were designed to be adopted by a product trio composed of each of these roles. 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.
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.
There are six mindsets that must be cultivated to successfully adopt the habits outlined in this book.
1. Outcome-oriented: The first mindset is both a mindset and a habit. You’ll learn more about the habit in the coming chapters, but the mindset requires that you start thinking in outcomes rather than outputs.
define success as the value that code creates for your
1. Outcome-oriented: The first mindset is both a mindset and a habit. You’ll learn more about the habit in the coming chapters, but the mindset requires that you start thinking in outcomes rather than outputs. 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 measure success in impact—the impact we have had on our customers’ lives and the impact we have had on
we measure success in impact—the impact we have had on our customers’ lives and the impact we have had on the sustainability and growth of our business.
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.
4. Visual: The fourth mindset encourages us to step beyond the comfort of spoken and written language and to tap into our immense power as spatial thinkers.
5. Experimental: The fifth mindset encourages you to don your scientific-thinking hat. Many of us may not have scientific training, but, to do discovery well, we need to learn to think like scientists identifying assumptions and gathering evidence.
Rather than thinking about discovery as something that we do at the beginning of a project, you will learn to infuse discovery continuously throughout your development process.
In my experience working with product teams, many are already adopting many of the discovery activities you will learn about in this book. Customer interviews, usability testing, and A/B testing are pervasive.
What is rare is for teams to adopt these discovery activities in a structured and sustainable way, enabling them to continuously infuse their product decisions with customer input.
Product teams make decisions every day. Our goal with continuous discovery is to infuse those daily decisions with as much customer input as possible.
“Managers must convert society’s needs into opportunities for profitable business.” — Peter Drucker “If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” — Albert Einstein
Businesses do need to make a profit. That’s required for their survival. However, profit should not come at the cost of serving the customer.
PART 1: WHAT IS CONTINUOUS DISCOVERY? Chapter One: The What and Why of Continuous Discovery Chapter Two: A Common Framework for Continuous Discovery PART 2: THE CONTINUOUS DISCOVERY HABITS Chapter Three: Focusing on Outcomes Over Outputs 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 Solutions Chapter Eight: Supercharged Ideation Chapter Nine: Identifying Hidden Assumptions Chapter Ten: Testing Assumptions, Not Ideas Chapter Eleven: Measuring Impact Chapter Twelve: Managing the Cycles Chapter Thirteen: Show Your Work PART 3: DEVELOPING YOUR CONTINUOUS DISCOVERY HABITS Chapter Fourteen: Start Small, and Iterate Chapter Fifteen: What’s Next?
Working in a product role is hard. There is huge pressure to solve customer problems and drive business value. Everyone is looking to you for answers.
Most books promise a whole lot—plenty of the “what” but little of the “how.” You are often left wondering what to do next.
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.
As the years go by, the more I credit luck for my good fortune, and the less I credit any particular skills I might possess.
I was mentoring a young designer whom I had known since she was nine years old—the daughter of a good friend of mine. I encouraged a young engineer, a recent math major from the University of Washington, to get up to speed with machine learning.
I was relying on him to help us realize our product vision and was thrilled that, as a company, we were investing in young talent. I loved coming to work each day. And then one day, I walked in and quit.
By the time I joined, the company had grown out of the speed-at-all-costs startup stage (if it ever had one).
I was tired of having to convince my colleagues that a relentless focus on customers was a better strategy than obsessing about our competitors.
As an undergraduate, I was exposed to human-centered design at Stanford University.
With time, I came to view my coaching curriculum as a product in and of itself, and I started to measure the impact of how I coached. I tracked cohorts, I measured where teams got stuck, I iterated on my methods. Over time, my curriculum got better, and, as a result, the product teams that I worked with got better. Today, teams walk away from my 12-week coaching program equipped with an arsenal of continuous discovery habits that help them discover, iterate, and refine products that deliver value for their customers
With time, I came to view my coaching curriculum as a product in and of itself, and I started to measure the impact of how I coached. I tracked cohorts, I measured where teams got stuck, I iterated on my methods. Over time, my curriculum got better, and, as a result, the product teams that I worked with got better. Today, teams walk away from my 12-week coaching program equipped with an arsenal of continuous discovery habits that help them discover, iterate, and refine products that deliver value for their customers in a way that drives value for their businesses.
The world needs better products. It’s up to us to make that happen. This book will teach you how.
How do you know that you are making a product or service that your customers want? How do you ensure that you are improving it over time? How do you guarantee that your team is creating value for your customers in a way that creates value for your business?
In this book, 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.
many companies put a heavy emphasis on delivery—they
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.
continuous discovery framework that enables teams to discover brand-new products and to iterate on existing ones.
continuously discover unmet customer needs and the solutions that will address those needs.
Sometimes a product manager translated business needs to product requirements, but not always.
in 2001, a group of engineers got fed up, went into the mountains, put their heads together, and came up with the Agile manifesto.
The authors of the Agile manifesto advocated for shorter cycles with more frequent customer feedback.
they advocated for simplicity. They were concerned with how much of what they built was never used or offered limited value and instead advocated for teams to ruthlessly limit what they built. You’ll see these four principles infused throughout the methods in this book.
We saw a rise in the adoption of Scrum and Kanban, two popular Agile frameworks, to manage delivery work. In parallel, we saw the growth of
We saw a rise in the adoption of Scrum and Kanban, two popular Agile frameworks, to manage delivery work. In parallel, we saw the growth of user-experience design and user research as means for collecting customer feedback.
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. However, it wasn’t all bad news.
Teams did shorten their delivery cycles. Companies iterated from annual releases to quarterly releases to monthly releases. Today, many teams work on a weekly or even daily release schedule.
This book was written for product people (product managers, designers, and software engineers) who want to build products that their customers need and love. It outlines a collection of habits that, when deployed continuously week over week, lead to better business outcomes and better customer outcomes. These habits were designed to be adopted by a product trio composed of each of these roles. 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.
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.
There are six mindsets that must be cultivated to successfully adopt the habits outlined in this book.
1. Outcome-oriented: The first mindset is both a mindset and a habit. You’ll learn more about the habit in the coming chapters, but the mindset requires that you start thinking in outcomes rather than outputs.
define success as the value that code creates for your
1. Outcome-oriented: The first mindset is both a mindset and a habit. You’ll learn more about the habit in the coming chapters, but the mindset requires that you start thinking in outcomes rather than outputs. 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 measure success in impact—the impact we have had on our customers’ lives and the impact we have had on
we measure success in impact—the impact we have had on our customers’ lives and the impact we have had on the sustainability and growth of our business.
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.
4. Visual: The fourth mindset encourages us to step beyond the comfort of spoken and written language and to tap into our immense power as spatial thinkers.
5. Experimental: The fifth mindset encourages you to don your scientific-thinking hat. Many of us may not have scientific training, but, to do discovery well, we need to learn to think like scientists identifying assumptions and gathering evidence.
Rather than thinking about discovery as something that we do at the beginning of a project, you will learn to infuse discovery continuously throughout your development process.
In my experience working with product teams, many are already adopting many of the discovery activities you will learn about in this book. Customer interviews, usability testing, and A/B testing are pervasive.
What is rare is for teams to adopt these discovery activities in a structured and sustainable way, enabling them to continuously infuse their product decisions with customer input.
Product teams make decisions every day. Our goal with continuous discovery is to infuse those daily decisions with as much customer input as possible.
“Managers must convert society’s needs into opportunities for profitable business.” — Peter Drucker “If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” — Albert Einstein
Businesses do need to make a profit. That’s required for their survival. However, profit should not come at the cost of serving the customer.
