How to run discovery
Most products fail not because they were built badly but because they were built for a problem that wasn’t painful enough, frequent enough or specific enough to justify a solution. Discovery is how you find that out before you’ve spent six months and significant money building the wrong thing. Beleive me, I’ve done this plenty of times because let’s be honest, building is fun.
And now that we have AI tools that accelerate the build process, we’re seeing a slew of products being built that nobody wants.
So before a single wireframe, line of code or pricing page, you need answers to three questions:
- Does this problem actually exist in the way I think it does?
- Is it painful and frequent enough that people would pay to solve it?
- Am I the right solution, or are they already solving it well enough with something else?
Everything else is secondary. You are not validating your solution at this stage. You are validating the problem. This distinction matters enormously and most founders get it backwards.
Find ten to fifteen people who fit your assumed target profile. Not friends. Not people who will be polite. People who plausibly have the problem you think exists.
For me, LinkedIn is the best place to start. Reach out to second to third connections and be up-front about the problem you’re trying to validate and ask them if they could spare 45 minutes to discuss the problem space, not the product. That framing gets more honest responses.
Offer nothing in return except your time and attention. Most people understand that what comes around goes around and those willing to help are expanding their own network.
During the interview, craft your questions carefully because this is where most founders fail.
They go into interviews to confirm what they already believe. The questions they ask are structured, consciously or not, to produce agreement.
The result is false validation.
Leading questions corrupt data. Here’s what that looks like in practice:
“Would you find it useful if you could automate that process?” — Leading. You’ve suggested the solution and framed it positively.
“How frustrated do you get when that happens?” — Leading. You’ve pre-loaded an emotional response.
“Do you think that’s a big problem?” — Leading. You’ve suggested the answer is yes.
The fix is to ask about behaviour and experience, not hypotheticals and opinions.
Use these structures instead:
“Tell me about the last time you had to deal with [problem space].” — Opens a real memory, not a hypothetical. People describe what actually happened, not what they imagine they’d do.
“Walk me through exactly how you handled it.” — Forces specificity. Vague answers hide weak problems. Specific answers reveal real friction.
“What did you do when that happened?” — Behaviour over opinion. What someone did is more reliable data than what they say they’d do.
“How often does that come up?” — Frequency is a proxy for pain. A problem that happens twice a year is a different business than one that happens daily.
“What have you already tried?” — This is the most underrated question in discovery. Existing workarounds reveal how motivated people are to solve the problem. A sophisticated workaround means real pain. No workaround often means it’s not that important.
Silence is a technique that is hard to master but is so crucial.
After they answer, wait. Count three seconds before speaking. Most interviewers jump in too fast. The most revealing answers often come after the first response, when the interviewee keeps going to fill silence.
Never pitch, even accidentally. The moment you say “well what we’re building is…” the interview is over as a research instrument. They will start responding to your idea rather than describing their reality.
What you’re listening for
Strong signal:
Specific, unprompted stories about the problem
Evidence of existing workarounds, however crude
Emotional language that emerges naturally, not in response to your framing
Frequency: this comes up weekly, daily, every time we do X
Weak signal:
“Yeah that could be useful”
“I’d probably use something like that”
Enthusiasm about your idea rather than recognition of the problem
Vague agreement without specific examples
The difference between “that sounds interesting” and “we’ve been trying to solve that for two years and nothing works” is the difference between a feature and a business.
After each interview, write down three things immediately:
- The specific problem they described in their words, not yours
- What they’re currently doing about it
- Your confidence level that this person would pay to solve it
After ten interviews, look across your notes. You’re not doing statistical analysis. You’re looking for patterns: the same friction described independently by multiple people in similar language. That convergence is your signal.
If you can’t find it after fifteen conversations, the problem isn’t validated. That’s not failure. That’s the system working. You just saved yourself six months.
End each interview with: “Is there anything about this problem I haven’t asked about that you think I should understand?”
It catches what your questions missed. It often produces the most useful thing said in the entire conversation.