We typically define product discovery in contrast with product delivery. Product discovery is used to describe the work done to make decisions about what to build, while product delivery is the work done to build, ship, and maintain a production quality product.
Good product discovery includes the customer throughout the decision-making process. through: customer interviews, usability tests, A/B tests, demand tests, customer journey mapping, experience mapping, story mapping, OKRs, opportunity solution trees, ethnographic studies, customer visits, and so on.

Product Discovery

The best teams are recognizing that digital products are never done. They can always iterate and improve. Good product teams know they can always create more value for customers and in turn create more value for their business. This shift in mindset often gets referred to as “product thinking” or as a “product mindset.”

The Product Mindset

As product teams build digital products, they build expertise in their products. They know what the product is capable of. The challenge is that the customers don’t share this expertise.Product people suffer from a bias called the “curse of knowledge": they develop expert knowledge about their product, they forget what it was like before they had that knowledge. And they can't imagine what it’s like for customers to not have this knowledge.This becomes a significant problem when they make daily product discovery decisions without input from customers.

The Curse of Knowledge in Product Development

Good product discovery has a simple underlying structure: Start with an outcome, discover opportunities, discover solutions.
<ol>
<li>Good product discovery starts with a clear outcome. A business outcome measures the health of the business and is usually a financial metric or measures progress against a strategic initiative.</li>
<li>Once a product outcome is selected, the product team needs to discover the opportunity space. The team’s goal is to discover opportunities that have the potential to drive their product outcome.</li>
<li>Teams need to discover solutions that will address those opportunities. </li>
</ol>

The Underlying Structure of Product Discovery

