Customer Discovery Questions

The questions that surface the real problem, the constraints, and the definition of success — before you write a line of code.

Discovery is how you learn which problem is worth solving before you build anything. These questions are designed to surface specific past behavior — what people actually did, what it cost, who was involved — because opinions about the future are unreliable and polite people will praise almost any idea.

Run each call as an investigation, not a pitch: watch the real workflow, put a number on the pain, and leave with a metric, a baseline, the constraints, and the names of the people who can say yes or no.

The problem (not the feature)

Walk me through it: “Show me how you do this today, step by step.” Watch, don’t ask them to summarize.
Cost of the status quo: “What does this cost you now — time, money, errors, missed revenue?”
Last time it hurt: “Tell me about the last time this went wrong.” Specifics beat generalities.
Who feels the pain: “Who does this today, and how many of them?”
Why now: “Why is this worth solving this quarter and not last year?”
What you tried: “What have you tried already, and why didn’t it stick?” — shows real effort and failed fixes
How often: “Daily, weekly, at quarter-end?” Frequency times cost is the size of the prize
The workaround: “Can I see the spreadsheet or script you use today?” A workaround proves the pain is real
If it vanished: “If this problem disappeared tomorrow, what would you do with that time?”

Workflow & data

Inputs and outputs: “What comes in, from where, and what has to come out — in what format?”
Volume: “How many per day, and what does a busy day look like?” — this sizes the system
Edge cases: “Which weird cases eat half your time?” The long tail decides feasibility
Real examples: “Can you share 20 real examples, good and bad?” — the seed of your eval set
Hand-offs: “Who touches it before you, and after you?” Every hand-off is an integration
Approvals: “When does a person have to sign off, and who is that?”

Success & scope

Definition of done: “If this works perfectly, what’s different on Monday morning?”
The one metric: “What number would move that tells us it worked?”
Good enough: “What accuracy / latency / coverage is good enough to be useful?”
The demo bar: “What would you need to see to believe this is real?”
Baseline: “What is that number today?” Without a baseline nobody can prove an improvement
Cost of a wrong answer: “When it gets one wrong, is that annoying, rework, or a compliance incident?”
Human review: “Where must a person check the output before anything goes out?”
Out of scope: “What should the first version explicitly not do?”

Constraints (find the landmines)

Where can it run: “Cloud, your VPC, on-prem, air-gapped? Who approves that?”
Data rules: “Can data leave your network? Any PII / regulated data (HIPAA, PCI)?”
Systems to touch: “What systems hold the data — and who owns access to them?”
Security review: “What does it take to get a new tool approved here?”
Deadline drivers: “Is there a date this must work by — a launch, an audit, a renewal?”
Existing tools: “What do you already pay for that does part of this?”
AI vendor rules: “Are any AI vendors or models approved here, or banned?”

People (map the room)

Champion: “Who wants this to succeed and will fight for it internally?”
Blocker: “Whose approval could stop this — security, legal, a skeptical lead?”
Decision maker: “Who signs off / holds the budget?”
The user: “Who actually uses it daily — and do they want it?”
How buying works: “Walk me through the last time you brought in a tool like this.”
Budget: “Where would the money come from?” — tells you whether it is funded or a wish
Who else to ask: “Who else should I talk to about this?” — end every interview with it

Running the conversation

Past, not future: ask what they did last time, not what they would do — hypotheticals invite polite fiction
Their life, not your idea: pitching early turns discovery into a sales call; describe your idea last, if at all
Compliments are noise: “Sounds great!” is not data — steer back to a specific recent example
Follow the emotion: a sigh or an “ugh” is a lead: ask why that part is so painful
Talk less: let them speak most of the time; a pause after a question is fine
No leading questions: not “Would you use a tool that…?” but “How do you handle that today?”
Ask for a commitment: end with a next step that costs them something — time, data access, an introduction

After the call

Write it up within a day: problem, metric, constraints, people, open questions — while it is fresh
Send a recap: play back what you heard in their words; corrections are the most valuable reply
Facts vs. guesses: mark what they said, what you saw, and what you only inferred
Red flags: no metric, no owner, no data access, or “just add AI” — resolve these before building

Recipes

