# How to Run Customer Discovery Interviews > Run customer discovery interviews for evidence: recruit the right people, ask about past behaviour, avoid pitching and turn notes into product decisions. - Canonical: https://zeroraised.com/blog/how-to-run-customer-discovery-interviews - Published: 2026-10-25 - Author: ZeroRaised Team (https://zeroraised.com/blog/authors/zeroraised) - Publisher: ZeroRaised (https://zeroraised.com/) - Section: Building - Tags: customer-research, validation, first-users, bootstrapping Customer discovery interviews are conversations with people who have the problem you want to solve. They are not pitches, surveys or validation rituals. The point is to learn how the problem shows up in someone's work, what they do about it today and what would have to change for them to try a different approach. Done well, a handful of interviews can save months of building the wrong thing. Done badly, they produce polite encouragement and false confidence. **TL;DR** - Interview people who have the problem now and have already acted on it. - Ask about the last time it happened, the workaround, the cost and the decision. - Do not pitch your idea or ask whether someone would use it. - Record exact phrases and compare themes across interviews. - Use the evidence to make a product, pricing or positioning decision. **Disclosure:** ZeroRaised publishes this guide and is a launch and discovery site for bootstrapped products. It appears near the end as a place to present a product after the discovery work, not as a substitute for it. ## What customer discovery is, and what it is not Customer discovery is qualitative research. It helps you understand the problem, the language, the workflow and the constraints of a specific group of people. It does not prove that a market is large enough, that people will pay or that your solution will work. It is not: - **A sales call.** If you are pitching, the person is responding to you rather than describing their work. - **A survey.** Surveys are useful for measuring patterns across many people, but they are poor at discovering the details of a workflow. - **A vote on your idea.** Asking "would you use this?" invites a hypothetical answer that costs the person nothing. - **A one-off conversation.** A single interview is an anecdote. Discovery is a set of conversations compared systematically. The useful output is a better model of the problem: what triggers it, who feels it, what they do now, what it costs and what would make them switch. That model should influence the product and the positioning. ## Who to interview The best interview subjects have three qualities: 1. **They have the problem now.** Not a problem they had years ago, and not a problem they might have if their business changes. 2. **They have acted on it.** They have built a workaround, hired someone, bought a tool or complained publicly. Action is stronger evidence than opinion. 3. **They can describe the decision.** They either make the buying decision or can explain who does. Aim for a narrow segment at first. Five interviews with freelance designers who invoice by the hour will produce a clearer pattern than five interviews with "small businesses" in different industries. You can broaden later. Where to find them: - communities where the problem is discussed; - reviews of competing products; - marketplaces and app stores; - support inboxes and existing customers; - events, workshops and meetups; - warm introductions from people who know the work; - waitlists and adjacent tools. The [early adopters guide](https://zeroraised.com/blog/how-to-find-early-adopters) covers recruitment in more detail. The [SaaS validation guide](https://zeroraised.com/blog/how-to-validate-a-saas-idea-before-building) explains how interviews fit into a broader validation plan. ## Recruit with consent and context Ask for a conversation, not a favour. Explain who you are, why you are researching the problem and how long the conversation will take. If you want to record, ask permission and explain how the recording will be stored and used. Do not scrape email addresses or send bulk messages to strangers. In the United Kingdom, unsolicited marketing by email, text or direct message to individuals requires consent, and a research invitation can still be regulated depending on how it is framed. Keep the message personal, relevant and easy to ignore. A short recruitment message can say: > I am researching how [specific user] handles [specific problem]. I am not selling anything. Would you be open to a 20-minute conversation about how you do this today? I am happy to work around your schedule. That message is honest about the purpose and the time. It does not promise a product or a reward it cannot deliver. If you offer an incentive, keep it simple and disclose it. A small gift card or a donation may be appropriate for a longer interview. Do not make the incentive so large that people participate only for the reward. ## The interview structure A 30-minute interview can follow five parts. Adjust the timing to the person and the topic. ### 1. Context (5 minutes) Ask about the person's role, the work they do and how the problem fits into their week. Keep it factual. Do not ask them to summarise their entire job. Useful questions: - What does a typical week look like for you? - Where does [the problem] show up in your work? - Who else is involved when this happens? ### 2. The last time it happened (10 minutes) Ask for a specific recent example. Specificity is the difference between a story and a generality. Useful questions: - When did this last happen? - Walk me through what you did. - What did you try first? - What happened next? - How long did it take? - What else did you have to stop doing to handle it? If the person gives a general answer, ask for the most recent example. "Usually" is less useful than "last Tuesday". ### 3. The workaround and the cost (10 minutes) Ask how they solve the problem today and what that costs. Cost can be money, time, errors, stress or risk. Useful questions: - What do you use today? - Why that approach rather than another? - What does it cost you in money or time? - What goes wrong with it? - Have you tried anything else? Why did you stop? ### 4. The decision (5 minutes) Ask how a change would be approved and what would trigger it. Useful questions: - Who else would need to agree to a change? - What would have to happen for you to look for a different solution? - What would make you reject a new tool? ### 5. The close (5 minutes) Ask whether you can follow up, whether they know someone else with the problem and whether they would like to hear about the research. Do not pitch the product unless the person asks. If they do ask, keep the answer short and return to their workflow. ## Questions to avoid Some questions produce misleading answers. Avoid: - **"Would you use this?"** It is hypothetical and costs the person nothing to say yes. - **"Do you think this is a good idea?"** It invites an opinion about your idea rather than a description of their problem. - **"How much would you pay?"** People are poor at predicting their own future purchases. Ask what they pay today instead. - **"Don't you hate it when...?"** Leading questions tell the person what answer you want. - **"Our product does X. What do you think?"** This turns the interview into a pitch and anchors the conversation on your solution. ## Take notes you can use You do not need a perfect transcript. You need enough detail to compare interviews and quote the person accurately. Record, with permission, or take notes during the call. Write down: - the exact words the person uses for the problem and the workaround; - the sequence of events in the last example; - the tools and people involved; - the cost or consequence; - the trigger for a change; - any objection or constraint. After the call, add a short summary: the three most important things you heard, the questions that produced the best detail and what you want to ask next time. Use a simple tagging system. For example: `trigger`, `workaround`, `cost`, `decision`, `objection`, `language`. Then compare tags across interviews. A theme that appears in one interview is a hypothesis; a theme that appears in five is a pattern worth acting on. | Theme | What to capture | Example question | |---|---|---| | Trigger | The event that starts the problem | When did this last happen? | | Workaround | The current method | What did you do next? | | Cost | Time, money, risk or stress | What did it cost you? | | Decision | Who approves a change | Who else is involved? | | Objection | Why they resist a new approach | What would make you reject it? | | Language | The words they use | How would you describe this to a colleague? | ## Turn notes into decisions At the end of a round of interviews, write a one-page synthesis. Include: - the narrowest user segment you spoke to; - the problem in their words; - the workarounds they use; - the cost of the workaround; - the trigger for seeking a change; - the objections and constraints; - the questions you still cannot answer. Then make a decision. Discovery is only useful if it changes something. Possible decisions: - **Build the narrow workflow** that appeared in most interviews. - **Change the positioning** to match the language people actually use. - **Change the price** based on the current spend or the value of the result. - **Change the audience** because the people with the urgent problem are different from the ones you assumed. - **Stop the project** because the problem is not urgent, the workaround is good enough or the buyers cannot decide. Write down the decision and the evidence behind it. That record is useful when the product changes and when you explain the product to someone else. ## When to stop interviewing Stop when additional interviews stop producing new themes, or when you have enough evidence to make the next decision. That is a judgement, not a fixed number. Do not keep interviewing to avoid building. At some point, the next useful evidence comes from a prototype, a landing page test or a paid pilot. The [waitlist guide](https://zeroraised.com/blog/how-to-build-a-waitlist-before-launch) and the [first 100 users guide](https://zeroraised.com/blog/how-to-get-your-first-100-users) cover those steps. ## Common mistakes - **Pitching instead of listening.** The interview becomes a sales call and the evidence disappears. - **Asking about the future.** Hypothetical answers are cheap. Ask about the past. - **Interviewing only friendly people.** Supportive friends produce supportive answers. - **Taking notes but never synthesising.** A folder of transcripts is not a decision. - **Changing the product for one loud customer.** Look for patterns across interviews, not the strongest opinion. - **Ignoring the buyer.** A user who loves the product but cannot approve a purchase is not the whole picture. - **Recording without consent.** Ask, explain and respect the answer. ## A two-week discovery plan This is a sequence, not a guarantee. **Days 1 to 2: define the segment and the problem.** Write one paragraph describing the person, the job and the workaround. List where you will find them. **Days 3 to 4: recruit five people.** Send personal invitations and schedule the calls. Do not wait for a perfect list. **Days 5 to 9: run the interviews.** Ask about the last time, the workaround, the cost and the decision. Take notes and record with permission. **Days 10 to 11: synthesise.** Tag the notes, compare themes and write a one-page summary. **Days 12 to 14: decide the next step.** Choose one product, positioning or pricing change, or run a landing page test. Write down what would change your mind. ## Where ZeroRaised fits ZeroRaised is a launch and discovery site for products built without institutional venture capital or accelerator equity. Discovery comes before the launch; when you have something people can try, you can [submit it here](https://zeroraised.com/submit). The [pricing page](https://zeroraised.com/pricing) explains the current options, and the [archive](https://zeroraised.com/archive) shows how products are presented. A launch page is a useful place to explain the problem in the language you learned from interviews. It is not a replacement for the interviews themselves. Pair this guide with the [early adopters guide](https://zeroraised.com/blog/how-to-find-early-adopters) and the [product launch checklist](https://zeroraised.com/blog/product-launch-checklist-for-bootstrapped-makers). ## Sources and further reading - [Y Combinator, How to Talk to Users](https://www.ycombinator.com/library/6q-how-to-talk-to-users) - [The Mom Test](https://www.momtestbook.com/) - [Paul Graham, Do Things that Don't Scale](https://www.paulgraham.com/ds.html) - [ZeroRaised: how to validate a SaaS idea](https://zeroraised.com/blog/how-to-validate-a-saas-idea-before-building) - [ZeroRaised: how to find early adopters](https://zeroraised.com/blog/how-to-find-early-adopters) ## Frequently asked questions ### How many customer discovery interviews do I need? There is no universal number. Start with five to ten interviews in a narrow segment and look for repeated problems, workarounds and objections. Stop when additional conversations stop producing new themes. ### Should I pay people for interviews? A small incentive can be appropriate when you are asking for significant time, especially for busy professionals. It should not be so large that it distorts the feedback. Check the rules of any community or platform you use to recruit. ### Can I interview friends and family? Only if they genuinely have the problem and can speak from experience. Friends who are being supportive will often tell you what you want to hear, which makes their feedback unreliable for product decisions. ### Should I show a prototype during the interview? You can show a prototype after you have understood the problem, but keep the discussion about their workflow and the result they need. A prototype can anchor the conversation and hide problems you would otherwise discover. ### What should I do with the interview notes? Tag each note by theme, record exact phrases where possible and compare the themes across interviews. Use the evidence to decide what to build, what to test and what to stop assuming.