<div dir="ltr">Have you heard? My new book <a href="https://amzn.to/3hGkNYT" dir="ltr">Continuous Discovery Habits</a> is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery. </div>Product discovery is becoming a trendy topic in the world of digital products. Why? What is it? And what do you need to know about it? I’ve got you covered. This article will cover the ins and outs of product discovery.<h2>What is Product Discovery?</h2><img src="https://www.producttalk.org/wp-content/uploads/2021/08/discovery-and-delivery.jpeg" alt="The text reads, &quot;Product Discovery: Deciding what to build. Product Delivery: Building it.&quot;" width="550" height="309" srcset="https://www.producttalk.org/wp-content/uploads/2021/08/discovery-and-delivery.jpeg 550w, https://www.producttalk.org/wp-content/uploads/2021/08/discovery-and-delivery-300x169.jpeg 300w">Product discovery is often defined in comparison to product delivery.We typically define product discovery in contrast with product delivery. Product discovery is used to describe the work that we do to <a href="https://www.producttalk.org/decision-making/" dir="ltr">make decisions</a> about what to build, while product delivery is the work we do to build, ship, and maintain a production quality product.Good product discovery includes the customer throughout the decision-making process. We have dozens of tactics and frameworks that are often associated with product discovery: <a href="https://www.producttalk.org/customer-interviews/" dir="ltr">customer interviews</a>, usability tests, <a href="https://www.producttalk.org/hypothesis-testing/" dir="ltr">A/B tests</a>, demand tests, <a href="https://www.producttalk.org/2017/08/experiment-design/" dir="ltr">assumption tests</a>, customer journey mapping, experience mapping, <a href="https://www.jpattonassociates.com/user-story-mapping/" dir="ltr">story mapping</a>, <a href="https://www.strategyzer.com/blog/how-assumptions-mapping-can-focus-your-teams-on-running-experiments-that-matter" dir="ltr">assumption mapping</a>, OKRs, <a href="https://www.producttalk.org/opportunity-solution-tree/" dir="ltr">opportunity solution trees</a>, impact mapping, jobs-to-be-done, ethnographic studies, customer visits, and so on.<BLOCKQUOTE>Good product discovery includes the customer throughout the decision-making process. – <a href="https://ctt.ac/4aGLp" dir="ltr">Tweet This</a></BLOCKQUOTE>It’s easy to get overwhelmed by all the methods. But the underlying principle is simple. Product discovery is a decision-making process. Good product discovery includes the customer throughout that process.<h2>Understanding Project-Based Discovery</h2>Most of us grew up in a project world. Our companies conduct annual budgeting routines that involve resourcing projects or initiatives for the year. Most of these projects are framed in the solution space—they take the form of “build this feature” or “launch this program.”Projects have a beginning, a middle, and an end. We typically mark a project as finished once we release code to our production environment. Oftentimes, projects are sourced from <a href="https://www.producttalk.org/2018/06/managing-stakeholders/" dir="ltr">business stakeholders</a>, customers, or occasionally the project teams that are implementing them.If we are lucky, we might do some customer research at the beginning of the project. If we do, it’s usually in the form of project-based research. We interview half a dozen to a dozen customers, synthesize what we learn, and present our findings in a research deck. We rely on that deck (if we remember) throughout the project. At the end of the project, we might do some <a href="https://www.producttalk.org/2018/02/co-creating/" dir="ltr">validation research</a> to validate the design (through usability testing) or the final delivery (through <a href="https://www.producttalk.org/hypothesis-testing/" dir="ltr">A/B testing</a>).Sometimes we remember to assess the success of our project. But because we started with a project in the solution space, we don’t always know what success looks like. We rarely take the time upfront to define what problem the solution is intended to solve or what impact it might have on the business. This is why we so often define success as shipping working software.In a project world, most of the product discovery decisions are made by business stakeholders in the annual budgeting process and our product discovery activities are limited to project-based interviews (interviews conducted during a dedicated phase) and validation research (usability testing and A/B testing).<h2>The Need for Continuous Discovery</h2>The best teams, however, are recognizing that digital products are never done. We can always iterate and improve. Facebook and Netflix will never be finished projects. If they stopped iterating and developing, their competitors would catch up. For example, Netflix started as a DVD-by-mail service, iterated to streaming movies, and now creates its own original programming. They’ve also released countless new features, improved their recommendations engine, and enhanced the user interface.Good product teams know we can always create more value for our customers and in turn create more value for our business. This shift in mindset often gets referred to as “product thinking” or as a “product mindset.”<BLOCKQUOTE>The best teams recognize that digital products are never done. We can always iterate and improve. – <a href="https://ctt.ac/b0dN9" dir="ltr">Tweet This</a></BLOCKQUOTE>While there’s nothing inherently wrong with project-based research, it’s not sufficient for teams who continuously ship value to customers. The key idea is this simple: If we are continuously making decisions about what to build, we need to stay continuously connected to our customers, so that we can ensure that our product discovery decisions will work for our customers.As we build digital products, we build expertise in our products. We know what the product is capable of, we know where everything lives in the interface, we know how everything works—after all, we decided all of those things. The challenge is that our customers don’t share this expertise.Product people suffer from a bias called the “<a href="https://hbr.org/2006/12/the-curse-of-knowledge" dir="ltr">curse of knowledge</a>.” As we develop expert knowledge about our product, we forget what it was like before we had that knowledge. We can’t imagine what it’s like for our customers to not have this knowledge.This becomes a significant problem when we make daily product discovery decisions without input from our customers. We start making those decisions from our expert point of view, and we end up making decisions that don’t necessarily work for our customers.Thankfully, there’s an easy way to avoid this fate.Every time we engage with a customer, we start to see the gap between how we think about the product and how our customers think about the product. Most teams, when exposed to this gap, work hard to overcome it. Good product discovery teams <a href="https://www.producttalk.org/2017/10/keystone-habit/" dir="ltr">engage with customers at least weekly</a>, minimizing the number of decisions they make without customer input.<h2>The Underlying Structure of Product Discovery</h2><img src="https://www.producttalk.org/wp-content/uploads/2021/08/Opportunity-Solution-Tree-Blog-Newsletter.png" alt="A diagram of an opportunity solution tree. There's a desired outcome at the top, which branches out into several opportunitiesThese opportunities branch out into other opportunities, which branch out into solutions. Each solution branches out into several experiments." width="550" height="550" srcset="https://www.producttalk.org/wp-content/uploads/2021/08/Opportunity-Solution-Tree-Blog-Newsletter.png 550w, https://www.producttalk.org/wp-content/uploads/2021/08/Opportunity-Solution-Tree-Blog-Newsletter-300x214.png 300w">The opportunity solution tree provides a clear framework for product discovery.When we acknowledge that digital products are never done, we have to redefine the work that we do. It’s no longer as simple as shipping a project. To shift from a project mindset to a product mindset we can’t just focus on delivering outputs. We have to ask, “What impact did those outputs have?” We measure impact with <a href="https://www.producttalk.org/2020/05/product-outcomes/" dir="ltr">outcomes</a>.Good product discovery starts with a clear outcome.Business leaders typically ask teams to deliver business outcomes. A business outcome measures the health of the business and is usually a financial metric (e.g. increase customer acquisition, reduce churn) or measures progress against a strategic initiative (e.g. increase market share, increase countries served).Product teams need to translate those outcomes into product outcomes that they can impact. A product outcome measures how well the product supports a given business outcome. It measures a customer behavior that occurs in the product where the team either suspects or knows that the product outcome is a leading indicator of the business outcome. The product outcome represents how the product team can create business value.You can learn more about how to translate business outcomes into product outcomes in our <a href="https://producttalk.org/course/defining-outcomes" dir="ltr">Defining Outcomes course</a>.Once a product outcome is selected, the product team needs to discover the <a href="https://www.producttalk.org/2020/07/opportunity-mapping/" dir="ltr">opportunity space</a>. Opportunities represent customer needs, pain points, and desires. The opportunity space is infinite. The team’s goal is to discover opportunities that have the potential to drive their product outcome. Opportunities represent how a team can create customer value.And finally, teams need to discover solutions that will address those opportunities. The solution space is also infinite.Good product discovery has a simple underlying structure: Start with an outcome, discover opportunities, discover solutions.<BLOCKQUOTE>Good product discovery has a simple underlying structure: Start with an outcome, discover opportunities, discover solutions. – <a href="https://ctt.ac/dUKd5" dir="ltr">Tweet This</a></BLOCKQUOTE>Simple, however, does not mean easy. Product teams can use <a href="https://www.producttalk.org/opportunity-solution-tree/" dir="ltr">opportunity solution trees</a> to help them keep sight of the underlying structure of product discovery as they iterate and learn.<h2>Product Discovery: Week Over Week</h2><img src="https://www.producttalk.org/wp-content/uploads/2021/08/Continuous-Discovery-Overview-Blog-Newsletter.png" alt="At the center of the image, there's an opportunity solution tree with an outcome at the top, branching into opportunities, which, in turn, branch into solutions. Around the tree there are illustrations showing the activities the product team does such as conducting weekly interviews with customers, negotiating a product outcome with the product leader, and building prototypes and running product experiments weekly." width="550" height="550" srcset="https://www.producttalk.org/wp-content/uploads/2021/08/Continuous-Discovery-Overview-Blog-Newsletter.png 550w, https://www.producttalk.org/wp-content/uploads/2021/08/Continuous-Discovery-Overview-Blog-Newsletter-300x210.png 300w">What does product discovery look like week over week? This diagram shows the product team’s main activities.Good product discovery teams engage in two key activities week over week: <a href="https://www.producttalk.org/customer-interviews/" dir="ltr">customer interviewing</a> and <a href="https://www.producttalk.org/2017/08/experiment-design/" dir="ltr">assumption testing</a>. Interviewing helps us discover opportunities and assumption testing helps us discover solutions.<BLOCKQUOTE>Good product discovery teams engage in two key activities week over week: customer interviewing and assumption testing. Interviewing helps us discover opportunities and assumption testing helps us discover solutions. – <a href="https://ctt.ac/6v9We" dir="ltr">Tweet This</a></BLOCKQUOTE>When interviewing customers, our goal is to discover customer needs, pain points, and desires (collectively called “<a href="https://www.producttalk.org/2020/07/opportunity-mapping/" dir="ltr">opportunities</a>”) that, if we were to address them, would help us drive our outcome. Opportunities emerge from customer stories.We can’t simply ask customers what they need or want. Cognitive biases interfere with our customers’ ability to answer these questions reliably. Instead, we want to listen for needs, pain points, and desires in the context of specific stories.You can learn more about how to interview to collect specific stories in our <a href="https://producttalk.org/course/continuous-interviewing" dir="ltr">Continuous Interviewing course</a>.The opportunity space is always evolving. New competitors enter our markets. New technology disrupts what’s possible. Even our own code releases cause shifts in the opportunity space. Good product discovery teams interview week over week so that they can keep tabs on these constant changes.You can learn more about how to map out the opportunity space in our <a href="https://producttalk.org/course/opportunity-mapping" dir="ltr">Opportunity Mapping course</a>.When it comes to discovering solutions, many teams rely on project research. They do full-solution <a href="https://www.producttalk.org/2018/01/rapid-prototyping/" dir="ltr">prototype testing</a> or they run <a href="https://www.producttalk.org/hypothesis-testing/" dir="ltr">A/B tests</a> to understand impact. Full-solution prototypes require that we do all of the design work upfront before we know if we are designing the right product. A/B testing requires that we build the full solution before we know if it was the right product to build. We don’t want to do all of this work upfront before we have some evidence that we are on the right track.Instead, we can use rapid assumption tests to quickly understand which solutions have promise. Assumptions fall into five categories: desirable, viable, feasible, usable, and ethical. Good product discovery teams use <a href="https://www.jpattonassociates.com/story-mapping/" dir="ltr">story mapping</a> to help them quickly uncover hidden assumptions. Story maps illustrate what a customer needs to do to get value from a solution. Product teams can then walk through the map, asking for each step, “What needs to be true in order for our customer to do this step?” This exercise will help you generate assumptions across all five categories.We can rapidly test our assumptions with prototype tests that are designed to simulate a specific moment, one-question surveys, data mining, and research spikes. You can learn more about each of these types of assumption tests in my book <a href="https://amzn.to/3hGkNYT" dir="ltr">Continuous Discovery Habits</a>.Assumption testing allows us to collect the data we need to <a href="https://www.producttalk.org/2017/09/compare-and-contrast-decisions/" dir="ltr">compare and contrast</a> our different solutions against each other.<h2>Who Does Product Discovery?</h2><img src="https://www.producttalk.org/wp-content/uploads/2021/08/product-trio.jpeg" alt="A diagram illustrating the product trio. There is a product manager, a design lead, and a tech lead arranged in a triangle labeled &quot;The Trio.&quot;" width="550" height="550" srcset="https://www.producttalk.org/wp-content/uploads/2021/08/product-trio.jpeg 550w, https://www.producttalk.org/wp-content/uploads/2021/08/product-trio-300x169.jpeg 300w">The product trio—comprised of a product manager, design lead, and tech lead—is responsible for product discovery.A <a href="https://www.producttalk.org/2021/05/product-trio/" dir="ltr">product trio</a>—typically comprised of a product manager, a designer, and a software engineer—leads product discovery. However, that doesn’t mean other members of the team don’t contribute. The product team should pull in different members of the team based on the types of decisions they are making.<BLOCKQUOTE>A product trio—typically comprised of a product manager, a designer, and a software engineer—leads product discovery. 
– <a href="https://ctt.ac/tNy7M" dir="ltr">Tweet This</a></BLOCKQUOTE>The product trio should <a href="https://www.producttalk.org/2020/03/interview-customers-together/" dir="ltr">interview customers together</a>. They should collaborate on and execute <a href="https://www.producttalk.org/2017/08/experiment-design/" dir="ltr">assumption tests</a> together. These are the key inputs to good product discovery decisions.If you want to learn more about how product trios can work together to lead product discovery, <a href="https://www.youtube.com/playlist?list=PLD4atqlPcvA5G7gqRiE1cYw1lDpcAyWTL" dir="ltr">see this video series</a>.<h2>What Other Questions Do You Have?</h2>Did I miss anything? Do you have other questions about product discovery? <a href="https://www.producttalk.org/contact/" dir="ltr">Get in touch</a>.<h1 data-css="tve-u-15e63f83f8bc15" data-default="Your Heading Here" dir="ltr">Get the latest from Product Talk right in your inbox. Never miss an article.</h1><div data-css="tve-u-55e63f83f8bc1b" data-tcb_hover_state_parent="" data-button-style="rounded"><button type="submit">Subscribe Now&nbsp;</button></div>

