How do you do customer discovery?

Pick one narrow customer segment, list the assumptions that would sink the idea, then interview people who recently had the problem. In each interview, anchor on a specific past event, reconstruct the workflow, establish frequency and consequences, and dig into existing workarounds and what they already spend. Compare patterns across interviews before deciding whether to continue, narrow, pivot, or stop. The goal is evidence of past behaviour — not whether someone likes your idea.

What are good customer discovery interview questions?

The strongest questions ask about the past, not the future: 'Tell me about the last time this happened', 'Walk me through exactly what you did', 'How do you deal with it today?', and 'What have you already spent trying to solve this?'. Avoid hypotheticals like 'Would you use this?' or 'Would you pay $20/month?' — they produce polite yeses that feel like validation but predict nothing.

How many customer discovery interviews are enough?

There's no magic number, and this is a genuine limitation — it depends on your segment and how consistent the answers are. A practical rule: keep going until new interviews stop surprising you and you're hearing the same workflow, consequences, and workarounds repeatedly across distinct people. If every interview tells a different story, your segment is probably too broad; narrow it and continue.

Why do positive interviews still lead to products nobody buys?

Because interest, praise, and even signups are not the same as demand. People are agreeable, especially face to face, and hypothetical enthusiasm costs them nothing. In the founder discussions we analysed, a recurring pattern is building for months on assumptions and launching to silence, or getting 'customers' through relationships who never actually use the product. Weighting past behaviour and money already spent over stated enthusiasm is how you avoid it.

Founder guide · Evidence, not opinions

How to Do Customer Discovery Without Getting False Validation

By Problem Signal Research · Reviewed July 15, 2026

What customer discovery is

Customer discovery is the work of talking to real people to find out whether a problem is real, frequent, and painful enough that they already spend time or money trying to solve it. It is trying to establish one thing: evidence of specific past behaviour — not whether someone likes your idea. Asking “would you use this?” is insufficient because people are optimistic and polite; a hypothetical yes costs them nothing and predicts nothing. Good customer discovery uncovers repeated problems, existing workarounds, real consequences, and evidence of commitment. This guide gives you a step-by-step process, the interview questions to use, and what recurring founder mistakes in real discussions can teach you.

What founders actually struggle with

Problem Signal continuously analyses public founder and small-business discussions. Across 8,384 discussions (and 37,899 extracted pain statements), the second-largest cluster of problems — 1,337 pain statements — is about uncertain market fit and validation. These are the patterns that recur most. (A pain statement is not a person: we report distinct discussions, distinct people, and pain statements as three separate numbers, and public complaints are research signals, not proof anyone will buy.)

1. Building on assumptions instead of talking to people first

286 distinct discussions · 256 distinct people · 513 pain statements

The most common demand pattern in the corpus is founders who built for months on their own reasoning and then launched to silence. One recurring, carefully paraphrased sentiment: an entire year spent building on assumptions that, in the founder's own words, “lived only in my head” — followed by a launch with a handful of signups and no paying users.

Lesson: the reasons an idea feels right are not evidence. Discovery replaces the argument in your head with observed behaviour from people who are not you.

2. False validation: praise and signups without payment

A distinct pattern within the same cluster: encouraging feedback, or even early “customers”, that never convert into use. Founders describe getting their first customers through relationships — people who, as one paraphrased account put it, “aren't real customers, so they never really utilise or install the product”.

Lesson:separate interest from demand. A friendly yes, a signup, and a favour from your network are not purchases. Weight what people have already done over what they say they'll do.

3. Not knowing whether to continue, pivot, or stop

39 distinct discussions · 34 distinct people

A recurring ask is how to decide whether an idea is worth building — founders describe being “paralyzed” and unsure whether something is “good enough to show real users”. The struggle is making a decision on evidence rather than on anxiety or sunk cost.

Lesson:set your evidence bar before you start interviewing, then judge the interviews against it — not against how attached you've become.

4. Confusing interest with willingness to pay

38 distinct discussions · 33 distinct people

Founders repeatedly get stuck articulating why anyone should pay — one paraphrased account describes being stuck “putting into words why people should pay me in a way that makes people want to pay me”. The gap between “this is useful” and “here is my money” is where a lot of ideas quietly die.

Lesson: in interviews, chase what people already spend (time, money, tools, headcount) on the problem. Existing spend is the most honest willingness-to-pay signal you can get without a checkout page.

