How do you run a product discovery process that actually works?

Product discovery is the work you do before writing a line of production code—figuring out which problem is real, who has it badly enough to change behavior, and what solution they'll actually use. Done well, it compresses months of wasted engineering into days of cheap learning. Done poorly, it's theater: surveys that confirm what you already believe and interviews that feel productive but produce no decisions.

Start with a single user, not a market

The instinct at the start of discovery is to cast wide—run a survey, post in forums, collect a hundred data points, then look for patterns. This almost always produces mush. A cleaner approach is to find one person who has the problem acutely and treat them as if you are building the product exclusively for them. Paul Graham's argument in 'Do Things That Don't Scale' is that this kind of extreme focus on a single user acts as a mold: once you fit their needs precisely, you've usually built something others in that situation also want. The signal from one real, deeply engaged user beats noise from fifty lukewarm respondents.

In practice this means identifying the person whose hair is on fire. Not someone who says 'yeah, I'd probably use that'—someone who is currently losing time, money, or sleep because the problem isn't solved. Your job in early discovery is to locate that person, not to average across a population. Once you have them, your discovery sessions stop being interviews and start being collaborative problem mapping: you're trying to understand the full shape of their situation, not just validate a hypothesis you already have.

A useful qualifier: the person should be both a sufferer of the problem and someone who can act on a solution. A user who feels the pain but can't make a purchase decision, switch tools, or change their workflow is less useful as an anchor than someone who has both the pain and the authority to respond to a fix. Finding that intersection is often harder than it sounds, and it's worth spending real time on it before you build anything.

Structure your discovery conversations to produce decisions, not feelings

Most founder interviews end with a feeling—'they seemed excited,' 'they really got it'—rather than a decision. The reason is that the questions were too hypothetical. Asking 'would you use a tool that did X?' is nearly useless because people are bad at predicting their own behavior and tend to be polite. Asking 'how did you handle this situation last Tuesday?' is far more useful because it's grounded in what actually happened.

The structure that works: open with their context (role, workflow, tools they currently use), then ask them to walk you through a recent specific instance of the problem, then probe why they handled it the way they did rather than some other way, then ask what they tried before and why those alternatives fell short. Notice you haven't mentioned your product idea yet. The goal at this stage is to build a complete picture of the problem from their perspective, including the workarounds they've already accepted. Workarounds are gold: they prove the problem is real and they show you how much friction someone is willing to tolerate, which tells you a lot about willingness to pay and switch.

After you've heard the problem story fully, you can test your solution framing—but test it as a concept ('if something handled X for you automatically, where would that land in your priority list?') rather than as a pitch. Listen for hesitation, caveats, and conditions. A user who says 'yes, but only if it also did Y' is giving you a product requirement, not just encouragement. Document these conditions carefully; they're where most discovery insights hide.

Use deep curiosity as a method, not just a disposition

The best product discoverers share a particular cognitive habit: they refuse to accept the first answer. Paul Graham's observation about how curiosity narrows and deepens in ambitious adults—shifting from broad, shallow questioning to obsessive focus on specific mysteries—describes exactly the mental posture that produces discovery breakthroughs. When a user says 'we just export it to a spreadsheet,' a shallow response is to note 'spreadsheet workaround.' A deeper one is to ask why they don't use the built-in report, who in the organization owns that spreadsheet, how often it breaks, and what decisions get made from it. That line of questioning often reveals that the real problem isn't what the user first described.

Practically, build a habit of asking 'why' or 'what happens then?' at least three levels deep on anything that surprises you or that the user mentions as routine. Routines are especially worth interrogating—people normalize painful workflows so thoroughly that they stop seeing them as problems. Your job is to un-normalize those routines and identify whether they represent real opportunity. If you feel like you're annoying your interviewee by asking too many follow-ups, you're probably close to something interesting.

After each interview, force yourself to write down the one thing that surprised you most. Not a summary of the conversation—just the single most unexpected thing. Over five or ten conversations, the pattern of surprises is often more diagnostic than any individual insight. If you're not being surprised, you're probably not going deep enough, or you're talking to users whose problem isn't actually acute.

