glossary · discovery
Product discovery vs delivery
The ongoing work of reducing value, usability, feasibility, and viability risk before committing engineering to build.
Discovery is the work of proving you are building the right thing. Delivery is the work of building it right. The difference is not about timing, it is about the question each mode is answering.
Marty Cagan at SVPG named the four risks that discovery must reduce before a team commits engineering weeks to a solution: value risk (will anyone want this?), usability risk (can they use it without friction?), feasibility risk (can we build it?), and business viability risk (does it work for the company financially and legally?). Discovery is not a phase that ends before delivery starts. It is the parallel track that keeps delivery pointed at problems worth solving.
What PMs actually do in discovery
Teresa Torres, in Continuous Discovery Habits (2021), reframed discovery from a project kickoff ritual into a weekly habit: at minimum one touchpoint with a real customer per week, with findings mapped onto an Opportunity Solution Tree (OST). The OST has four layers: a desired outcome at the top, an opportunity space populated from customer evidence, candidate solutions, and assumption tests. The most common failure mode is an opportunity space that goes stale because the team stopped feeding it fresh customer evidence. The tree looks maintained but the leaves are dead.
JTBD framing disciplines the interview work. Instead of asking customers what they want, you ask what job they are hiring the product to do. This keeps interviews from becoming a feature-request queue. The customer says “I want a dashboard.” JTBD asks: what are you trying to accomplish that made you want a dashboard? The answer is the opportunity; the dashboard is one possible solution.
The Double Diamond maps cleanly onto the split: the first diamond (Discover, Define) is discovery work; the second (Develop, Deliver) is delivery. The mistake is reading those diamonds as sequential. Modern teams run both simultaneously. Delivery generates behavioral data that feeds right back into the opportunity space before the sprint is done.
The 2026 reframe
In 2026, feasibility is largely free. AI agents can produce working prototypes in hours. Cagan’s feasibility risk, the question of “can we build it,” has collapsed to near-zero for most product ideas. That concentrates discovery onto two questions: Is this a problem people and businesses will genuinely pay to solve (viability)? And does the solution meet users where they actually work, anticipate their needs, and make them feel understood rather than accommodated (lovability, the new high bar for usability)?
AI products add a specific discovery failure mode: teams confuse what the model can do with what users want. An LLM that summarizes fluently does not mean users want summaries, trust them, or will change their workflow to receive them. The discovery question for any AI feature is: what existing behavior are we augmenting, and would users notice if it disappeared?
Teresa Torres expanded her Vistaly partnership in 2026 to add AI-assisted interview synthesis. AI clusters notes and surfaces candidate opportunities; PMs validate the framing. The habit stays human, the overhead drops.
What distinguishes a strong interview answer
The weak answer lists methods: “I run user interviews, surveys, and usability tests.” That is methodological inventory. It tells the interviewer nothing about judgment, about when discovery is done, or about how findings connect to decisions.
strong
"Discovery is how I reduce the four risks before my team spends weeks building. In 2026 the feasibility risk is often near-zero since I can prototype almost anything in a day, so I concentrate on value and viability. I keep at least one customer touchpoint per week and map what I hear onto an Opportunity Solution Tree so the team sees the problem space, not just the solution I happen to prefer. I use JTBD framing in interviews to avoid feature-request traps. And discovery doesn't stop at ship: delivery data feeds straight back into the opportunity space. The failure mode I watch for is discovery theater: we ran ten interviews but the findings never changed a decision. If that's happening, something is broken in how we're connecting evidence to the roadmap."
weak
"Discovery is when you talk to users to understand their needs before building." Then a list of methods without explaining what question each answers or how findings feed a decision. No mention of risk, evidence cadence, or what bad discovery looks like. The interviewer cannot tell whether this candidate has judgment or just vocabulary.
Named failure modes
Discovery theater: Running interviews or surveys without connecting findings to any decision. The team feels like it is doing discovery; risk is not actually reduced.
Starving the OST: Maintaining an Opportunity Solution Tree without fresh customer evidence. The structure is there but the opportunity space reflects old assumptions.
Feature-request trap: Treating what users say they want as the opportunity, rather than the underlying job. Solved with JTBD framing.
Feasibility theater (2026): Using prototyping speed as a substitute for viability evidence. Building fast does not prove the market will pay.