Customer interviews are useful when they reveal how somebody already works, what gets in the way, and what happens when the problem is left unresolved. They become less useful when the founder spends the conversation explaining an idea and collecting polite agreement. The distinction is easy to understand and surprisingly easy to lose in practice.

This guide offers a practical interview structure for an early-stage startup. It uses a hypothetical scheduling service for independent tutors, not a real customer study. The scripts and exercises are suggestions for organizing research. They do not turn a small sample of conversations into proof of demand or a prediction of sales.

Choose the decision before writing questions

Begin with a decision you need to make. The tutor-scheduling founder might be choosing whether to address cancellations, payment reminders, or finding available lesson times. Each possibility involves a different workflow. Asking vaguely about “running your business” could produce interesting stories without helping choose among them.

Write the current belief and the uncertainty beside each other. For example: “I believe last-minute rescheduling takes substantial time; I do not know how tutors currently handle it.” This framing makes it possible for an interview to disconfirm the idea. A question designed only to uncover supporting examples will not do that job.

Do not try to resolve every business question in one call. The startup podcast track separates early customer learning from later decisions about growth. Use interviews to understand a narrow situation first, then choose another method when the question concerns actual purchasing or sustained product use.

Recruit for relevant experience

Look for people who recently handled the task you want to understand. A tutor who schedules their own lessons can describe that work directly. A tutor employed by a school may have an administrator doing it instead. Both perspectives can be useful, but they should not be treated as interchangeable accounts of the same workflow.

Describe the conversation honestly when inviting participants. Say that you are researching how tutors organize lessons, explain how long the conversation is expected to take, and make clear that participation is optional. Do not disguise a sales pitch as independent research or imply that joining creates an obligation to buy.

If you offer compensation, keep it separate from the content of the answers. People should not need to praise the idea to receive what was promised. Record the recruitment method in your notes so you can later recognize how your sample may differ from the broader customer population.

At the start, explain the topic, how notes will be used, and whether you intend to record. Obtain appropriate permission before recording and follow applicable requirements. Offer a notes-only conversation where practical. Avoid collecting personal details that are not necessary for the research question.

For the tutor example, the scheduling process may involve information about children or other clients. Ask participants to describe the workflow without exposing names, contact details, or private records. A redacted example or a verbal reconstruction can often answer the question without collecting sensitive material.

Give the participant permission to decline a question or stop. This is both respectful and operationally useful: the objective is to understand the task, not to obtain every possible detail. Set a time boundary and leave room at the end for anything important that your prepared questions missed.

Reconstruct one recent event

A recent scheduling event

Start with a concrete prompt: “Tell me about the last time you needed to move a lesson.” Then follow the sequence. What triggered the change? Who contacted whom? Which calendar or message thread was used? What happened when the other person did not respond?

Let the participant finish before offering an interpretation. When they describe a confusing step, ask them to explain what they did next. A founder may hear an inefficient process and immediately propose automation, while the participant may see that same step as a useful personal check.

Ask for specifics without turning the conversation into an interrogation. “How did you notice that?” often reveals more than “Why didn't you use another app?” The second question can sound like criticism and may push the participant to justify a choice instead of describing what actually happened.

Explore consequences and existing workarounds

After understanding the sequence, ask what the event changed. Did it take time away from another task? Did a lesson remain unbooked? Was the inconvenience minor enough to ignore? Do not translate every mention of frustration into a major commercial opportunity.

Ask what the person has tried before and what happened. A spreadsheet, recurring message, assistant, or scheduling platform may already solve most of the issue. Find out what they kept, abandoned, or changed. The reasons may reveal switching costs, preferences, or limitations that your first idea overlooked.

Y Combinator's Startup School video collection includes a dedicated session on talking to users, alongside material on first customers and product development. It is a useful primary educational starting point. The interview structure in this guide is an independent practical exercise, not a transcript of that session.

Keep a product demonstration separate

If you want feedback on a concept, label the transition clearly after the research conversation. “I would now like to show a rough idea and hear what you understand” is different from implying that the concept is already proven. Record demonstration feedback separately from evidence about the participant's existing behavior.

Ask the person to explain what they think the concept does. Notice unclear language, missing information, and questions about permissions or responsibility. Avoid defending every detail. A demonstration is useful partly because it exposes differences between the founder's intention and the participant's understanding.

Be careful with promises about future payment. “I would probably buy this” is not the same event as accepting a defined offer, paying, and continuing to use the service. The business idea validation guide describes how to choose a subsequent test for a different uncertainty.

Turn notes into a usable synthesis

After each conversation, write a short account of the situation, the sequence, the consequence, and the alternative used. Keep direct quotations clearly distinguished from paraphrases. Add a separate interpretation section so that your inference does not quietly become something the participant supposedly said.

Group similar observations, but preserve meaningful differences. One tutor may prioritize reducing message exchanges; another may prefer personal messaging because it supports a relationship with families. A single “tutors want automation” summary would erase the disagreement that makes the research useful.

Track contradictions and unanswered questions. Small samples can reveal possible patterns without estimating how common those patterns are. Describe the recruitment limitations and avoid turning a handful of interviews into percentages that appear representative of all tutors, all founders, or an entire country.

Make the next action proportional to the evidence

Suppose several participants can describe recent scheduling problems, but the consequences vary. A reasonable next action might be to narrow the customer group and examine one workflow more closely. It is not automatically a reason to build every feature participants mentioned.

Suppose the problem appears important but the proposed concept is confusing. You might revise the explanation or sample output before writing software. Suppose an existing tool already meets the need. You might investigate a different problem rather than treating the competitor's presence as proof that your version will sell.

Write the decision with its limitation: “We will test a simpler cancellation workflow with self-employed tutors; we have not established pricing or broader demand.” That sentence gives the team direction without overstating what the conversations accomplished. It also makes the next research question visible.

Conclusion: leave room to be surprised

A productive customer interview does not need to end with a compliment about your idea. It should leave you with a clearer account of a real task and the choices surrounding it. Recruit relevant participants, reconstruct recent events, separate demonstrations from research, and preserve disagreement in your notes. The most valuable answer may be the one that changes what you planned to build.