How to Run Product Discovery: A Step-by-Step Process

Most product discovery still happens the old way: a research phase at the start of a project, a round of interviews, a handoff to design, then nothing. The team ships, moves to the next project, and doesn’t talk to a customer again until something breaks. The problem with this model isn’t the research itself, it’s the gap. Customer needs don’t pause between projects, and a team that only checks in occasionally is making most of its decisions on assumptions that go stale.

Product discovery coach Teresa Torres, whose book Continuous Discovery Habits has become the standard reference for this shift, defines continuous discovery as, at minimum, weekly touchpoints with customers, conducted by the team actually building the product, in pursuit of a specific desired outcome. That’s the model this guide walks through: not a one-time research sprint, but a repeatable weekly process any PM can actually run. It’s one of the best places to learn how to run product discovery.

Who Should Be Involved: The Product Trio

Discovery doesn’t work as a solo PM activity conducted in isolation and handed off afterward. Torres’s framework centers on what she calls the product trio, typically a product manager, a designer, and a tech lead engineer, running discovery together rather than through serial handoffs where a PM defines, a designer mocks up, and an engineer builds without ever hearing the customer conversation firsthand.

The reasoning behind this matters. Three different disciplines in the same customer conversation surface different signals: a designer notices a usability friction point a PM might miss entirely, an engineer flags a technical constraint before it becomes a wasted design cycle. Teams that run discovery as a trio consistently catch bad bets earlier than teams relying on a single researcher’s summarized notes passed along after the fact.

Step 1: Define the Outcome, Not the Feature

Before any interview gets scheduled, define what you’re actually investigating and which decision the work needs to support. This is where most discovery efforts go wrong immediately, starting from a feature idea already in mind rather than a genuine open question.

Torres distinguishes between business outcomes, financial or company-health metrics, and product outcomes, specific customer behavior or sentiment shifts your team can directly influence. A vague goal like “improve onboarding” isn’t a usable discovery outcome. “Increase the percentage of new users who complete their first key action within 48 hours” is, because it’s specific enough to know when you’ve actually made progress, and it doesn’t presuppose which feature will get you there.

Step 2: Build an Opportunity Solution Tree

The Opportunity Solution Tree, Torres’s central visual framework, is what keeps continuous discovery from turning into an unstructured pile of interview notes. According to Torres’s own writing on Product Talk, the tree has four connected layers: the outcome at the root, opportunities, customer needs, pain points, and desires that emerged from research, branching below it, potential solutions attached to each opportunity, and experiments or assumption tests attached to each solution to evaluate whether it’s actually worth building.

The tree isn’t built once and left static, it grows and shifts as evidence comes in from ongoing interviews. Its real value is forcing explicit connections: every solution on the tree should trace back through a real customer opportunity to the outcome at the root. A feature idea that can’t trace back that way is a solution looking for a justification, not something discovery actually surfaced.

Teresa Torres’s Opportunity Solution Tree connects a specific desired outcome to the customer opportunities, potential solutions, and assumption tests that support it, giving a product team a structured way to keep every proposed solution traceable back to real evidence rather than an assumption. The tree isn’t static, it updates continuously as weekly customer interviews surface new opportunities or invalidate existing branches.

Step 3: Run Weekly Customer Interviews the Right Way

Weekly is the cadence Torres recommends, at minimum one interview per product trio per week. According to research and coaching platform GreatQuestion’s synthesis of the framework, monthly cadences are too infrequent to sustain the habit, learning velocity drops and teams start treating discovery as a project again rather than an ongoing practice.

How the interview is conducted matters as much as the cadence. A common mistake, highlighted in a Shortform summary of Torres’s book, is asking customers general, forward-looking questions like “what features do you look for in a new laptop.” These produce vague, unreliable answers because people are bad at predicting their own future behavior. The better approach asks about a specific, recent, real experience instead, “tell me about the last time you bought a new laptop,” walking through what actually happened, not what someone imagines they’d do in the abstract.

Also Read: Product Prioritzation Frameworks – RICE, MoSCoW

Step 4: Map What You Learn Onto the Tree

After each interview, the trio maps new insight directly onto the Opportunity Solution Tree, adding a newly surfaced opportunity, strengthening an existing branch with fresh evidence, or occasionally invalidating a branch the team previously thought was worth pursuing. This step is what keeps discovery genuinely continuous rather than a series of disconnected conversations, each interview adds to a living, evolving map instead of sitting in an isolated notes document nobody revisits.

Step 5: Choose One Opportunity to Focus On

