In this article
Customer Discovery: How to Find Out What People Will Actually Pay For
By Hao Xu · Founder, WedgeScout · Published July 27, 2026 · Updated July 27, 2026
TL;DR — Customer discovery tests whether a problem exists before you build anything. The people you interview will lie to you politely. Ask about specific past behaviour, not future intentions. Plan on 15–30 interviews per persona and stop when new conversations stop surprising you. But interviews cannot test the last hypothesis: one founder bought 111,927 impressions for €174 and "Converted exactly zero people. ZERO." Problem, user and solution respond to conversation. Value responds to an invoice.
Customer discovery means testing whether the problem you want to solve actually exists — by talking to the people who supposedly have it, before you build anything. Every guide will tell you that much. What most guides skip is the uncomfortable part: the people you interview will lie to you. Not maliciously — politely. They'll say your idea is interesting, that they'd "definitely use it," and then never think about it again. This guide covers the standard process (hypotheses, interviews, journey mapping, templates) and then the part the standard process can't fix.
What is customer discovery?
Definition: Customer discovery is the first phase of building a product, in which founders form explicit hypotheses about a customer problem and test those hypotheses against real customer behavior — through interviews, observation, and evidence — before committing to a solution.
The term comes from Steve Blank, the serial-entrepreneur-turned-Stanford-educator whose book The Four Steps to the Epiphany argued that startups die not from bad engineering but from building things nobody wants. Blank's insight — "get out of the building" — became the foundation of the lean startup movement, and customer discovery is its step one: before product, before pitch deck, find out whether the pain is real.
Two words in the definition do the heavy lifting. Hypotheses — you are not "chatting with users," you are testing specific, falsifiable guesses. Behavior — what people do (and complain about, and pay for) counts; what they say they might do mostly doesn't. Keep both in view and the rest of the process makes sense.
What "behaviour" looks like when you collect it at scale: a scan of what small accounting firms complain about — the evidence report our own pipeline produced for that market.
The four hypotheses you're actually testing
Harvard Business School's Rock Center frames discovery as testing four linked hypotheses, in order:
| Hypothesis | The question | Killed by | | ------------ | ---------------------------------------------------- | ---------------------------------------------------------- | | Problem | Does this pain exist, and is it severe and frequent? | "That's annoying, but I just work around it." | | User | Who exactly has it worst? (persona, not "everyone") | Discovering your buyer and your user are different people. | | Solution | Would this approach actually relieve the pain? | Users love the problem statement, shrug at the demo. | | Value | Will they pay — money, time, or switching cost? | "I'd use it if it were free." |
Result: a solution hypothesis tested before the problem hypothesis is confirmed is how you build a beautiful answer to a question nobody asked.
Watch one real idea walk the gauntlet
This is not a hypothetical. In July 2026 we scanned "explainable expense-categorization exceptions for small accounting firms" twice, and here is what each hypothesis actually hit.
Problem — survived. A bookkeeper describing a two-year catch-up job spelled out the whole workflow unprompted: "park transactions without backup or clear indica of what they are (say mysterious E-TRANSFER to JIM BOB) to Uncat Income or Uncat Expense, complete the bank recs, and then send a list of all the uncats to the customer and then simply correct them after the fact" (r/Bookkeeping). Nobody writes that sentence about a problem they don't have.
User — survived, narrowed. The pain sits with the bookkeeper, but the sentence that mattered was about their client: "I've heard of Keeper and such but you need to have a client that is willing to keep up with it" (r/Bookkeeping). The person who feels the pain and the person whose behaviour causes it are different people. That is the User hypothesis doing its job.
Solution — killed and replaced. We went in assuming the fix was better categorisation. A QuickBooks Online user corrected the problem statement: "I know QBO bank rules can speed up categorization… But my recurring pain isn't the category, it's job/customer assignment" (r/quickbooksonline). Same market, adjacent problem, different product.
Value — never tested. Zero of the evidence establishes what anyone would pay. Not one post says a price. We will come back to this, because it is the hypothesis public evidence structurally cannot reach.
Three hypotheses moved, one didn't — and the one that didn't move is the one that decides whether this is a business. That ratio is normal. A scan that confirms all four is a scan that was reading for agreement.
Where Steve Blank's "customer development" fits
Customer discovery is step one of Steve Blank's four-step customer development cycle from The Four Steps to the Epiphany: discovery → validation → creation → company building. If discovery invalidates your hypotheses, you loop — pivot the hypothesis and test again, cheaply, before the next step spends real money. The loop is the point: customer development is not a phase you pass, it is a cycle you exit only with evidence. Eric Ries later compressed the same idea into build-measure-learn for The Lean Startup; Blank's version is the one that puts discovery before everything.
Customer discovery vs product discovery
The two get conflated constantly. They're different tools for different moments:
| | Customer discovery | Product discovery | | --------------------- | ------------------------------------ | ---------------------------------------------- | | When | Before you've committed to a product | After — while deciding what to build next | | Orientation | Problem-first: should this exist? | Solution-first: what should we ship? | | Core risk managed | Building something nobody wants | Building the wrong version of something wanted | | Typical owner | Founders | Product teams |
If you're pre-product, you're doing customer discovery, whatever your tools call it.
The same company does both, years apart. When Slack's founders watched their game studio fail and noticed every team wanted the internal chat tool more than the game, the question was "do teams have this problem at all?" — customer discovery. Years later, when Slack's product team debated whether threads or better search should ship next, the question was "which version of the solution serves them best?" — product discovery. Same company, same users, different decade of the same conversation.
Pick 3–5 target personas before you interview anyone
Discovery conversations only produce signal if you know whose pain you're sampling. Draft three to five candidate segments — concrete enough to find in the wild ("owner-operator of a 2–10 person accounting firm", not "SMBs") — and treat which segment hurts most as one of your discovery questions, not a settled fact. MIT's Bill Aulet goes further: pick one beachhead market and dominate it before touching the rest. B2B founders often use an ICP (ideal customer profile — firm-level criteria like size, industry, budget) to define who qualifies; we cover that distinction in our ideal customer profile guide.
Interviews: where discovery lives or dies
The mechanics are simple; the discipline isn't. Aim for one-on-one conversations (not focus groups — group dynamics bury dissent), recorded with permission, 20–30 minutes, with operators of the problem — not your friends.
Ten questions that produce evidence, not compliments
- "Walk me through the last time you dealt with [problem]." (past behavior, not speculation)
- "What did that cost you — time, money, mistakes?"
- "What have you already tried?" (workarounds = proof of pain)
- "Why did those solutions fail you?"
- "Who else on your team feels this?" (maps user vs buyer)
- "If nothing changes, what happens?"
- "What would have to be true for you to switch tools?"
- "Have you ever paid for something to fix this?" (value hypothesis, past tense)
- "Who else should I talk to about this?" (referral chain = sampling beyond your network)
- What you don't ask: "Would you use my product?" — see below.
What a passing answer to question 3 sounds like. Not "yeah, we've tried a few things." This: park the transaction in Uncat Income or Uncat Expense, finish the bank recs, send the client a list, correct after the fact. Named accounts, fixed sequence, a constraint (the client's time), a cost (the rework). If the answer to "what have you already tried" contains no proper nouns, you have not reached a workaround yet — keep asking. The same test applies to question 8: "I'd pay for that" is not an answer, QuickBooks Online, Keeper and Uncat are, and so is a number like the €174 below.
The Mom Test, in three rules
Rob Fitzpatrick's The Mom Test is the standard reference on why interview answers mislead — the title's point being that your questions should be good enough that even your mother couldn't lie encouragingly to you. The three rules: talk about their life, not your idea; ask about specifics in the past, not opinions about the future; listen more than you talk. I've failed this test myself — a previous product of mine passed every interview and died at launch; that story, and the full question frameworks, are in our Mom Test summary.
The I-Corps method: why NSF makes scientists do 100 interviews
The U.S. National Science Foundation runs I-Corps, a program that teaches researchers to commercialize science — and its core requirement is famously blunt: teams must complete 100 customer discovery interviews before the program ends. Not ten. The number is the method: the first ten conversations teach you your questions are wrong; the next thirty kill your favorite hypothesis; somewhere past fifty, patterns start repeating and you've found the shape of the market. If a federal science agency thinks no lab result is real until it survives 100 conversations, your weekend idea can survive twenty.
What interviews can't tell you
Interviews have a ceiling. They sample dozens of people, all of whom know they're being studied, and the Mom Test exists precisely because that awareness distorts what they say. There is a complementary evidence source with the opposite properties: complaints people post in public when nobody's selling to them. Nobody upvotes r/laundromats posts about broken water heaters to be polite.
The most honest evidence is produced when nobody is trying to sell anyone anything. Reading thousands of those posts is the job interviews can't do — and the job nobody wants to do manually.
Neither one measures what a price does
Interviews and complaint scans share a blind spot, and it is the expensive one. Both collect what people say and do while nothing is being charged.
Here is that blind spot with a receipt attached. A B2B SaaS founder posted a full accounting of a Reddit ad campaign: €174 spent, 111,927 impressions, 1,579 clicks — and, in his words, "Converted exactly zero people. ZERO." His verdict on the traffic was blunter than any interview would have been: "It's the cheapest, most useless traffic I've ever bought." (r/startups) A hundred thousand people were shown the offer. Sixteen hundred were interested enough to click. Zero were interested enough to buy. No volume of attention converted into a single commitment, and no interview and no scan would have predicted the gap — because attention and commitment are different variables and only one of them costs the customer anything.
What he did next is the part worth copying: he reframed the spend, "The €174 was spent to collect all that data, not acquire customers." That is a discovery budget, honestly relabelled after the fact.
What the founders who got paid did instead
The counterweight showed up in the same scan. A founder who says he interviewed 47 SaaS founders at $10K MRR reported that the ones who made it "sold before they built" — including "one guy [who] got 8 prepayments at $500 each before writing a single line of code" and another who "manually fulfilled the service for 3 months using spreadsheets and Zapier" before automating anything (r/SaaS).
⚠️ Grade that claim honestly, because this page keeps telling you to. It is one person's summary of conversations you cannot inspect — second-hand, unverifiable, and exactly the shape of story that performs well on Reddit. Our own extraction rated "they sold before they built" as high-strength and the manual-fulfilment line as corroboration_needed, which is the correct grade for both. Treat it as a hypothesis worth testing on yourself, not a finding.
$4,000 collected before a line of code is not a better interview. It is a different instrument. An interview asks someone to predict their own behaviour; a pre-sale makes them perform it. The four hypotheses do not all yield to the same tool — problem, user and solution respond to conversation, and value responds to an invoice.
Research report note: This section refers to a completed July 2026 WedgeScout run. It surfaced public discussion, not interviews or willingness-to-pay proof; read the solo SaaS evidence report for its evidence and limitations.
Where our own method stops
We ran this method on our own category — "cited public-discussion idea validation for solo SaaS founders" — and it came back with a finding we would rather it hadn't.
The scan surfaced a direct counter-signal, from someone arguing the whole premise: "One cannot 'validate demand'." (r/SaaS) His alternative — "One can create a strategy based on sound research and analysis though" — is not a refutation of research; it is a refutation of the word validate, and on the evidence above he has a point. Our extractor rated it corroboration_needed, logged it as a counter-signal, and it stayed in the report. A scan that only returns encouragement is a scan you should stop paying for, including ours.
The report then graded us. Its own limitations section says the run collected no case tying any automated scan — vendor or ours — to a paid conversion event, and that until it does, "differentiation against vendor scans will remain provisional." Written by our own pipeline, about our own pitch.
So, plainly. WedgeScout has scanned nine directions — small accounting firms, independent laundromats, pressure-washing crews, Etsy sellers, AI meeting notes for small teams, payroll documents, AP invoice exceptions, plugin installation, and solo SaaS founders. Across all nine, the count of interviews conducted is zero and the count of willingness-to-pay claims established is zero. Public complaints are excellent evidence for the problem hypothesis, good for the user hypothesis, useful for the solution hypothesis, and structurally silent on value. One founder in that scan put the limit better than our documentation does — "A model agreeing that people will pay is not the same as a single person taking out their card." (Our own run scored that unit excluded; I am quoting it on my judgment, not as a run finding, and I don't know why it was dropped.)
So use the scan for the three hypotheses it can actually reach, and go get an invoice signed for the fourth. Scout your market with WedgeScout → — cited evidence reports in about 10 minutes, counter-signals included, and it will tell you when the evidence isn't there.
Journey mapping: seeing the pain in sequence
A customer journey map visualizes one persona moving through one scenario — phases, actions, thoughts, and an emotion curve, with the low points marked as opportunities (definition per Nielsen Norman Group's framework). In discovery, the map does one job: it locates where in the sequence the pain concentrates, which is what your solution hypothesis should aim at.
You do not have to invent the sequence. The r/Bookkeeping poster quoted earlier mapped it himself, in one sentence, in the order it happens: park the mystery transaction in Uncat Income or Uncat Expense → complete the bank recs in QuickBooks Online → send the client the list of uncats → correct after the fact. Four phases, named in the practitioner's own vocabulary, and the emotional low is not where a founder would guess. It is not the parking (fast, feels like progress) and not the correcting (billable). It is phase three — waiting on the client — where the work stops moving for reasons the bookkeeper does not control. A second r/Bookkeeping practitioner, in a different thread found by a different scan, named that same phase as the constraint: a client "willing to keep up with it." A third, in r/quickbooksonline, placed his pain in the same gap — job/customer assignment, the field only the client can resolve.
Two independent people, two independent scans, zero shared sources — and both stalled at step three. That is what a journey map is for: not the drawing, the location. The pain has an address, and the address is a handoff, not a task. A product aimed at step one — faster categorisation — flattens the wrong part of the curve, which is precisely the mistake our own solution hypothesis was making until the map corrected it.
Journey map vs empathy map vs service blueprint
Don't confuse the family members — Nielsen Norman Group draws the distinctions this way. An empathy map has no timeline (a snapshot of one user's head), an experience map is product-agnostic (the generic experience of, say, "getting business insurance"), and a service blueprint maps your organization's backstage processes under the user's journey. For discovery you want the journey map; the others assume a product exists. NN/g's own library is the reference for all three, and it is worth reading before you draw anything.
Templates: track what you heard, not what you hoped
Discovery falls apart at the note-taking stage — twenty interviews, no comparable records, and memory quietly rewrites everything toward optimism. Use a tracker with one row per interview and columns that force falsifiability:
Date · Persona · Problem severity (their words) · Frequency · Current workaround · What they've paid/tried · Exact quotes · Hypothesis supported? (P/U/S/V) · Counter-signal? · Referral
Use the copy-ready interview tracker above, then move the findings into our broader market research template so the interview evidence sits beside public complaints, competitor findings, and counter-signals.
What skipping discovery costs
Three autopsies: Juicero, Quibi, Webvan
Juicero raised about $120 million to build a $400 Wi-Fi juicer — until Bloomberg demonstrated that hands squeezed the juice packs just as well as the machine. It shut down within five months. No discovery interview ever established that anyone's problem was squeezing. Quibi raised $1.75 billion for premium 10-minute mobile video and shut down six months after launch — the "commuters want short prestige TV" problem hypothesis was never tested against actual commuters, who already had TikTok and YouTube for free. Webvan burned through roughly $800 million building automated grocery warehouses for a delivery demand that 2001 households didn't yet have — infrastructure first, discovery never.
Two saves: Airbnb and Dropbox
Airbnb's founders flew to New York and stayed in their hosts' apartments to watch the product fail in person — Paul Graham canonized it in "Do Things That Don't Scale". Dropbox validated demand with a 3-minute demo video before building the hard infrastructure, converting a waitlist into evidence a launch video.
The pattern in all five: the money followed the order of operations. Problem evidence first, product second — or product first, autopsy second.
FAQ
What does customer discovery mean?
Customer discovery means testing whether a customer problem really exists — through interviews and evidence — before you build a product. It is step one of Steve Blank's customer development cycle: form problem/user/solution/value hypotheses, then let real customer behavior confirm or kill them.
How many customer discovery interviews are enough?
Customer discovery interviews are enough when new ones stop surprising you — usually 15–30 per persona for a solo founder. NSF's I-Corps program requires 100. Plan on 15–30 per persona and stop when new interviews stop surprising you. Ten is almost never enough — the first ten mostly fix your questions.
What questions should I ask in customer discovery?
The questions that work in customer discovery ask about specific past behaviour: "Walk me through the last time you hit this problem," "What have you tried?", "What did it cost you?" Avoid future hypotheticals — "would you use this?" produces polite lies. Full list above.
What's the difference between customer discovery and product discovery?
Customer discovery happens before you commit to a product and asks should this exist? (problem-first). Product discovery happens after, and asks what should we build next? (solution-first).
What is the difference between customer discovery and market research?
The difference between customer discovery and market research is direction. Market research measures a market from the outside — size, segments, trends, usually from analyst reports. Customer discovery tests your specific hypotheses from the inside, one real customer at a time. You can do market research from a desk; discovery forces contact with reality. In practice you run both: our market research template puts the outside-in sections and the complaint log in one document, and its market-snapshot section stays empty until someone counts something.
Is there a customer discovery template?
There is a customer discovery template on this page: the interview tracker above covers interviews; our market research template covers the wider research workflow.
The short version
Customer discovery tests whether a problem exists before you build. The people you interview will lie to you politely, so ask about specific past behaviour instead of future intentions. Four hypotheses, in order: problem, user, solution, value — a solution tested before the problem is confirmed is how you build a beautiful answer to a question nobody asked. Juicero raised $120 million, Quibi $1.75 billion, Webvan roughly $800 million; none tested the problem hypothesis first. Plan on 15–30 interviews per persona and stop when new conversations stop surprising you. And remember the ceiling: interviews sample dozens of people who all know they are being studied — the most honest evidence is behaviour that happened without you in the room. Public complaints supply that behaviour for three of the four hypotheses and none of it for the fourth: one founder's €174 bought 111,927 impressions and zero customers. Value responds to an invoice, not to a conversation — so the last test in discovery is a pre-sale, and everything before it is preparation for asking.