Product discovery is a hot topic in the product world. This article covers what it is, the history and evolution, and today's best practices.

Stashed ideas

Continuous Discovery Habits

Product discovery is becoming a trendy topic in the world of digital products. Why? What is it? And what do you need to know about it? I’ve got you covered. This article will cover the ins and outs of product discovery.

Product discovery is often defined in comparison to product delivery.

We typically define product discovery in contrast with product delivery. Product discovery is used to describe the work that we do to <a dir="ltr" href="https://www.producttalk.org/decision-making/">make decisions </a>about what to build, while product delivery is the work we do to build, ship, and maintain a production quality product.

Good product discovery includes the customer throughout the decision-making process. We have dozens of tactics and frameworks that are often associated with product discovery: <a dir="ltr" href="https://www.producttalk.org/customer-interviews/">customer interviews </a>, usability tests, <a dir="ltr" href="https://www.producttalk.org/hypothesis-testing/">A/B tests </a>, demand tests, <a dir="ltr" href="https://www.producttalk.org/2017/08/experiment-design/">assumption tests </a>, customer journey mapping, experience mapping, <a dir="ltr" href="https://www.jpattonassociates.com/user-story-mapping/">story mapping </a>, <a dir="ltr" href="https://www.strategyzer.com/blog/how-assumptions-mapping-can-focus-your-teams-on-running-experiments-that-matter">assumption mapping </a>, OKRs, <a dir="ltr" href="https://www.producttalk.org/opportunity-solution-tree/">opportunity solution trees </a>, impact mapping, jobs-to-be-done, ethnographic studies, customer visits, and so on.