A limit worth stating: this corpus documents the consequences of weak discovery — building the wrong thing, false validation, and not being able to tell interest from demand. It does not contain granular, technique-level debate about, say, phrasing a non-leading question. So the interview craft below is established best practice, presented as guidance — not a claim mined from the data.

The customer-discovery process

Eleven steps, from picking who to talk to through deciding what the interviews mean. Each includes what to do, why it matters, an example, and — where the data supports one — a common mistake founders actually make.

Step 1. Define one narrow customer segment
What to do:
Pick a single, specific type of person — not 'small businesses' but 'solo bookkeepers with 5–15 monthly clients'.
Why it matters:
A narrow segment gives consistent answers you can compare. A broad one gives noise.
Example:
'Freelance web designers juggling 3+ concurrent clients', not 'freelancers'.
Common mistake:
In the discussions we analysed, a recurring failure is targeting a persona that turned out to be wrong — one seller spent months optimising for the wrong audience before the real buyers showed up in the sales data.
Step 2. List the assumptions that could invalidate the idea
What to do:
Write down the beliefs that, if false, kill the idea: that the problem is frequent, painful, and that this segment feels it.
Why it matters:
Discovery is a test of your riskiest assumptions, not a search for applause.
Example:
'I assume designers lose real time consolidating feedback from 3+ channels every week.'
Common mistake:
Building for a year on assumptions that 'lived only in my head' is the single most common story in the corpus — reasons that feel logical are not evidence.
Step 3. Recruit people who recently had the problem
What to do:
Find people who hit the problem in the last few weeks — go where they already talk about it.
Why it matters:
Recent memory is accurate; recruiting the wrong people wastes every later step.
Example:
Reach out in the communities and threads where people describe the exact problem, and ask for 20 minutes.
Common mistake:
Founders repeatedly report cold outreach going nowhere — 'after two weeks I literally got zero replies'. Recruiting is itself a signal: if you can't find anyone who has the problem, that's data.
Step 4. Ask about a specific past event
What to do:
Anchor every interview to 'the last time this happened' before anything else.
Why it matters:
A concrete event can't be answered with a hopeful hypothetical.
Example:
'Tell me about the last time a client's revisions got lost between email and Slack.'
Common mistake:
Asking 'would you use X?' invites a polite yes that feels like validation and predicts nothing.
Step 5. Reconstruct the workflow step by step
What to do:
Have them walk you through exactly what they did, tool by tool, hand-off by hand-off.
Why it matters:
The real friction is usually not where you assumed it was.
Example:
'So you copied the comment from Slack into a spreadsheet, then re-typed it into the project tool?'
Common mistake:
Accepting a summary ('it's just annoying') instead of the actual steps hides where a product could win.
Step 6. Identify severity, frequency and consequences
What to do:
Establish how often it happens and what it costs when it goes wrong.
Why it matters:
Frequency × severity is what makes a problem worth paying to remove.
Example:
'This happens every week, and last month a missed revision cost us a client.'
Common mistake:
Treating a rare, low-stakes annoyance as if it were a business-critical problem.
Step 7. Investigate existing workarounds
What to do:
Ask how they cope today — the spreadsheet, the script, the manual routine.
Why it matters:
A workaround already built is the strongest proof the pain is real and worth effort.
Example:
'I keep a master Google Sheet and paste every comment in by hand.'
Common mistake:
Missing the workaround means missing both the proof of pain and the shape of the product they'd accept.
Step 8. Look for time, money or effort already spent
What to do:
Find out what they've already paid — in tools, subscriptions, hours, or hiring.
Why it matters:
Past spend is real, committed evidence of a budget and a felt need.
Example:
'We pay a VA two hours a week just to reconcile this.'
Common mistake:
Substituting 'would you pay $X?' for 'what have you already spent?' — the first is fiction, the second is fact.
Step 9. Identify the buyer and other stakeholders
What to do:
Work out who actually decides and pays — it may not be the person you're talking to.
Why it matters:
In B2B especially, the user and the budget owner are often different people.
Example:
'I'd use it, but my ops manager would have to approve the spend.'
Common mistake:
Assuming the enthusiastic user can buy — a recurring frustration is first 'customers' who came through relationships and never really adopted the product.
Step 10. Compare patterns across interviews
What to do:
After several interviews, look for the workflow, consequences and workarounds that repeat across distinct people.
Why it matters:
One vivid story is an anecdote; the same pattern from many people is a signal.
Example:
'Six of eight designers keep a manual feedback sheet' is far stronger than one great quote.
Common mistake:
Over-weighting the single most enthusiastic interview instead of the repeated pattern.
Step 11. Decide: continue, narrow, pivot, or stop
What to do:
Set your evidence bar in advance, then judge the interviews against it — not against how attached you've become.
Why it matters:
A decision made on pre-set thresholds beats one made on sunk cost or fear.
Example:
'If fewer than half describe a weekly, costly version of this, I narrow the segment or stop.'
Common mistake:
Founders describe being 'paralyzed', unsure whether something is 'good enough to show real users' — deciding on anxiety rather than the evidence in front of them is its own failure mode.

Customer discovery interview questions

A focused set of customer discovery interview questions, grouped by purpose. For each one, the signal it's meant to reveal matters more than the wording — adapt the phrasing to how your customers actually talk. Prioritise depth over covering all of them; 20–30 minutes is enough for the groups that matter to your idea.

Context

Confirm the person is actually in your segment before you trust anything they say.

“Walk me through your role and what a typical week looks like.”
Signal: Confirms whether they belong to the segment you're targeting — off-segment answers should be weighted down, not thrown into the same pile.
“Where does [the problem area] sit in your week — is it a daily thing or an occasional one?”
Signal: Establishes whether the problem is even on their radar before you name it.

Last occurrence

Anchor to a real, specific event instead of a hypothetical.

“Tell me about the last time this happened.”
Signal: Confirms the person has actually experienced the problem and moves the conversation off opinions and onto memory.
“When exactly was that? What were you doing right before?”
Signal: A real event has a date and a lead-up; a vague 'oh, all the time' with no example is a warning sign the pain is imagined.

Workflow

Reconstruct the actual steps, tools and hand-offs.

“Walk me through exactly what you did, step by step.”
Signal: Surfaces where the real friction is — often not where the founder assumed.
“Which tools, spreadsheets or people were involved at each step?”
Signal: Reveals the true 'competitor' — usually a spreadsheet, a manual process, or nothing.
“Where did it slow down or go wrong?”
Signal: Pinpoints the specific step worth solving rather than the whole workflow.

Frequency

Separate a one-off annoyance from a recurring cost.

“How often does this come up — per day, week, or month?”
Signal: Frequency × severity is what makes a problem worth paying to remove; a painful once-a-year event rarely sells.
“Is it getting more or less frequent?”
Signal: A growing problem is a better bet than a shrinking one.

Severity & consequences

Find out what the problem actually costs them.

“What happens if it doesn't get handled?”
Signal: Distinguishes a real consequence (lost money, lost customer, missed deadline) from a mild irritation.
“The last time it went wrong, what did it cost you — time, money, or something else?”
Signal: Quantifies the pain in the person's own terms; a consequence they can name is far stronger than 'it's annoying'.

Existing workarounds

See what they already do to cope — the strongest signal of real pain.

“How do you deal with it today?”
Signal: A workaround that already exists proves the problem is worth effort — people don't build hacks for problems they don't have.
“What have you cobbled together — a spreadsheet, a script, a manual routine?”
Signal: The shape of the workaround tells you the shape of the product they'd actually accept.

Time & money already spent

Look for commitment that's already happened, not intent.

“What have you already spent trying to solve this — tools, subscriptions, hours, or hiring someone?”
Signal: Past spend is evidence of a budget and a felt need; it beats any answer to 'would you pay?'.
“Who signed off on that spend?”
Signal: Identifies whether there's a budget owner — critical in B2B.

Existing products tried

Understand the alternatives and why they fell short.

“What have you tried before, and why did you stop using it?”
Signal: Tells you the real bar to clear and the specific reasons alternatives failed.
“What would have to be true for you to switch off your current approach?”
Signal: Surfaces switching barriers and the minimum viable improvement.

Stakeholders & purchasing

Find out who actually decides and pays.

“If you wanted to bring in a tool for this, who else would need to be involved?”
Signal: Separates the user from the buyer and the blockers — the person in front of you may not control the money.
“How do purchases like this normally get approved where you work?”
Signal: Reveals the real sales cycle and the gatekeepers.

Switching barriers

Understand what keeps them stuck.

“What's stopped you from fixing this already?”
Signal: Exposes the real obstacles — cost, risk, habit, integration — that your product has to overcome.

Closing & referrals

Turn one conversation into evidence and more conversations.

“Is there anything about this I should have asked but didn't?”
Signal: Opens the door to the thing you didn't know to ask about.
“Who else do you know who deals with this that I should talk to?”
Signal: A genuine referral is a small commitment and a sign the problem resonated; refusal is itself a (softer) signal.
“Would it be OK to follow up if I build something to test?”
Signal: A yes here is a low-cost early commitment you can later convert into a pilot or pre-order.

Questions founders should avoid

The most dangerous questions are the ones that feel like they're working — they generate agreement and enthusiasm that reads as validation. Expand each pair to see the better version and why the weak one produces unreliable answers.

Weak“Would you use a product that solves this?”

Better“How did you handle this the last time it happened?”

The first asks for a prediction about a hypothetical future — people are optimistic and polite, so almost everyone says yes. The second asks for a memory, which is far harder to fake and tells you what they actually do.

Weak“Would you pay $20 per month for this?”

Better“What have you already spent trying to solve this?”

A hypothetical price gets a hypothetical yes. Past spend is real, already-committed money — the single most reliable willingness-to-pay signal you can get in an interview.

Weak“Do you think this is a good idea?”

Better“Which part of your current workflow causes the most difficulty?”

Asking someone to rate your idea invites flattery and makes them the judge of your solution. Asking about their workflow keeps them describing their world, where the truth lives.

Weak“Don't you hate it when [problem]?”

Better“Tell me about the last time [problem area] came up for you.”

A leading question hands the person the answer you want; they'll agree to be agreeable. A neutral, open prompt lets them tell you whether it even happened.

How to interpret interview answers

Not all answers weigh the same. Use this evidence ladder — one positive comment near the top is weaker than repeated behaviour lower down, observed across several distinct people.

1General complaint. 'That's always annoying.' Interest at best — no proof it's theirs.
2Specific recent example. A dated event they can walk you through. Now it's real.
3Repeated problem. It happens on a rhythm — daily, weekly, every close.
4Meaningful consequence. It costs them money, a customer, or a deadline when it goes wrong.
5Existing workaround. They've already built a hack to cope — effort already spent.
6Time or money spent. They pay for a tool, an hour, or a person to deal with it.
7Active search for a solution. They're currently looking, or have looked, for something better.
8Commitment. An intro, a pilot, a pre-order, a letter of intent, or payment.

It helps to keep five words distinct:

Interest — they find the topic worth discussing.
Pain — the problem actually costs them something.
Demand — the pain recurs across many people, not just one.
Purchase intent — they show signs of being willing to pay (past spend, active search).
Commitment — they do something costly now: an intro, a pilot, a pre-order, payment.

Enthusiasm lives at the “interest” end. The decisions that de-risk a business live at the “commitment” end.

A copy-ready interview script

A 20–30 minute script you can run today. Copy it, replace [problem area] with yours, and keep the person in the past tense as much as you can.

Copy-ready interview script

CUSTOMER DISCOVERY INTERVIEW SCRIPT (20–30 minutes)

0. INTRODUCTION (2 min)
"Thanks for making the time. I'm trying to understand how people handle
[problem area] today — I'm not here to sell you anything, and there are no
right answers. I'd love to just hear about your actual experience."

1. PERMISSION & EXPECTATIONS (1 min)
"Is it OK if I take notes so I don't miss anything? This should take about 20–30
minutes. Feel free to tell me if a question doesn't apply to you."

2. CONTEXT (3 min)
- Walk me through your role and what a typical week looks like.
- Where does [problem area] sit in your week — daily, or occasional?

3. LAST EVENT (4 min)
- Tell me about the last time [problem] happened.
- When was that? What were you doing right before?

4. WORKFLOW (5 min)
- Walk me through exactly what you did, step by step.
- Which tools, spreadsheets, or people were involved?
- Where did it slow down or go wrong?

5. FREQUENCY & CONSEQUENCES (4 min)
- How often does this come up?
- What happens if it doesn't get handled?
- The last time it went wrong, what did it cost you — time, money, something else?

6. WORKAROUNDS & SPEND (5 min)
- How do you deal with it today?
- What have you already spent trying to solve this — tools, hours, hiring?
- What have you tried before and stopped using? Why?

7. STAKEHOLDERS (2 min)
- If you brought in a tool for this, who else would need to be involved?
- How do purchases like this normally get approved?

8. CLOSING (2 min)
- Is there anything I should have asked but didn't?
- Would it be OK to follow up if I build something to test?

9. REFERRAL (1 min)
- Who else do you know who deals with this that I should talk to?

AFTER THE CALL (do this within 10 minutes, while it's fresh):
- Score the interview against the scorecard.
- Note the strongest rung on the evidence ladder they reached.
- Capture one verbatim quote in their exact words.

No sign-up needed — copy it, swap in your problem area, and run it.

The customer-discovery scorecard

After each interview, tick what you genuinely heard. There are 9 items — it's a tally to keep you honest, not a scientific score. Nothing is sent anywhere and no account is needed.

Score an interview

0 / 9

The participant clearly belongs to your target segment.
They described a specific, recent, real event (not a hypothetical).
They walked through the workflow in concrete detail.
Frequency was established (how often it recurs).
A meaningful consequence was identified (time, money, risk).
A current workaround exists.
Time or money is already being spent on the problem.
The buyer / decision-maker is known (may not be the interviewee).
They offered a next step, an introduction, or agreed to a follow-up.

Weak — mostly interest, not evidence. Treat with caution.

A tally, not scientific validation — it just shows how much of what you heard was evidence of past behaviour versus polite interest.

What customer interviews cannot prove

Interviews give you depth from a small number of people. That is exactly what they can — and can't — do. Even a dozen great interviews do not, on their own, prove:

· Market size — a handful of interviews can't tell you how many people share the problem.
· Willingness to pay — what people say about price is not what they do at a checkout.
· Product adoption — wanting the outcome is not the same as changing their workflow to use your product.
· Retention — whether they'll still use it in three months.
· A viable acquisition channel — whether you can reach these people repeatably and affordably.

To test those, follow interviews with something that asks for real commitment:

· A prototype test with a real task
· A landing-page test measuring sign-ups against traffic
· A pre-order or paid waitlist
· A pilot with a small number of customers
· Paid discovery — charging for the manual version
· A concierge / manual service before you build software

How Problem Signal complements interviews

Interviews give you depth from a few people. Problem Signal gives you breadth: it helps you look for the same problems, workarounds, and requests across a large body of public discussions — useful before you interview (to find who and what to ask about) and after (to check whether what you heard shows up more widely). Those public discussions are research signals, not proof of purchase intent — the same caveat that applies to a friendly interview.

Startup Idea Validator — check whether similar problems are already appearing in real discussions before you invest in interviews.
AI Idea Reality Check — reality-check an idea from ChatGPT or Claude against real evidence, so your interviews start from a grounded hypothesis.
Problem Gap Finder — name a market and see the recurring unmet needs and workarounds inside it, to decide which segment to interview.
Find My Customers — find the communities where your customers already talk, so recruiting interviewees stops being cold outreach into the void.

Want the fuller picture on demand signals? See our idea-validation research report or browse free startup ideas backed by real discussions.

Customer discovery FAQ

How do you do customer discovery?: Pick one narrow customer segment, list the assumptions that would sink the idea, then interview people who recently had the problem. In each interview, anchor on a specific past event, reconstruct the workflow, establish frequency and consequences, and dig into existing workarounds and what they already spend. Compare patterns across interviews before deciding whether to continue, narrow, pivot, or stop. The goal is evidence of past behaviour — not whether someone likes your idea.
What are good customer discovery interview questions?: The strongest questions ask about the past, not the future: 'Tell me about the last time this happened', 'Walk me through exactly what you did', 'How do you deal with it today?', and 'What have you already spent trying to solve this?'. Avoid hypotheticals like 'Would you use this?' or 'Would you pay $20/month?' — they produce polite yeses that feel like validation but predict nothing.
How many customer discovery interviews are enough?: There's no magic number, and this is a genuine limitation — it depends on your segment and how consistent the answers are. A practical rule: keep going until new interviews stop surprising you and you're hearing the same workflow, consequences, and workarounds repeatedly across distinct people. If every interview tells a different story, your segment is probably too broad; narrow it and continue.
Why do positive interviews still lead to products nobody buys?: Because interest, praise, and even signups are not the same as demand. People are agreeable, especially face to face, and hypothetical enthusiasm costs them nothing. In the founder discussions we analysed, a recurring pattern is building for months on assumptions and launching to silence, or getting 'customers' through relationships who never actually use the product. Weighting past behaviour and money already spent over stated enthusiasm is how you avoid it.