A 45-minute discovery call

0-5 min    intros, purpose, permission to take notes: "I'm here to learn, not to pitch"
5-20 min   "Walk me through how you did this last time" (screen-share the real workflow)
20-30 min  pain and cost: how often, time per case, errors, what breaks at quarter-end
30-38 min  success: the one metric, today's baseline, what "good enough" means
38-43 min  constraints and people: data rules, where it can run, who approves
43-45 min  a next step with a date, and "Who else should I talk to?"

Spend most of the time on the walkthrough: watching one real case beats an hour of description. If you run out of time, cut the agenda, not the next step.

Turn a feature request into a problem statement

request:   "We need an AI chatbot for our support team."
ask:       "What would it handle on day one?"           -> password-reset tickets
ask:       "How many, and what does each one cost?"     -> 1,200 a month, about 6 minutes each
ask:       "What does done look like?"                  -> half of them resolved with no agent

problem:   1,200 password-reset tickets a month take about 120 agent-hours
metric:    share resolved without an agent (baseline 0%, target 50%)
scope v1:  password resets only, in English; hand off to a human if the identity check fails

The request named a solution; the questions found the job, its size and a measurable target. Scope v1 is narrow on purpose — it can ship and be proven in weeks.

Spot and fix a leading question

leading:    "Would you use a tool that summarizes your contracts automatically?"
            -> "Sure, sounds useful."          (polite, hypothetical, worthless)

better:     "Tell me about the last contract you had to review."
            -> "It took two days, and I missed an auto-renewal clause. We paid for a year."

follow-up:  "What did that cost? What do you do differently now?"

The better question produces a story with a cost attached, which is evidence. The first only tells you the person is polite.

A discovery recap email

Subject: Recap: invoice matching, and next steps

What we heard
- 3 AP clerks match about 2,000 invoices a month to POs by hand (~4 min each)
- mismatches over $500 need controller approval: about 8% of invoices
- success = 70% matched automatically, with zero false matches over $500

Constraints:     data stays in your Azure tenant; security review takes ~3 weeks
Open questions:  who owns the ERP export? can we get 200 sample invoices?
Next step:       data walkthrough with Priya, Thursday 2:00 pm

Writing it down exposes gaps before they become rework, and the customer’s corrections are often the most useful thing you learn all week.

Questions about Customer Discovery Questions Cheat Sheet

What questions should I ask in a customer discovery interview?

Ask about specific recent events rather than opinions: walk me through the last time you did this, what did it cost, what have you tried, and why did that not work. Then quantify: how often it happens, how long it takes, how many people are involved. Ask what success would look like and how it is measured today, so you get a metric and a baseline. Uncover constraints such as data rules, security review and where software can run, and map the people: who uses it, who pays, who can block it. Close by asking who else you should talk to.

What is the Mom Test?

The Mom Test is a set of interviewing rules from Rob Fitzpatrick’s book of the same name, named for the idea that even your mother should not be able to lie to you if you ask the right questions. Talk about their life instead of your idea, ask about specifics in the past instead of generalities or the future, and talk less while listening more. Compliments, hypothetical promises and feature requests are treated as weak data, while past behavior, money already spent and commitments such as time, introductions or a pilot are strong signals.

How many customer discovery interviews do I need?

Enough to stop hearing new things within a segment. Patterns usually start to repeat after five to ten conversations with similar people, such as the same role in similar companies, and if every call sounds different your segment is too broad. For an enterprise or forward-deployed project with one customer, cover every role that touches the workflow: the daily users, their manager, the budget holder, IT or security, and whoever owns the data. Keep interviewing after you start building, because the first prototype will surface questions nobody could answer in the abstract.

How do I avoid leading questions in customer interviews?

Avoid questions that contain your solution or invite agreement, such as would you use, do you think it would be useful, or would you pay for. They produce polite yes answers that predict nothing. Ask about what already happened instead: how do you handle this today, tell me about the last time, what did you do next, what did that cost. Keep questions open, avoid suggesting answers, and stay quiet long enough for people to fill the silence. If you need a reaction to an idea, show it at the end and watch for a concrete commitment rather than enthusiasm.

Go deeper

FDE playbook →Demo checklist →