Product discovery is the work of deciding what's worth building before you build it — talking to users, testing assumptions, and turning a vague request into a justified bet. It's the opposite of taking a feature request at face value and shipping it. This page covers the discovery process, the techniques that actually move things, the questions worth asking, and a simple template — then the part most guides skip: discovery produces a pile of evidence and assumptions, and the line from insight → decision → spec is exactly where it usually breaks.
Product discovery is how a team reduces the risk that they build the wrong thing. It runs in parallel with delivery — while engineers ship what's already decided, the team is investigating what should come next: is the problem real, do people want this, can we build it, should we. The output isn't a feature; it's a decision you can defend, with the evidence attached.
The classic frame is "dual-track": discovery and delivery as continuous, parallel streams, not phases. The risks discovery tackles are usually grouped as value (will they use it), usability (can they), feasibility (can we build it), and viability (should we, for the business). A good discovery process is just a disciplined way of retiring those risks before they cost a quarter of engineering.
Five techniques cover most real discovery. You don't run all of them every time — you pick the ones that retire your biggest current risk.
Talking to real users about their actual problems, not pitching your solution. The single highest-leverage technique — done continuously, not as a one-off study. The output is a clear-eyed view of the problem before any feature is on the table.
Teresa Torres's map from a desired outcome down through opportunities (unmet needs) to candidate solutions. Keeps you from jumping to a feature before you've understood the opportunity space — and makes the reasoning visible.
List what must be true for an idea to work, then sort by how risky and how unknown each assumption is. You test the riskiest, least-known ones first. Stops you validating the comfortable assumptions and ignoring the load-bearing one.
Low-fi prototypes, fake-door tests, concierge MVPs — the cheapest experiment that can disprove an assumption. The goal is a fast "no" before an expensive "yes", not a polished demo.
Funnels, cohort retention, support themes — the quantitative half that interviews can't give you. Best paired with qualitative work: the numbers tell you where to look, the interviews tell you why.
A lightweight discovery doc answers six things: the outcome you're chasing, the opportunity (the unmet need), the assumptions that must hold, the experiments run and what they showed, the decision reached, and the open questions left. That's the whole template — the value is in filling the decision and its evidence honestly.
The questions worth asking are the uncomfortable ones: What would have to be true for this to be a bad idea? Who is this NOT for? What's the cheapest way to be wrong fast? If we're right, what breaks downstream? Discovery that only confirms the plan isn't discovery.
Discovery's real output is a chain: an observation became an insight, the insight justified a decision, the decision shaped a spec. In most teams that chain lives in scattered docs and memory, so when an assumption is later disproven, nothing walks the chain forward to the spec built on it. Draftlize makes the chain explicit.
An interview observation, an experiment result, an assumption — each is a card. The decision that rests on them links back to the evidence, so "why did we decide this" has an answer that isn't "someone remembers a call from March."
A later test disproves an assumption discovery relied on. The decision that cited it — and the spec built on that decision — auto-flag stale. The evidence trail runs forward, not just backward, so a disproven assumption doesn't leave a live spec quietly resting on it.
When Claude Code or Cursor drafts the spec over MCP, it reads the actual decision and the findings behind it — so what gets built traces to the discovery that justified it, instead of a lossy hand-off through a doc nobody re-opens.
Discovery's output isn't a feature — it's a decision with evidence attached. Lose the attachment and you've kept the conclusion and thrown away the reason.Run discovery your way. Keep the chain from observation to spec intact.
Discovery decides what to build and why; delivery builds it. The modern practice is "dual-track" — they run continuously in parallel, not as sequential phases. Discovery retires the risk that you build the wrong thing; delivery executes once that risk is low enough.
Continuous customer interviews, opportunity solution trees, assumption mapping, cheap prototypes and experiments (fake-door, concierge), and quantitative data analysis. You pick the technique that retires your biggest current risk rather than running all of them every time.
The classic "product trio" — product manager, designer, and engineer — discovering together, so value, usability, and feasibility are weighed at once. Pulling the engineer in early is what stops discovery from proposing things that can't be built affordably.
The uncomfortable ones: what would make this a bad idea, who is it explicitly not for, what is the cheapest way to find out we are wrong, and what breaks downstream if we are right. Discovery that only confirms the existing plan is not really discovery.
Interview, prototype, and analyze however you like. Put the findings and decisions in Draftlize as linked cards, so when an assumption is disproven, every decision and spec that rested on it flags stale — and your agent always builds from the evidence, not a stale summary.
Start free with $5