What is Product Discovery? [Process, Methods, and Benefits]
A guide for people that want to build the right product.
Reading time: 20 minutes
If you’re making products, then product discovery is how you go pro.
How can you be sure that customers will use the stuff you build? Anyone who spent a year on a failed product knows the value of checking ideas before committing to weeks of work.
How do you ensure you’re building the right thing before building it?
Read this if:
You want to design user-centered products
You want a system for evaluating ideas with data
You want to learn how modern, empowered product teams work at Netflix, Amazon, and Google
Before product discovery, designing software didn’t require much thinking. It was all delivery.
Ideas came from the top, mostly. The people at the top gave the ideas to the people in the middle, who mildly discussed them and turned them into “requirements” for workers at the bottom.
The waterfall delivery system before Product Discovery
This top-down system was a Waterfall Delivery System designed to optimize delivery. Even if one stage was Agile to customer change, the system stayed locked into Waterfall because the ideas flowed from the top. If you worked in this system, your best bet was to keep your head down and deliver.
But users of products don’t care if ideas come from executives if the ideas suck.
What is Product Discovery?
Here’s a quick definition of product discovery:
Product Discovery is a system where the product team collaboratively decides what gets built after systematically gathering evidence through research and experimentation.
Product discovery is a system for evaluating ideas before launch. Product discovery is non-linear and occurs in parallel with delivery. The process of product discovery helps you improve product decisions and helps you de-risk ideas before investing in code and infrastructure.
A key output of product discovery is deciding what ideas to deliver. Decisions made after product discovery should be democratic and evidence-based. Data helps the team determine what problems are worth solving and which ideas are worth designing.
Product Discovery vs. Product Delivery
To understand product discovery, you have to understand product delivery. In the real world, activities from discovery and delivery will blend and happen at the same time. Let’s examine the methods and mentalities involved in both.
[a non-exhaustive list of research methods and where they might happen by Jeff Humble]
What’s different about product discovery vs. delivery
Doing research vs. Polishing solutions
Focusing on problems vs. Focusing on solutions
Primarily qualitative data vs. Primarily quantitative data
Learning fast vs. Learning thoroughly
Validating the need vs. Validating the details
Rapid experimentation vs. Optimization
If you’re a product manager, UX designer, or researcher, much of your work will be discovery. You might split your work between discovery and delivery, especially if you’re a UI designer or an engineer.
Product Discovery or “Build the right thing.”
The discovery mindset is choosing the right idea using customer data as your guide. A common goal for this phase is getting a validated backlog of product ideas.
A great duo of skills for discovery are the problem-focused skills of UX research and strategy. In this phase, you might prioritize qualitative learnings that you gather directly from current or potential users of your product. Since the idea is new, you should simulate the experience with a prototype. Lean on your designers for this research & conceptualization work.
Common product discovery activities
These product discovery activities help you "build the right thing."
Interview users and explore problems
Send out a survey and identify problem areas worth solving
Create a lo-fi prototype and get feedback on an early idea
Design an experiment to test an assumption
Run a brainstorming session with stakeholders
Research and analyze competitors with a SWOT diagram
Conduct a usability test with a prototype to identify big issues
Facilitate a workshop to understand internal challenges
Share research findings and insights
Product Delivery or “Build the thing right.”
Product discovery is the opposite of product delivery and should happen in parallel. The mindset of delivery is optimizing solutions for maximum effectiveness. A common goal for this phase is releasing the next iteration of a feature.
You might prioritize quantitative learnings from real-world usage and large sample sizes in this phase. Since the ideas will be in code, you will have access to more data to analyze. An excellent skills duo for this phase are the solution-optimizing skills of data analytics & UI design. Together, those skills will provide innovative results in delivery work.
Common product delivery activities
These product delivery activities ensure you "build the thing right."
Design high-fidelity mockups
Iterate on details of the interface
Do a handover meeting with engineers
Run a closed card sort with users
Write micro-copy for the page
Create animations for the loading screen
Conduct a usability test of your product vs. the competitor’s product
Check the performance of solutions using product analytics
Reduce the file size of your images
Instrument the analytics for a page
What is the Product Discovery Process?
The Double Diamond is the most common process followed for product discovery.
I know that might be surprising to designers who thought the Double Diamond was the entire process. Turns out that everything we consider UX and service design is a product discovery process.
When the Double Diamond is used to describe product discovery and delivery, it might be labeled a bit differently. We like the extra diamond to understand the design and development process of delivering solutions. This version of the Double Diamond is known as the Triple Diamond, and it has two diamonds in discovery and one in delivery.
We can split the discovery process into two distinct phases: problem discovery and solution discovery.
Problem Discovery in Product Discovery
Problem discovery starts with an initial problem or challenge and ends with a validated problem, sometimes called an “opportunity” in the product discovery world.
Problem discovery seeks to understand problems to create better solutions. Teams will conduct primary research like user interviews, surveys, and ethnography. You might also conduct secondary research on competitors, product reviews, scientific papers, etc.
Solution Discovery in Product Discovery
Solution discovery starts with a final problem and ends with a validated solution.
Solution discovery seeks to find an optimal first version of a solution to be delivered. Teams will conduct initial solution iteration activities like wireframing, storyboarding, prototyping, and user story mapping.
The Full Product Discovery Process
I’ve taught a very user-focused and advanced product discovery process for a few years. I think it can help you gather and generate data for product discovery.
The Fountain Institute’s Product Discovery Process
Start with your desired business outcome
Identify your research questions
Identify assumptions in those questions
Start recruiting users to answer your questions
Run in-depth user interviews with the product team
Capture user insights into the problem and analyze research data
Synthesize user insights and needs into a final problem statement
Finalize research questions and write any more that you discovered
Sketch and storyboard solution ideas with the team
Design lo-fi wireframes & prototypes that solve the problem
Set up lo-fi experiments with users using those prototypes
Run at least one experiment for every assumption
Gather learnings in an experiment retro and analyze experiment data
Synthesize experiment learnings into a final solution
Decide with the whole team which solutions should move into delivery
Of course, that’s a linear way to put a non-linear process. You might bounce from activity to activity in the real world, depending on the project.
Product discovery happens in parallel with delivery, a concept known as Dual-Track Agile. The parallel process is a bit complicated initially, but it’s a powerful way for teams to work well with current and future challenges.
Teams work in short sprints, doing both discovery and delivery tasks concurrently. The team is constantly working on two horizons: delivering things now and discovering things for later. Many of the sprint’s discovery tasks will eventually make it back as future delivery tasks.
History of Product Discovery
The term comes from product consultant and author Marty Cagan, inspired by the drug discovery process in the pharmaceutical industry, where you used clinical trials to bring a drug to market. Back in 2007, Marty’s goal was to help product managers understand their real job is discovery, not delivery. [Cagan, 2020]
When Marty coined the term, there was a perception that product leadership meant making up requirements and telling everyone what to do. The problem with that mentality is that predicting what customers will do is risky, especially if they haven’t researched the customer.
Today, the term is catching fire with companies that understand customer-driven discovery is the real decider of corporate success, not executive-driven delivery.
Product discovery aimed to democratize deciding what to build using research and customer data. While the term and outcomes are often owned by product management, the work is for everyone on the product team.
Why care about product discovery?
Product discovery helps companies reduce risk and deliver products validated by customer data. But what about those below leadership? Product discovery is ideal for product teams, too.
1.) Product discovery allows teams to be autonomous
Product discovery is a systematic way to select ideas for delivery so you can rely on the system to feed good product ideas into the world.
The system works best when the people that are discovering are also delivering. Some organizations split the discovery and delivery work between two teams, but this can create a bottleneck when one team has to wait on another for a handoff, something product discovery teams avoid at all costs.
Executives will love this autonomy because it will help them scale product teams easily and quickly, depending on business needs.
2.) Product discovery helps you focus on user problems
If you're stuck in delivery work, you won't get to explore problems...only solutions.
UX Research, UX Strategy, and pretty much anything with UX require time for discovery. Give a UX Designer all delivery tasks, and you will severely limit the methods she can use.
It's like trying to design with one hand behind your back.
Products can’t reach their full potential if they focus solely on delivery. Tacking a usability test at the end of a project is like putting lipstick on a pig because, at that point, you can only make changes to the surface.
You might uncover a few problems, but what’s the point if you’ve already decided what to build? Product teams need to realize the power of understanding problems and stop building in the face of uncertainty. We have enough feature factories as it is.
3.) Product discovery reduces bias & risk
Product discovery is collaboratively deciding what to build, which invites more critical thinking. You can get multiple brains critiquing an idea and avoid Confirmation Bias, the tendency to favor data that matches personal expectations.
There are considerable risks involved in designing products.
The 4 Big Risks of Product
Desirability - Will customers find value in it?
Usability - Will customers be able to use it?
Viability - Will it be good for the business?
Feasibility - Can we build it?
Most of the product risk comes from customers being unwilling to adopt them. By testing the idea before building it, you can reduce the risk involved in the release.
4.) Product discovery is an easier sell than “research.”
For some reason, “research” can be a dirty word at tech companies.
More research can seem like an insult to executives proud of their idea. The “move fast and break things” mentality is prevalent; many executives see product teams as delivery teams. How do you explain that you must explore an idea further when your only job is building it?
Product discovery is research, but it’s a methodology that might be easier to sell to the suits upstairs. It uses the language they care about, like risk, confidence, and data.
"Can we get more budget for discovery?" may work better than saying, "Can we get more budget for research?"
5.) Product discovery builds customer expertise
Designing solutions for a vague, un-researched user is like designing with your hands behind your back. It’s the same for developers that don’t understand what the customer is doing with their code. Teams that learn about customers together get better at their jobs.
Teams that get good at product discovery immerse themselves in customer problems. That may not be an easy sell to management, but it’s a great way to improve overall work quality.
I’ve worked in both delivery and discovery teams, and I know I’m more motivated to work on a feature if I understand the background. If you haven’t felt the pain of watching a customer struggle through a poorly designed feature, you don’t know the motivation potential behind a well-understood problem. I seek to solve user problems more entirely if I also have empathy for their problems.
Rather than building whatever the highest-paid person’s opinion (known as the HiPPO) tells you, you can implement a discovery process that promotes team-wide learning.
So what is product discovery? It’s the exploration that helps you decide what to design & build.
Product discovery is working together to ensure you’re building what the customer needs. It’s better product design through user research. It improves your company’s product decisions by understanding users.
Product discovery learning resources
Check out these books on product discovery:
INSPIRED: How to Create Tech Products Customers Love by Marty Cagan
“Escaping the Build Trap: How Effective Product Management Creates Real Value” by Melissa Perri. Preview the book here.
Continuous Discovery Habits: Discover Products That Create Customer Value and Business Value by Teresa Torres
Sense & Respond, How Successful Organizations Listen to Customers and Create New Products by Jeff Gothelf & Josh Seiden
Check out these talks on product discovery
Watch Marty Cagan’s talk about Product Discovery here
Watch Teresa Torres give an introduction to product discovery here
Watch this webinar from Jeff on how to do research continuously here
Watch this webinar from Jeff on how to learn how to test product ideas before delivery here
Check out these articles on product discovery:
How to Product Discovery, Not Just Delivery by Jeff Humble
5 Ways to Make UX Research Agile by Pete Armitage
What is Continuous Research? by Jeff Humble
The UX Research Methods of Continuous Product Discovery Teams by Jeff Humble
