Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery. 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.
What is 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 make decisions 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: customer interviews, usability tests, A/B tests, demand tests, assumption tests, customer journey mapping, experience mapping, story mapping, assumption mapping, OKRs, opportunity solution trees, impact mapping, jobs-to-be-done, ethnographic studies, customer visits, and so on.
Good product discovery includes the customer throughout the decision-making process. – Tweet This
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.
Understanding Project-Based Discovery
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 business stakeholders, 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 validation research to validate the design (through usability testing) or the final delivery (through A/B testing).
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 Need for Continuous Discovery
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. – Tweet This
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 “curse of knowledge.” 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 engage with customers at least weekly, minimizing the number of decisions they make without customer input.
You can learn more about the evolution of product discovery here.
The Underlying Structure of Product Discovery
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 outcomes.
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 Defining Outcomes course.
Once a product outcome is selected, the product team needs to discover the opportunity space. 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. – Tweet This
Simple, however, does not mean easy. Product teams can use opportunity solution trees to help them keep sight of the underlying structure of product discovery as they iterate and learn.
How Do You Do Product Discovery?
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: customer interviewing and assumption testing. 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. – Tweet This
When interviewing customers, our goal is to discover customer needs, pain points, and desires (collectively called “opportunities”) 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 Continuous Interviewing course.
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 Opportunity Mapping course.
When it comes to discovering solutions, many teams rely on project research. They do full-solution prototype testing or they run A/B tests 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 story mapping 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 Continuous Discovery Habits.
Assumption testing allows us to collect the data we need to compare and contrast our different solutions against each other.
If you are new to discovery, be sure to check out the common mistakes most teams make when getting started.
Who Does Product Discovery?
The product trio—comprised of a product manager, design lead, and tech lead—is responsible for product discovery.
A product trio—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.
– Tweet This
The product trio should interview customers together. They should collaborate on and execute assumption tests 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, start here.
What Other Questions Do You Have?
Did I miss anything? Do you have other questions about product discovery? Get in touch.
