Product discovery definition

Product discovery is not a project phase. It is an ongoing loop that runs in parallel with delivery, aimed at answering one question before you build anything: is this the right problem to solve? Getting this wrong in an interview is common. Getting it wrong in a role is expensive. The two errors are related: candidates who describe discovery as something that happens “at the start” tend to also be the ones who treat it as a research handoff rather than an ownership practice.

Continuous discovery vs. customer discovery

These are distinct practices, and senior interviewers at companies running continuous delivery will catch candidates who conflate them.

Customer discovery (Steve Blank, IDEO) validates a new market hypothesis from scratch. It is bounded: you run it, you confirm or invalidate the hypothesis, you move on. It belongs in the zero-to-one phase of a company or a product line. It is not what most PM interview questions are asking about.

Continuous discovery (Teresa Torres, formalized in the 2021 book “Continuous Discovery Habits”) is an embedded, ongoing practice inside a delivery team. Torres’s minimum recommended cadence: one story-based customer interview per week, per product trio (PM, designer, engineer). “Story-based” is the operative phrase. You ask about a specific past experience (“Tell me about the last time you tried to do X”) rather than hypotheticals or feature requests. Hypotheticals produce polite fiction. Past stories produce real behavior.

The structural difference matters: customer discovery is a sprint; continuous discovery is a practice.

The opportunity solution tree

Torres’s Opportunity Solution Tree (OST) is the organizing structure for everything continuous discovery produces. Four layers:

Desired outcome. The business metric the team owns. This is the root. Every discovery effort is in service of moving it.
Opportunity space. Unmet customer needs, pain points, and desires that, if addressed, would improve the outcome. These come from the weekly interview cadence.
Solutions. Candidate approaches to addressing specific opportunities. Multiple solutions per opportunity; this is where creative range matters.
Assumption tests. Experiments at the leaf level that kill or confirm the riskiest bets before the team commits to a full build.

The OST gives interviewers a shorthand to probe: if you say “OST” and then describe it without the desired outcome at the root, or collapse opportunities and solutions into the same layer, the interviewer knows you have read about it but not used it.

The four risks and where the 2026 shift lands

Marty Cagan’s INSPIRED names four risks discovery must kill: value risk (will customers actually use it?), usability risk (can they figure it out without friction?), feasibility risk (can the team build it?), and business viability risk (does it produce an outcome the business can sustain?).

In 2026, feasibility risk is structurally lower for most software products. AI can scaffold a working prototype from a description in hours. That collapses one of the four risks and changes where discovery effort should concentrate. A candidate who centers their discovery answer on “I tested whether we could technically build it” signals they have not updated their mental model.

The new concentration: viability (is there clear willingness-to-pay in a market big enough to sustain the build cost and generate profit?) and lovability (does the solution meet people where they already work, anticipate needs before users articulate them, and avoid the trap of obnoxious AI over-intervention?). Surface-level usability is table stakes now. What replaces it as the usability bar is whether the product fits into existing behavior rather than demanding that users change for it.

When to stop discovering and start building

This is the judgment call interviewers probe most directly at the senior level. The signal a candidate is ready: they name the specific assumption that, once tested, would give them enough confidence to commit. Not “when we have enough data,” which is indefinite, but “when we have evidence that users will pay to solve this problem and that our proposed mechanism fits how they already work.”

Discovery does not end at build. It compresses. Weekly interviews continue through delivery, now focused on whether the solution being built is actually landing on the opportunity it targeted.

Strong and weak interview answers

strong

"Product discovery is the continuous practice of identifying which customer problems are worth solving before committing to a solution. I run it as an ongoing loop, not a phase, following Teresa Torres's continuous discovery model: weekly story-based interviews with real users anchored in past behavior, not hypotheticals. I map what I'm learning into an opportunity solution tree: the desired outcome (the business metric the team owns) at the root, the opportunity space as branches, candidate solutions beneath those, and assumption tests at the leaves. The test I apply to each opportunity before moving toward a solution is whether it clears all four of Cagan's risks: do customers actually want it, can they use it without friction, is it buildable, and does it produce a business outcome we can sustain? In 2026, feasibility is rarely the blocker. AI can build nearly anything quickly, so I spend most discovery energy on viability and lovability: proving willingness-to-pay exists, sizing the addressable problem, and testing whether the solution fits into how people already work rather than asking them to change their behavior for us."

weak

"We do discovery at the start of a new feature. We run user interviews, look at analytics, and hand off requirements to design." This fails on three counts interviewers notice: it frames discovery as a handoff rather than a continuous loop, which shows the candidate has not internalized the Torres model; it positions the PM as a researcher who collects and passes work on rather than an owner who makes bets; and it does not connect discovery to a business outcome, which means the candidate cannot explain when discovery should stop and delivery should start. The other common failure: conflating customer discovery (Blank) with continuous discovery (Torres). These are different practices, and senior interviewers catch the conflation immediately.

Connection to adjacent frameworks

The OST and Jobs to Be Done are complementary, not competing. JTBD gives you the vocabulary for the opportunity layer: each opportunity maps to a job a customer is trying to get done, or a pain that prevents them from completing it. The OST gives you the structure that keeps opportunities and solutions from collapsing into each other before you have confirmed the right problem to bet on.

The practical judgment on when discovery is “done enough” to build maps directly to MVP decisions: you have a minimum viable discovery signal when you can state the riskiest assumption your solution rests on and point to evidence that the assumption holds. That is the moment the OST’s assumption tests graduate to a delivery commitment.

For more on what the 2026 feasibility shift means for where PMs spend discovery time, see feasibility is free and lovable, not just usable.