Good product discovery includes the customer throughout the decision-making process. – <a dir="ltr" href="https://ctt.ac/4aGLp">Tweet This </a>

It’s easy to get overwhelmed by all the methods. But the underlying principle is simple. Product discovery is a decision-making process. Good product discovery includes the customer throughout that process.

Most of us grew up in a project world. Our companies conduct annual budgeting routines that involve resourcing projects or initiatives for the year. Most of these projects are framed in the solution space—they take the form of “build this feature” or “launch this program.”

Projects have a beginning, a middle, and an end. We typically mark a project as finished once we release code to our production environment. Oftentimes, projects are sourced from <a dir="ltr" href="https://www.producttalk.org/2018/06/managing-stakeholders/">business stakeholders </a>, customers, or occasionally the project teams that are implementing them.

If we are lucky, we might do some customer research at the beginning of the project. If we do, it’s usually in the form of project-based research. We interview half a dozen to a dozen customers, synthesize what we learn, and present our findings in a research deck. We rely on that deck (if we remember) throughout the project. At the end of the project, we might do some <a dir="ltr" href="https://www.producttalk.org/2018/02/co-creating/">validation research </a>to validate the design (through usability testing) or the final delivery (through <a dir="ltr" href="https://www.producttalk.org/hypothesis-testing/">A/B testing </a>).

