01 / Build the business
Customer discovery questions to ask before you build.
Ask potential customers to describe a recent situation, the steps they took, what went wrong, and how they handled it. Then investigate their alternatives and what would make a change worthwhile. Use their answers to choose your next test before building a product.
You will leave with: An interview outline and an evidence record you can use to decide what to investigate next. The example is a small business workflow; adapt the questions to your customer.
What a customer discovery interview should answer
This is an early problem interview: you want to understand how someone works before choosing a solution. A sales discovery call has a different purpose: checking whether an existing offer fits a buyer. Keep the two conversations distinct so a research invitation does not become an unexpected pitch.
Start with one uncertainty. For example: do independent wedding photographers repeatedly chase missing client details after a booking? You need examples of the workflow, including cases where it works well. Approval of an app idea would not answer that question.
Strategyzer's interview guidance recommends investigating the customer's situation before introducing a solution. The script and examples below apply that principle to a specific business task.Asking useful customer questions.
1. Choose people who recently did the work
Define the situation someone must have experienced to help you answer your question. Recruit for that experience, including people whose current process works well.
A short research brief
Decision: Should I investigate a client-information problem before designing a tool?
Participant: An independent wedding photographer who handles their own client intake.
Qualifying event: They collected details for a recent booking and can describe the steps.
Assumption: Missing information causes repeated work.
Evidence against it: Their current process collects what they need with little follow-up.
Ask a relevant contact for a voluntary introduction, or use a community that welcomes research requests. Describe the task you are studying and the time you are asking for. Do not recruit only people who already dislike their tools; that would exclude useful counterexamples.
An invitation after an introduction is welcome
I'm learning how independent photographers collect client details after a booking.
Would you be open to a 20-minute conversation about a recent booking and the process you used? This is research, with no product demo or sales pitch.
You would not need to share client names or private records.
Use a small initial batch that you can interview and review carefully. The batch size is a scheduling choice, not a threshold that validates the idea. Keep the recruitment source in your notes so you can see whether every answer comes from the same circle.
2. Use this 20-minute customer interview script
Open with the purpose and available time, follow one recent event, then explore alternatives and recap what you heard. Use follow-up questions selectively.
A workable starting agenda is two minutes for context, ten for the recent event, five for alternatives, and three for a recap. Adjust the timing when an answer needs more detail. This is an example agenda, not a tested formula or a checklist you must finish.
Opening the conversation
Thanks for helping. I want to understand how you collect client information, including what already works.
We have about 20 minutes. You can skip anything you prefer not to discuss.
May I take notes? I will keep names and client details out of the research summary.
If you want to record, ask separately and explain how you will use the recording. Taking notes does not imply permission to record, publish a quote, or identify the person.
| Ask | What you are trying to learn | Follow up if useful |
|---|---|---|
| Think of the last booking you handled. How did you collect the details you needed? | A specific event and the existing process | What happened between the booking and receiving the final details? |
| Which part took the most attention, if any? | Difficulty without assuming there was a serious problem | Can you walk me through that part? |
| What happened as a result? | The consequence of the difficulty | Did anything else have to wait or change? |
| How did you deal with it that time? | The actual workaround | What did that involve for you or someone else? |
| How typical was that booking compared with others? | Whether this was routine or an exception | Can you describe a recent booking that went differently? |
| What have you changed about this process before? | Previous attempts and their results | What made you keep or stop using that approach? |
| What tools or services do you use for this work now? | Existing alternatives and purchasing context | How did you choose them, and who was involved? |
| Where does improving this process fit among your current priorities? | Whether a real inconvenience merits action now | What are you working on first, and why? |
Let the participant finish before filling a silence. Ask for clarification when a phrase is vague: “When you say it took ages, what happened?” If they estimate time or cost, label it as an estimate. If they cannot recall an example, record that limit instead of suggesting an answer.
Closing without turning the call into a pitch
My understanding is [short summary of the event and current approach]. What have I missed or misunderstood?
Is there something important about this process that I have not asked?
Would you be comfortable with a follow-up if I have a specific question about these notes?
Replace leading questions with questions about behavior
A useful question leaves room for the idea to be wrong. Rewrite questions that contain your preferred answer, assume a pain point, or ask someone to predict a purchase.
| Avoid relying on | Try instead | Why the answer is more useful |
|---|---|---|
| Wouldn't automatic reminders save you time? | How did you handle missing information on the last booking? | The participant describes the process before evaluating your proposed feature. |
| How frustrating is your current software? | Which parts of your current process work well, and which need attention? | An adequate existing tool remains a possible answer. |
| Would you pay $20 a month for my app? | What have you bought or tried to improve this process? | Past purchases give context. They still do not establish a price for your offer. |
| Do you usually spend two hours chasing clients? | How much time did you spend on that booking, and how did you estimate it? | You do not supply the number you hope to hear. |
If someone volunteers a feature idea, record it as a suggestion. Then ask which recent event made them want it. A request for a dashboard may point to a visibility problem, but it is not yet a specification or a commitment to use your product.
3. Separate the account, the evidence, and your interpretation
After the conversation, write what the participant reported, what you actually observed, what you inferred, and what remains uncertain in separate fields.
Nina's first interview — a fictional worked example
Nina is researching onboarding for wedding photographers. One participant describes sending three reminders for a missing venue address before a recent booking. They estimate spending two hours on related administration that week.
The participant voluntarily shows a redacted email sequence. It contains three reminders with dates. Nina can record the visible reminder count. She cannot treat the two-hour estimate as measured time or attribute all of it to the missing address.
Another photographer says their existing intake form already collects the details they need. Nina keeps this answer. She asks what their process does differently instead of excluding it because it does not support her idea.
| Field | Record | Limit or next check |
|---|---|---|
| Reported event | Three reminders for a venue address on a recent booking | One booking; frequency across other bookings is still uncertain |
| Observed artifact | Redacted email sequence shows three dated reminders | Does not measure time spent or show every task that week |
| Participant estimate | Two hours of related administration that week | Do not present as two hours lost to the address issue |
| Founder interpretation | Missing information may create avoidable follow-up work | A hypothesis, not a confirmed need for software |
| Contradicting evidence | Another photographer's intake form appears sufficient | Compare how the two workflows collect required details |
| Next investigation | Compare recent bookings from photographers using different intake processes | Do not choose features or a price from these two accounts |
Interviews can inform a hypothesis, while a later experiment tests behavior under a defined offer. Strategyzer discusses this distinction between interview accounts and actions.Customer accounts and experimental evidence.
4. Choose the next test from what is still uncertain
Compare interviews about the same situation, retain contradictory cases, and choose one next investigation or offer test. Do not turn a small sample into a market forecast.
| What you found | Next useful action | What you cannot conclude yet |
|---|---|---|
| No participant can describe a relevant recent event | Check recruitment criteria and whether the assumed situation occurs | That the entire market has no demand |
| The issue occurs, but the current workaround is satisfactory | Investigate why it is satisfactory and whether a different situation needs help | That another feature would make people switch |
| A repeated problem matters, but buying context is unclear | Learn who chooses changes and how similar purchases were made | That the user you interviewed can authorize a purchase |
| A defined problem matters and a suitable buyer wants to explore a solution | Design a small, honestly described offer test with scope and a decision rule | That interest in a conversation equals willingness to pay |
There is no interview count in this workflow that guarantees validation. Start another batch when an important uncertainty remains, your sample is narrow, or accounts conflict. Move to a separate offer test when it can answer your next question more directly than another conversation. Set a time and cost limit for that test.
Use the broader validation workflow to define that experiment and distinguish an interview, a signup, and a paid pilot.Validate a business idea before you build.
Your customer discovery interview template
Use one record per conversation. Replace the prompts with your situation, keep identifying details private, and preserve answers that challenge the idea.
- Research decision
- One assumption: ____. Decision this research should inform: ____. Evidence that would challenge the assumption: ____.
- Participant and context
- Private interview ID/date: ____. Role: ____. Recruitment source: ____. Qualifying recent event: ____. Notes/recording permissions: ____.
- Conversation outline
- Opening: ____. Recent-event question: ____. Steps and consequence: ____. Workaround: ____. Alternatives and prior changes: ____. Priorities and decision process: ____. Recap: ____.
- What the participant reported
- Event and trigger: ____. Steps: ____. Consequence: ____. Estimate and its basis: ____. What already works: ____.
- What I observed
- Artifact voluntarily shared: ____. What it actually shows: ____. What it does not show: ____. Record unavailable if nothing was observed.
- Interpretation and contradictions
- My interpretation: ____. Evidence against it: ____. Other plausible explanation: ____. Still unknown: ____.
- Next decision
- Comparable interviews reviewed: ____. Next question or test: ____. Why it matters: ____. Time/cost limit: ____. Any agreed follow-up: ____.
Plain text. Open it in any text editor or paste it into your notes.
Your next action
Write one assumption and one question that could challenge it. Choose a suitable participant, then adapt the opening and recent-event prompts before inviting them.