Favors.dev
Every good customer discovery interview question does the same one thing: it asks about something that already happened. Not what someone would want, would use, or would pay — what they did, when they last did it, and what it cost them. Below are 22 questions grouped by stage, each with what to listen for in the answer and the follow-up to ask next, because the follow-up is where discovery actually happens. The script only gets you to the door.
That last point is the reason this post exists. The guides ranking for this query hand you 40, 50, sometimes 80 questions in a list and stop there — no guidance on what a good answer sounds like, no probe to ask next, nothing about how to recruit anyone in the first place or what to do with the notes afterward. A list of questions is not a discovery process. It's the raw material for one. So this version carries the question bank plus the three probes that make any of it work, a scorecard for grading an interview the moment it ends, a ten-minute debrief template, and an honest section on what interviews can't tell you no matter how well you run them.
What makes a discovery question good?
A good discovery question is answerable from memory. That's the whole test. If someone has to imagine, predict, or evaluate to answer, you are collecting fiction — polite, well-intentioned fiction, produced by a person who wants to be helpful.
This is the rule at the center of Rob Fitzpatrick's The Mom Test, which named the problem better than anyone: ask your mother whether your business is a good idea and she'll say yes, because she's answering a question about your relationship rather than your market. The fix isn't to demand honesty. It's to ask questions whose answers are facts about the past, which even a supportive mother can't inflate without noticing she's doing it. The practice itself is older — it's the core of what Steve Blank called customer discovery when he built the customer development method around getting out of the building and testing your assumptions against people who aren't you.
Three tests, applied to any question before you ask it:
- Past tense, not future tense.“What did you use?” beats “what would you use?” every single time. The past is a record; the future is a wish.
- Their world, not your product.The best Stage 1 questions could be asked by a journalist who has never heard of your company. If a question only makes sense because of what you're building, save it for later.
- Answerable with a story, not a rating.Anything that ends in a number on a scale of one to ten is a survey question. You're here for the thing that happened before the number.
The question bank: 22 questions by stage
Run these in three stages, in order, and treat the stage boundary as a gate: don't move to solution questions until problem questions gave you a real problem, and don't move to money questions until a solution has somewhere to live. You will not ask all 22 in one conversation — pick six to ten, and let the follow-ups eat the rest of the time.
Stage 1 · Problem discovery
Find out whether the problem exists outside your head — before you describe anything you're building.
Rule: Say nothing about your product in this stage. The moment you do, every answer after it is contaminated.
“Walk me through the last time you had to do this. What happened?”
Listen for — A specific instance with a time attached. If they slide into “usually I…” you're getting a summary of their self-image, not a record of their week.
Then ask — “When exactly was that? What were you doing right before?”
“How often does that come up?”
Listen for — A number they produce without effort. Hesitation followed by “it depends” usually means rarely.
Then ask — “When was the most recent time before that one?”
“What did you do about it?”
Listen for — An action, ideally an ugly one. A hacky workaround is the strongest signal in this entire list.
Then ask — “Can you show me? I'd love to see the actual thing.”
“What was open on your screen while you did that?”
Listen for — The real stack, including the spreadsheet nobody lists when you ask what tools they use.
Then ask — “Which of those do you pay for?”
“What happened downstream — did it cause anything else?”
Listen for — Consequences. A problem with no second-order cost is an annoyance, not a purchase.
Then ask — “Roughly how much time did that cost you that week?”
“Who else was involved when this came up?”
Listen for — The decision unit. In B2B the person with the pain is often not the person who signs.
Then ask — “Who would have to agree before you changed how this works?”
“When did you last go looking for a better way to do it?”
Listen for — Search behavior. People who have never looked have not decided the problem is worth solving.
Then ask — “What did you type in? What came back?”
“What's the last thing you tried that didn't stick?”
Listen for — Your future churn reason, described in advance and for free.
Then ask — “What would it have needed to do to keep you?”
Stage 2 · Solution fit
Find out where a solution would have to live and what would stop it. Only run this stage once Stage 1 gave you a real problem.
Rule: Ask about their workflow, not your features. “Would you use it?” is not a question, it's a compliment request.
“If we'd never spoken, what would you have done about this next month?”
Listen for — The do-nothing baseline. This is your actual competitor, and it usually wins.
Then ask — “What would have had to change for you to act on it sooner?”
“Where in your week would something like this have to sit?”
Listen for — Whether there's a slot for you at all. Tools without a slot get signed up for and never opened.
Then ask — “What would you have to stop doing to make room?”
“What's the first thing you'd try to do with it?”
Listen for — Their true first-run job — which is rarely the one your onboarding is built around.
Then ask — “And what would make you close the tab in the first minute?”
“What would have to be true for you to stop using what you use now?”
Listen for — The switching cost, stated as a threshold. If they can't name one, the incumbent is safe.
Then ask — “Has that ever happened with another tool? What did it take?”
“Which part of this would you expect to break?”
Listen for — Trust objections. People predict the failure they've already lived through somewhere else.
Then ask — “What would you need to see to believe it wouldn't?”
“Who on your team would push back, and what would they say?”
Listen for — The objection you'd otherwise meet six months later in a lost deal.
Then ask — “How have you gotten past that person before?”
“What would you have to explain to someone to justify bringing this in?”
Listen for — The internal pitch. If they can't construct it, you don't have a story yet — they do the selling, not you.
Then ask — “What number would they ask you for?”
Stage 3 · Willingness to pay
Find out whether money and authority exist. This is the stage founders skip, and it's the one that decides whether the other two mattered.
Rule: Never ask “would you pay for this?” Ask what they already paid, to whom, and how the decision got made.
“What does this problem cost you today, in hours or dollars?”
Listen for — Any number at all. Vagueness here means the problem hasn't been priced, which means it hasn't been prioritized.
Then ask — “How did you arrive at that?”
“Walk me through how you bought the last tool like this.”
Listen for — The actual purchase path — trial, card, approval, procurement. This is your sales process, described by the buyer.
Then ask — “How long did the whole thing take from first look to paying?”
“Who signed off, and what did you have to show them?”
Listen for — The artifact you'll eventually have to produce: a case study, a security page, a number.
Then ask — “What almost killed it?”
“Which budget would this come out of — and does that budget exist right now?”
Listen for — Whether there's a line item or a hope. “We'd find the money” is a no in a friendly costume.
Then ask — “When does that budget reset?”
“If it existed today at around this price, what's the one question you'd need answered before saying yes?”
Listen for — The real objection. This question converts a polite yes into a usable no.
Then ask — “And if that were answered, what happens next on your end?”
“Can I set you up on Tuesday?”
Listen for — An advance or a dodge. A commitment that costs them something — time, data, a card, an intro — is the only reliable proof of interest.
Then ask — “If not Tuesday, what would need to be true for a date to work?”
“Who else should I be talking to about this?”
Listen for — Both a referral and a verdict. People who found the conversation worthwhile give names; people who didn't say they'll think about it.
Then ask — “Would you be up for introducing me?”
Notice how little of this is about your idea. Stage 1 has 8 questions and none of them mention a product, which is deliberate and genuinely hard to do — the urge to explain what you're building arrives around minute four and it never goes away. Resist it for the first half. Everything the interviewee says after they know what you want to hear is worth a fraction of what they said before.
The three follow-ups that do the real work
Three probes cover almost every situation, and running them well matters more than which of the 22 questions you opened with. Each one takes a soft answer and converts it into something you could put in a document and defend.
The specificity probe “When was the last time?”
Turns a generalization into an instance. People describe their habits the way they'd like them to be and their last Tuesday the way it was. Every claim in an interview is worth exactly as much as the most recent concrete example behind it — and if there isn't one, you've learned the most important thing in the conversation.
The evidence probe “Can you show me?”
Turns a claim into an artifact. The spreadsheet, the Slack channel, the folder of screenshots, the script someone wrote in 2023 and never told anyone about. Nobody builds a workaround for a problem they don't have, which makes the artifact the single most reliable signal you can collect. Ask for a screen share; most people say yes.
The cost probe “What did that cost you?”
Turns an annoyance into a priority. Hours, dollars, a missed deadline, a customer who left. Founders routinely finish an interview delighted that the problem is real without ever establishing that it's expensive — and cheap real problems are where startups go to die quietly.
There's a fourth that isn't a question: stop talking. When someone finishes an answer, count to three before you respond. The sentence that arrives in that gap is very often the honest one — the qualification, the “although, to be fair…”, the detail they were deciding whether to mention. Founders fill silence because silence feels like a failure of hosting. In an interview it's the most productive four seconds available to you.
How many discovery interviews do you need?
Six to see the shape, about twelve to trust it. That's not a folk number: the most-cited empirical test of the question is Guest, Bunce and Johnson's 2006 study in Field Methods, which systematically coded sixty in-depth interviews and found that saturation — the point where additional interviews stop surfacing new themes — occurred within the first twelve, with the basic elements of the major themes already present by six.
The condition attached to that finding matters as much as the number. It held for a relatively homogeneous population and a narrowly defined research question — which is precisely the situation you are in when you interview one customer segment about one job, and precisely not the situation you're in when you interview “small business owners” about “productivity.” So the number is really a diagnostic:
- Interviews 1–6:you're learning the vocabulary. Expect to be surprised constantly and to rewrite your questions after each one. That rewriting is the work, not a sign you started badly.
- Interviews 7–12:you're testing whether the pattern holds. Write down what you believe after six and try to break it — you'll defend it otherwise.
- Still surprised at twelve? Your segment is too broad, not your sample too small. Split it and run six more inside one half.
How do you find people to interview?
Four sources work when nobody knows who you are, and they're ranked here by how honest the resulting conversation tends to be, not by how easy the yes is:
- People publicly complaining about the problem. A Reddit thread, an X reply, a GitHub issue, a one-star review of a competitor. Pre-qualified by definition and flattered to be asked. Approach as a curious stranger, not a vendor — the etiquette that keeps you welcome is in the guide to marketing on Reddit without getting banned.
- Communities where the job is discussed daily. The Slack, Discord, or forum your target user was already in before you needed something. Ask in public for their expertise, not in DMs for their time; which rooms are worth joining is mapped in indie hacker communities 2026.
- Second-degree contacts via a warm introduction. One remove from your network gets you the access without the politeness tax that makes friends and family useless as interviewees.
- Other founders.Easy to reach, used to being interviewed, and — if they build for a similar buyer — often carrying the exact problem you're investigating. The catch is that a cold “can I pick your brain” DM converts about as well as it deserves to.
That fourth source is the one worth engineering, because the yes rate on it is a function of reciprocity rather than charm. Sit for someone else's discovery interview and the ask becomes symmetrical instead of extractive. That symmetry is the entire design of Favors.dev, the founder marketing co-op I run: you earn points by doing verified favors for other founders — structured feedback, an honest review, a real critique — and spend them to pull the same help back. The founder directory is a searchable list of people who have already opted into being useful, which is a materially different starting point than a cold inbox. Nobody can spend what they haven't earned, so the well doesn't run dry in month three the way informal founder groups reliably do.
One warning about founder interviewees: they are excellent for problem discovery when they're genuinely in your segment and actively misleading when they're not. A founder will happily reason about your market from first principles for twenty minutes. That's a conversation, not data. Apply the same past-tense test you'd apply to anyone.
The scorecard and the 10-minute debrief
Score the interview the moment it ends, before you do anything else, because your memory of it starts flattering you within the hour. Five signals, two points each — a strong answer scores 2, a partial 1, an absent 0.
| Signal | Scores 2 | Scores 0 |
|---|---|---|
| Specificity | Named a date, a project, or a person unprompted. Told a story with a beginning. | Stayed in “usually” and “generally” the whole time. |
| Existing workaround | Showed you a spreadsheet, a script, a process, or a paid tool doing the job badly. | “I just deal with it” — or nothing at all. |
| Cost named | Quantified hours, dollars, or a concrete consequence without being pushed. | Called it annoying and moved on. |
| Active search | Has gone looking for a fix recently and can tell you what they found. | Has never searched for one. |
| Advance offered | Gave you something that costs them: a next meeting, their data, an intro, a card. | “Send me the link and I'll take a look.” |
8–10: a real problem with a real budget behind it — follow up within two days. 4–7:the problem is real and unpriced; keep them on the list and re-interview after you've narrowed the segment. 0–3: a pleasant conversation. Log it and move on, and resist the urge to count it as validation because they were enthusiastic. Enthusiasm scores zero on this card on purpose.
Then spend ten minutes on the debrief while it's fresh. Same eight lines every time, so the notes are comparable across twelve interviews rather than twelve differently-shaped documents:
The 10-minute debrief
- The problem, in one sentence— as they experience it, not as you'd pitch it.
- Two or three verbatim quotes — their words, unpolished. These become your landing page later.
- What they do today — the workaround, described concretely enough that you could replicate it.
- What it costs them— a number, or the word “unknown,” which is itself a finding.
- What surprised me— the single most valuable line in the template. If it's empty, you talked too much.
- What this kills or confirms— name the specific assumption. “Interesting” is not an outcome.
- The advance they gave — a next meeting, data, an intro, money, or nothing.
- Who they pointed me to — your next interview, pre-warmed.
After six of these, read all six debriefs in one sitting rather than reviewing each as it lands. Patterns live between interviews, not inside them, and the founder who synthesizes after every call ends up steering the product with whoever spoke most recently. Once you have something built, the same discipline carries over to grading what testers send you — the four-dimension rubric for that is in how to get product feedback before launch.
What customer interviews can't tell you
Interviews are the wrong instrument for predicting behavior, and treating them as a verdict is how founders build confidently wrong things. Nielsen Norman Group put the critical failing plainly in their analysis of interviewing users: you're asking people either to remember past use or to speculate about future use, and human memory is reconstructive — people build a tidy story to explain what they did. Their recommendation is triangulation: pair interviews with watching someone actually use the thing, and trust the two together over either alone.
Concretely, that means three things stay out of reach:
- Whether they'll buy.Only a commitment tests that — a card, a deposit, a signed pilot, a calendar slot. Which is why question 21 exists and why a warm “definitely, send me the link” scores zero on the card above.
- Whether your interface works.That's observation, not conversation. Put a build in front of people and watch where they stall — the recruiting map for that is in how to find beta testers.
- How big the market is. Twelve interviews tell you a problem is real and shaped a certain way. They tell you nothing about how many people have it, and no amount of enthusiasm in the room changes that.
Used inside those limits, discovery is the cheapest leverage a solo founder has. Twelve conversations cost you a week and can save you a quarter of building the wrong thing — and the people who gave you those hours are, not coincidentally, the shortlist you go back to when it's time to get your first 100 users. Discovery isn't a phase you exit. It's the first contact with the people who become your launch.
Frequently asked questions
How many customer discovery interviews should you do?
Six to see the shape of the problem, around twelve before you trust it, and more only if your market is genuinely varied. The most-cited empirical work on this is Guest, Bunce and Johnson's 2006 study in Field Methods, which coded sixty in-depth interviews and found that thematic saturation — the point where new interviews stop producing new themes — occurred within the first twelve, with the basic elements of the major themes already visible by six. That was a homogeneous population with a narrow research question, which is exactly the situation a solo founder is in when interviewing one customer segment about one job. The practical rule: run six, write down what you think you know, then run six more and see whether they change your mind. If interviews eleven and twelve are still surprising you, your segment is too broad, not your sample too small.
What questions should you never ask in a customer discovery interview?
Anything hypothetical, anything leading, and anything that invites a compliment. “Would you use this?”, “How much would you pay for it?”, “Do you think this is a good idea?” and “Would you want a feature that does X?” all ask people to predict their own future behavior, which humans are reliably bad at — and to do it while being polite to the person who built the thing. Replace each with its past-tense equivalent: what did you use, what did you pay, what did you do the last time this came up. The one exception is the closing commitment question — “can I set you up on Tuesday?” — which is a real test precisely because it asks for something now rather than an opinion about later.
How long should a customer discovery interview be?
Twenty to thirty minutes is the right ask, and forty-five is the right container. A short ask gets accepted; people who are engaged will talk past the time on their own, and that overrun is itself a signal. Plan six to ten questions rather than a script of twenty — you will only get through a handful properly, because each good answer should spawn two or three follow-ups. Founders who get through their whole list have almost always interviewed badly: it means nothing they heard was interesting enough to chase.
How do you find people to interview when you have no customers?
Four sources work without an audience: communities where your target user already discusses the problem, people publicly complaining about it on Reddit or X, second-degree contacts reached through a warm introduction, and other founders — who are both easy to reach and unusually willing to be interviewed, because they need the same favor back. Ask for their expertise rather than their opinion of your idea, keep the ask to twenty minutes, and never let the request double as a pitch. The most reliable recruiting channel is reciprocity: agree to sit for someone else's discovery interview and the yes rate on your own goes up sharply.
What's the difference between customer discovery and user feedback?
Customer discovery asks whether the problem is worth solving; user feedback asks whether your solution solves it. Discovery comes first, involves no demo, and is mostly about the interviewee's past. Feedback comes after you have something to put in front of people, involves watching them use it, and is mostly about the present. Running them in the wrong order is the classic founder error — you demo in minute two, the conversation becomes a reaction to your screen, and you never learn whether anyone was looking for this before you showed up.