A tree with dozens of opportunity branches is common once a few months of continuous discovery accumulate. Trying to pursue all of them at once is a fast way to dilute a team’s effort across too many half-explored directions. The discipline here is choosing one opportunity at a time to focus solution generation and testing on, using the outcome at the root of the tree to judge which opportunity, if addressed, would move that outcome the most.

Step 6: Generate Multiple Solutions Before Committing

Once an opportunity is chosen, resist jumping straight to the first solution idea that comes to mind. Brainstorming several genuinely different solutions to the same opportunity, before committing engineering time to any of them, surfaces options a team would otherwise never consider, and it protects against anchoring on a familiar pattern just because it’s the first idea on the table.

Step 7: Test the Riskiest Assumption Before You Build

Every solution rests on assumptions, about desirability, whether customers actually want it, viability, whether it makes business sense, feasibility, whether it can actually be built, and usability, whether people can figure out how to use it. Before committing real development time, identify the riskiest of these assumptions, the one most likely to be wrong and most costly if it is, and design a small, fast experiment to test it directly.

Shortform’s summary of Torres’s methodology gives a concrete illustration: simulating a purchase decision by presenting participants with a list of available options and observing what they actually choose. If a team assumes their first-person-shooter game concept will appeal to a given audience, but simulation participants consistently choose platform and puzzle games instead, that’s real evidence the underlying assumption is wrong, gathered before a single line of production code gets written.

Step 8: Feed Evidence Back Into Delivery, Then Keep the Loop Running

Once a solution has survived assumption testing, it moves into delivery, where the trio, alongside the broader engineering team, actually builds it. Discovery doesn’t stop here. According to guidance from product discovery platform Zfort, the steps in this process describe types of work, not a strict one-way sequence, teams move backward and forward as evidence changes, and behavior observed once a feature ships, real production data and customer response, feeds directly back into the tree, informing the next round of discovery.

This is the core distinction between continuous discovery and the old upfront-research model: the loop never fully closes. It keeps running, week after week, as long as the product exists.

Also Read: Most Asked Product Manager Interview Questions

Common Mistakes That Undermine Product Discovery

A handful of failure patterns show up repeatedly across teams attempting this process, and naming them directly helps avoid repeating them.

Treating discovery as a one-off phase rather than an ongoing habit is the most common. A single round of interviews at project kickoff produces a snapshot that goes stale within months, while customer needs keep shifting underneath it.

Delegating discovery entirely to a researcher who summarizes findings afterward, rather than having the actual product trio present in the room, loses signal. According to Product Talk’s own definition of continuous discovery, the team building the product must directly interact with customers, not learn secondhand through a report or a persona document assembled by someone else.

Asking customers what they want, in the abstract, instead of asking about specific past behavior, produces unreliable input that feels like real research but rarely predicts what people actually do.

Skipping assumption testing and jumping straight from a promising interview to a full build is a mistake that erases most of the value discovery was supposed to provide. The entire point of a small, fast experiment is catching a wrong assumption before it costs a full development cycle, not after.

And the opposite failure, running research indefinitely without ever converging on a decision, is just as damaging. As Torres has put it directly in her own commentary, teams that try to run every single discovery habit perfectly for every single thing they work on often end up doing nothing at all. Discovery is meant to inform a decision, not replace one.

How to Start If Your Team Currently Does Zero Discovery

If none of this exists at your company yet, don’t try to implement all eight steps simultaneously. Torres’s own guidance, described through frameworks like the SPICEY approach documented on Product Talk, recommends starting with the smallest sustainable action rather than attempting a full continuous discovery practice overnight.

For a team currently operating as a pure feature factory, building whatever’s requested without real customer input, the first habit worth building alone is simply committing to one real customer interview a week, even without a fully built Opportunity Solution Tree yet. The structure can be layered in once the weekly habit itself is genuinely sustainable, trying to build the full system before the basic habit exists is one of the more common reasons teams abandon continuous discovery within the first month.

In conclusion…

Product discovery stops being a one-time research phase and becomes a genuine competitive advantage once it’s run as a continuous, weekly habit rather than a project with a start and end date. Define a real outcome, build a living Opportunity Solution Tree connecting that outcome to actual customer evidence, and test the riskiest assumption behind every solution before committing real engineering time to it. The process isn’t about generating more research. It’s about making sure fewer product decisions get made on pure guesswork.

If you want to practice running this process on a real product scenario, our Product Management Course covers discovery frameworks, interview technique, and assumption testing with guided exercises.

FAQs on How to Run Product Discovery