What product discovery actually is (and isn't)
Product discovery is the set of activities a team runs to decide what to build before committing engineering time to building it. It has two jobs: reduce the risk that the problem isn't worth solving, and reduce the risk that your proposed solution doesn't solve it. Everything else — the interviews, the prototypes, the trees, the workshops — is in service of those two questions.
It is not a phase that happens once before a project starts. Teams that treat discovery as a two-week kickoff activity, then move into 'build mode' for the next six months, are doing discovery theatre: they get the reassurance of having talked to customers without the ongoing evidence needed to make the next fifty decisions correctly. Continuous discovery, the term popularised by Teresa Torres, means a weekly touchpoint with customers that never stops, run in parallel with delivery rather than sequenced before it.
It is also not usability testing, though usability testing can be part of it. Usability testing asks 'can people use what we built'. Discovery asks the earlier and harder question: 'should we have built this at all'. Confusing the two is why teams end up with a beautifully polished feature nobody needed.
Continuous discovery vs project discovery: the practical difference
Project discovery is what most startups actually do: a burst of customer interviews and a competitor scan before a big build, condensed into a slide deck, then forgotten. It has a place — you genuinely need a concentrated push before a major bet like a pivot or a new product line — but it produces a single snapshot that ages fast. Six months after the deck, the market, the customers and often the team have moved on, and nobody goes back to check.
Continuous discovery is a standing weekly habit: a product trio (typically founder or PM, a designer, and an engineer) speaks to at least one customer every week, generates at least one small test of an assumption, and feeds what they learn straight into the opportunity map. The unit of output isn't a report, it's a decision — this week we learned X, so we're deprioritising Y and testing Z.
The practical difference shows up in speed of correction. A team running continuous discovery notices a wrong assumption within a week or two and changes course cheaply. A team relying on project discovery finds out three months into a build that the core assumption was wrong, after the code is written and the runway is spent. For a seed-stage company with 12-18 months of cash, that lag is the difference between a pivot and a failure to raise the next round.
Opportunity solution trees: the tool that stops solution-first thinking
- —Start with the outcome, not the feature. Write the single metric you're trying to move — activation rate, weekly retention, revenue per account — at the top of the tree. If you can't name the outcome, you're not ready to discuss solutions yet.
- —Map opportunities as customer problems, needs or pains, in the customer's language, gathered from actual interviews — not brainstormed internally. 'Users forget to log their trip' is an opportunity; 'add push notifications' is a solution wearing an opportunity's clothes.
- —Only attach a solution to a specific opportunity branch. If a proposed feature doesn't map to a named customer problem on the tree, it doesn't belong on the roadmap yet, no matter how loudly an investor or a competitor is asking for it.
- —Prune ruthlessly. A tree with forty opportunity branches is not more rigorous than one with six — it's a sign nobody has prioritised. Pick the two or three opportunities with the strongest evidence and go deep, not wide.
- —Revisit weekly, not quarterly. The tree is a living document updated after every interview round; a static tree reviewed once a quarter has already reverted to being a project-discovery artefact with extra branches.
Interview technique that actually produces evidence
The single biggest technique failure I see is asking customers what they want. Customers are unreliable narrators of their own future behaviour — they'll tell you they'd pay for a feature and then never open the app when you ship it. The fix is to ask about specific past behaviour instead: 'tell me about the last time you tried to solve this problem' produces a concrete story you can mine for evidence. 'Would you use a feature that did X' produces a polite hallucination.
Structure each interview around a recent, specific instance rather than general opinions. Get the timeline: what triggered the problem, what they tried, what happened, how they felt about the outcome. This is the interview snapshot technique — you're reconstructing a real event, not surveying an opinion.
Take notes as inferences, not quotes, and tag them against the opportunity tree in real time or immediately after. An inference is 'this customer avoids switching tools because onboarding took two days last time' — specific, falsifiable, attributable. A vague note like 'customer likes simplicity' is not evidence, it's a feeling, and feelings don't belong on a roadmap.
How many interviews are enough?
For a single, narrow question — does this specific workflow confuse people — five to eight interviews will usually surface the dominant patterns; qualitative research consistently shows diminishing returns after around the eighth conversation for a tightly scoped question. This is the number I use for a two-week discovery sprint: 6-10 conversations, enough to see a pattern repeat at least three times before acting on it.
For continuous discovery, the right frame isn't a target number, it's a minimum cadence: at least one interview a week, every week, indefinitely. Over a quarter that's roughly 12-15 conversations, spread across different customer segments, which gives you far more reliable signal than a single burst of 15 interviews crammed into one week, because you're testing evolving assumptions against a moving product rather than a single static snapshot.
The failure mode in both directions is treating the number as the goal. Three interviews that each surface the same specific, painful, recurring problem is stronger evidence than twenty interviews of polite generalities. Depth and repetition of a specific pattern matter more than raw volume.
Discovery for AI features: a different set of assumptions to test
AI features fail discovery in a specific way: they demo brilliantly on a curated example and fall apart on a real customer's messy input. The assumption you need to test isn't 'do customers like the idea of AI doing this' — they almost always say yes — it's 'does the model perform acceptably on the actual variance of real inputs, and do customers trust the output enough to act on it without checking it manually'.
Practically, that means discovery for an AI feature needs a step most teams skip: running the prototype against a sample of real, unfiltered customer data before committing to the build, not a hand-picked demo dataset. If accuracy or hallucination rate on real inputs is unacceptable, no amount of enthusiastic interview feedback about the concept should move it up the roadmap.
The second AI-specific assumption to test is trust and verification cost: does the customer actually save time using the AI output, once you account for the time they spend checking it? A feature that's 90% accurate but requires the customer to double-check every output may produce net negative time savings, and that only shows up if you test with a realistic task, not a scripted one.
Common discovery anti-patterns, and how to spot them in your own team
- —The advisory board fallacy: treating five enthusiastic conversations with your own investors or advisors as customer validation. They are not your customer, however smart they are.
- —Feature-request theatre: running interviews but only asking existing power users, who already like your product and will happily request more of what already works, rather than talking to churned users or people who rejected you.
- —The solution-first workshop: gathering the team in a room to brainstorm features, then retroactively looking for interview quotes that support the favourite idea, instead of letting the opportunity tree generate the solution.
- —One-and-done discovery: running a sprint before a big build, then not touching customer interviews again until the next big bet six months later, by which point the market has moved.
- —Confusing enthusiasm with commitment: a customer saying 'I'd love that' in an interview is not the same as them changing behaviour, paying money, or switching tools — always look for a costly signal, not a polite one.