Sometimes we remember to assess the success of our project. But because we started with a project in the solution space, we don’t always know what success looks like. We rarely take the time upfront to define what problem the solution is intended to solve or what impact it might have on the business. This is why we so often define success as shipping working software.

In a project world, most of the product discovery decisions are made by business stakeholders in the annual budgeting process and our product discovery activities are limited to project-based interviews (interviews conducted during a dedicated phase) and validation research (usability testing and A/B testing).

The best teams, however, are recognizing that digital products are never done. We can always iterate and improve. Facebook and Netflix will never be finished projects. If they stopped iterating and developing, their competitors would catch up. For example, Netflix started as a DVD-by-mail service, iterated to streaming movies, and now creates its own original programming. They’ve also released countless new features, improved their recommendations engine, and enhanced the user interface.

Good product teams know we can always create more value for our customers and in turn create more value for our business. This shift in mindset often gets referred to as “product thinking” or as a “product mindset.”

The best teams recognize that digital products are never done. We can always iterate and improve. – <a dir="ltr" href="https://ctt.ac/b0dN9">Tweet This </a>

While there’s nothing inherently wrong with project-based research, it’s not sufficient for teams who continuously ship value to customers. The key idea is this simple: If we are continuously making decisions about what to build, we need to stay continuously connected to our customers, so that we can ensure that our product discovery decisions will work for our customers.

As we build digital products, we build expertise in our products. We know what the product is capable of, we know where everything lives in the interface, we know how everything works—after all, we decided all of those things. The challenge is that our customers don’t share this expertise.