Move from discovery to definition without premature closure

Discovery should end with a crisp problem statement, a candidate user archetype, and a hypothesis about the minimum useful version of a solution. What it should not produce is a full feature list or a roadmap—those are artifacts of premature closure, where you've stopped learning and started deciding before you have enough signal. The transition from discovery to definition is one of the places founders most commonly go wrong, usually because they get impatient or because they fall in love with a particular solution.

A useful forcing function: before you stop discovery, write down the three things that would change your mind about the direction you're heading. What evidence would convince you the problem isn't real enough, the user isn't accessible enough, or the solution approach is wrong? If you can't articulate those falsifying conditions, you haven't been doing discovery—you've been collecting confirmation. Post those conditions somewhere visible and check them against what you're actually learning.

Once you're ready to define, the output should be a problem brief: a one-page document that describes the target user in specific behavioral terms (not demographics), the specific situation in which the problem occurs, what they currently do about it, why that falls short, and what a successful outcome looks like from their perspective. This brief becomes the north star for your first prototype or MVP, and it's what you return to when feature debates break out later. Teams that skip this document spend disproportionate time relitigating decisions that should have been settled in discovery.

Validate with behavior, not opinion

Once you have a prototype or even a mockup, the final stage of discovery is behavioral validation—finding out whether people will actually do something, not just say they would. The clearest signal is money: someone willing to pre-pay or sign a letter of intent is expressing a credible preference in a way that a thumbs-up in an interview is not. But even below money, there are behavioral proxies that are more meaningful than stated enthusiasm: Will they give you two hours to test a prototype with their real workflow? Will they introduce you to their colleague who also has this problem? Will they send you the actual spreadsheet they use to do this manually? Each of these asks something of them, which means their willingness tells you something real.

For B2B products specifically, the consultant framing Paul Graham describes in 'Do Things That Don't Scale'—where you treat the first user as if you are their dedicated product team—is one of the best discovery validation tools available. When you are deeply embedded in solving their specific version of the problem, you learn things no survey or interview would surface. You see the edge cases they didn't think to mention. You understand the internal politics that shape how any new tool gets adopted. And you build the kind of trust that turns a beta user into a champion who sells your product internally on your behalf.

Discovery is not a phase you complete and then leave behind. The best founders maintain a continuous discovery loop—regularly spending time with users, paying attention to how usage patterns diverge from expectations, and treating each surprise as a new research question. The cadence shifts as you scale, but the habit of staying close to users is one that compounds in value over time.

“Keep tweaking till you fit their needs perfectly, and you'll usually find you've made something other users want too.”

— Paul Graham, source

The one thing to do

Find one person with the problem acutely, embed yourself in their actual workflow before building anything, and measure your discovery by how often you're surprised—not by how often you're validated.

Frequently asked questions

How many user interviews do you need before you have enough signal?

There's no universal number, but most teams reach saturation—where new conversations stop producing new surprises—somewhere between 8 and 15 interviews with users who share the same problem context. If you're still hearing radically different things at interview 15, you're probably talking to too broad a population and need to narrow your target user definition.

What's the difference between product discovery and market research?

Market research typically describes a population—size, demographics, spending patterns. Product discovery is about understanding the specific mechanics of a problem: when it occurs, why existing solutions fall short, and what behavior change a solution would need to produce. You need both, but discovery is what drives product decisions; market research is what contextualizes them.

When should you stop discovery and start building?

Stop when you have a problem statement you're confident in, at least one user who has committed to testing whatever you build, and a clear falsifiable hypothesis about what the solution needs to do. Don't wait for certainty—discovery de-risks building, it doesn't eliminate the need to build.

How do you avoid confirmation bias in user interviews?

Ask about past behavior rather than future intent, bring a second person to take notes so you can focus on listening, and write down your surprises after each session rather than your confirmations. Also deliberately seek out users who you expect to disagree with your hypothesis—their objections are often more valuable than enthusiasts' encouragement.

Sources

More playbook answers · Growth Prophet home