Product people suffer from a bias called the “<a dir="ltr" href="https://hbr.org/2006/12/the-curse-of-knowledge">curse of knowledge </a>.” As we develop expert knowledge about our product, we forget what it was like before we had that knowledge. We can’t imagine what it’s like for our customers to not have this knowledge.

This becomes a significant problem when we make daily product discovery decisions without input from our customers. We start making those decisions from our expert point of view, and we end up making decisions that don’t necessarily work for our customers.

Thankfully, there’s an easy way to avoid this fate.

Every time we engage with a customer, we start to see the gap between how we think about the product and how our customers think about the product. Most teams, when exposed to this gap, work hard to overcome it. Good product discovery teams <a dir="ltr" href="https://www.producttalk.org/2017/10/keystone-habit/">engage with customers at least weekly </a>, minimizing the number of decisions they make without customer input.

The opportunity solution tree provides a clear framework for product discovery.

When we acknowledge that digital products are never done, we have to redefine the work that we do. It’s no longer as simple as shipping a project. To shift from a project mindset to a product mindset we can’t just focus on delivering outputs. We have to ask, “What impact did those outputs have?” We measure impact with <a dir="ltr" href="https://www.producttalk.org/2020/05/product-outcomes/">outcomes </a>.

Good product discovery starts with a clear outcome.

Business leaders typically ask teams to deliver business outcomes. A business outcome measures the health of the business and is usually a financial metric (e.g. increase customer acquisition, reduce churn) or measures progress against a strategic initiative (e.g. increase market share, increase countries served).

Product teams need to translate those outcomes into product outcomes that they can impact. A product outcome measures how well the product supports a given business outcome. It measures a customer behavior that occurs in the product where the team either suspects or knows that the product outcome is a leading indicator of the business outcome. The product outcome represents how the product team can create business value.

You can learn more about how to translate business outcomes into product outcomes in our <a dir="ltr" href="https://producttalk.org/course/defining-outcomes">Defining Outcomes course </a>.

Once a product outcome is selected, the product team needs to discover the <a dir="ltr" href="https://www.producttalk.org/2020/07/opportunity-mapping/">opportunity space </a>. Opportunities represent customer needs, pain points, and desires. The opportunity space is infinite. The team’s goal is to discover opportunities that have the potential to drive their product outcome. Opportunities represent how a team can create customer value.

And finally, teams need to discover solutions that will address those opportunities. The solution space is also infinite.

Good product discovery has a simple underlying structure: Start with an outcome, discover opportunities, discover solutions.

Good product discovery has a simple underlying structure: Start with an outcome, discover opportunities, discover solutions. – <a dir="ltr" href="https://ctt.ac/dUKd5">Tweet This </a>

Simple, however, does not mean easy. Product teams can use <a dir="ltr" href="https://www.producttalk.org/opportunity-solution-tree/">opportunity solution trees </a>to help them keep sight of the underlying structure of product discovery as they iterate and learn.

What does product discovery look like week over week? This diagram shows the product team’s main activities.

Good product discovery teams engage in two key activities week over week: <a dir="ltr" href="https://www.producttalk.org/customer-interviews/">customer interviewing </a>and <a dir="ltr" href="https://www.producttalk.org/2017/08/experiment-design/">assumption testing </a>. Interviewing helps us discover opportunities and assumption testing helps us discover solutions.

Good product discovery teams engage in two key activities week over week: customer interviewing and assumption testing. Interviewing helps us discover opportunities and assumption testing helps us discover solutions. – <a dir="ltr" href="https://ctt.ac/6v9We">Tweet This </a>

When interviewing customers, our goal is to discover customer needs, pain points, and desires (collectively called “<a dir="ltr" href="https://www.producttalk.org/2020/07/opportunity-mapping/">opportunities </a>”) that, if we were to address them, would help us drive our outcome. Opportunities emerge from customer stories.

We can’t simply ask customers what they need or want. Cognitive biases interfere with our customers’ ability to answer these questions reliably. Instead, we want to listen for needs, pain points, and desires in the context of specific stories.

You can learn more about how to interview to collect specific stories in our <a dir="ltr" href="https://producttalk.org/course/continuous-interviewing">Continuous Interviewing course </a>.

The opportunity space is always evolving. New competitors enter our markets. New technology disrupts what’s possible. Even our own code releases cause shifts in the opportunity space. Good product discovery teams interview week over week so that they can keep tabs on these constant changes.

You can learn more about how to map out the opportunity space in our <a dir="ltr" href="https://producttalk.org/course/opportunity-mapping">Opportunity Mapping course </a>.

When it comes to discovering solutions, many teams rely on project research. They do full-solution <a dir="ltr" href="https://www.producttalk.org/2018/01/rapid-prototyping/">prototype testing </a>or they run <a dir="ltr" href="https://www.producttalk.org/hypothesis-testing/">A/B tests </a>to understand impact. Full-solution prototypes require that we do all of the design work upfront before we know if we are designing the right product. A/B testing requires that we build the full solution before we know if it was the right product to build. We don’t want to do all of this work upfront before we have some evidence that we are on the right track.

Instead, we can use rapid assumption tests to quickly understand which solutions have promise. Assumptions fall into five categories: desirable, viable, feasible, usable, and ethical. Good product discovery teams use <a dir="ltr" href="https://www.jpattonassociates.com/story-mapping/">story mapping </a>to help them quickly uncover hidden assumptions. Story maps illustrate what a customer needs to do to get value from a solution. Product teams can then walk through the map, asking for each step, “What needs to be true in order for our customer to do this step?” This exercise will help you generate assumptions across all five categories.

We can rapidly test our assumptions with prototype tests that are designed to simulate a specific moment, one-question surveys, data mining, and research spikes. You can learn more about each of these types of assumption tests in my book <a dir="ltr" href="https://amzn.to/3hGkNYT">Continuous Discovery Habits </a>.

Assumption testing allows us to collect the data we need to <a dir="ltr" href="https://www.producttalk.org/2017/09/compare-and-contrast-decisions/">compare and contrast </a>our different solutions against each other.

The product trio—comprised of a product manager, design lead, and tech lead—is responsible for product discovery.

A <a dir="ltr" href="https://www.producttalk.org/2021/05/product-trio/">product trio </a>—typically comprised of a product manager, a designer, and a software engineer—leads product discovery. However, that doesn’t mean other members of the team don’t contribute. The product team should pull in different members of the team based on the types of decisions they are making.

A product trio—typically comprised of a product manager, a designer, and a software engineer—leads product discovery. – <a dir="ltr" href="https://ctt.ac/tNy7M">Tweet This </a>

The product trio should <a dir="ltr" href="https://www.producttalk.org/2020/03/interview-customers-together/">interview customers together </a>. They should collaborate on and execute <a dir="ltr" href="https://www.producttalk.org/2017/08/experiment-design/">assumption tests </a>together. These are the key inputs to good product discovery decisions.

If you want to learn more about how product trios can work together to lead product discovery, <a dir="ltr" href="https://www.youtube.com/playlist?list=PLD4atqlPcvA5G7gqRiE1cYw1lDpcAyWTL">see this video series </a>.

Did I miss anything? Do you have other questions about product discovery? <a dir="ltr" href="https://www.producttalk.org/contact/">Get in touch </a>.

Get the latest from Product Talk right in your inbox.  Never  miss an article.

Bite-sized knowledge
to upgrade
your career

Product Discovery Basics: Everything You Need to Know - Product Talk

Product Discovery

The Product Mindset

The Curse of Knowledge in Product Development

The Underlying Structure of Product Discovery

IDEAS ABOUT

MORE LIKE THIS

How product teams can measure progress through outcome OKRs

The Key to Fast Growth is Achieving Product-Market Fit

Problem Statements in UX Discovery

It's time to

READ

LIKE

A PRO!

Bite-sized knowledgeto upgradeyour career

Product Discovery Basics: Everything You Need to Know - Product Talk

Product Discovery

The Product Mindset

The Curse of Knowledge in Product Development

The Underlying Structure of Product Discovery

IDEAS ABOUT

MORE LIKE THIS

How product teams can measure progress through outcome OKRs

The Key to Fast Growth is Achieving Product-Market Fit

Problem Statements in UX Discovery

It's time to

READ

LIKE

A PRO!

Bite-sized knowledge
to upgrade
your career