Guides / Ideas and launching

How to Do Customer Interviews That Tell You the Truth

How to run customer interviews: finding people, questions that get honest answers, what to avoid, taking notes, and turning conversations into decisions.

Mythex Team · 2026-09-29 · 6 min read

A good customer interview is a conversation about the other person's real, recent experience with a problem — not a pitch and not a request for their opinion of your idea. Ask about the last time something happened, what they did, what it cost them and what they've tried. Listen far more than you talk, write down their exact words, and look for patterns across several interviews before you decide anything.

Interviews are cheap, fast and tell you more than almost any other early research. They're also easy to get wrong, because people are kind and will tell you what they think you want to hear.

What customer interviews are for

There are two main kinds, and mixing them up causes most bad interviews.

Most founders jump to the second too early. If you show a solution before you understand the problem, people react to your design instead of telling you about their life.

Step 1: Decide what you need to learn

Write down the two or three assumptions you are least sure about. For example:

• Clinic managers spend significant time rescheduling appointments by phone.
• They already pay for a booking tool but are unhappy with it.
• The owner, not the manager, decides what software to buy.

Each interview should help confirm or reject these. If you can't say what you're testing, the conversation will drift into friendly chat.

Step 2: Find the right people

Talk to people who match your target customer as closely as possible. Good places to find them:

• Your network: ask for introductions to people in a specific role, not "anyone who might be interested".
• Communities: industry forums, subreddits, LinkedIn groups, local business associations.
• Your waitlist or sign-ups: people who already raised their hand.
• Cold outreach: a short, honest message usually works when the topic is their problem.

A request that gets replies:

Hi [name] — I'm researching how [role]s handle [problem]. I'm not selling anything; I'd just like to hear how you do it today. Would you have 15–20 minutes for a call this week?

Only say you're not selling if it's true.

Screen before booking: one or two quick questions confirm they actually have the problem. Talking to the wrong people produces confident, wrong conclusions.

Step 3: Prepare a short script

You won't follow it word for word, but it keeps you on track. A problem-interview script:

Opening (2 minutes)

• Thank them, say how long it will take, and explain there are no wrong answers.
• Ask permission if you want to record.

Context (5 minutes)

• "Tell me about your role. What does a normal week look like?"
• "Where does [problem area] fit into that?"

The last time it happened (10–15 minutes)

• "Tell me about the last time you had to [task]. Walk me through it."
• "What did you do first? Then what?"
• "What tools or people were involved?"
• "What was the hardest or most annoying part?"
• "How long did that take? How often does it happen?"

What they've tried (5 minutes)

• "Have you looked for a better way to do this?"
• "What have you tried? Why did you stop, or why do you keep using it?"
• "Do you pay for anything related to this today?"

Wrap-up (2 minutes)

• "Is there anything I should have asked but didn't?"
• "Who else should I talk to about this?"
• "Can I follow up if I build something?"

Questions to avoid

Some questions reliably produce useless answers.

The pattern: ask about specific past events, not opinions or predictions. The past is what actually happened; the future is what people imagine.

Rob Fitzpatrick's book The Mom Test is a good short read on this style of questioning.

Step 4: Run the interview

A few habits make a big difference:

• Talk less. Aim to speak much less than they do. Silence is fine; people often fill it with the most useful detail.
• Follow the energy. When they get animated or frustrated, ask "Tell me more about that."
• Dig for specifics. "Can you give me an example?" "What happened next?" "Roughly how long?"
• Don't defend your idea. If they say something that contradicts your plan, that's the most valuable moment of the call.
• Don't pitch at the end of a problem interview. If they ask what you're building, give one sentence and offer to follow up.

Step 5: Take notes that you can use

Write notes during the call or right after, while it's fresh. A simple template:

Their exact phrases are gold. When several people describe a problem with the same words, those words become your landing page copy — see how to write a landing page headline.

Step 6: Make sense of the results

After every five or so interviews, review your notes side by side.

• Look for repeats. Which pains came up without prompting, from several people?
• Separate strong from weak signals. "That's annoying" is weak. "I spend every Monday morning on this and I've tried three tools" is strong.
• Look at commitments. Did anyone offer an introduction, ask to be a beta user, or offer to pay? Actions count more than words.
• Update your assumptions. Mark each one confirmed, rejected, or still unclear.

Keep going until the answers stop surprising you. If every interview tells a different story, your audience is probably too broad — narrow it down and continue.

Solution interviews: showing what you've built

Once you have a prototype, the format shifts. Start with the same context questions, then:

1. Give them a realistic task: "Imagine it's Monday and you need to reschedule three patients. Show me how you'd do it here."
2. Watch without helping. Note where they hesitate.
3. Ask: "What did you expect to happen there?" rather than "Did you like it?"
4. End with a concrete ask: a trial, a pilot, a pre-order.

A cheap working prototype makes these interviews much more realistic than slides or mockups.

Common mistakes

• Interviewing only friends and family.
• Pitching instead of listening.
• Asking about the future instead of the past.
• Counting compliments as validation.
• Not writing notes until days later.
• Stopping after two interviews that agreed with you.

Turning interviews into a product

Interviews should shape what you build first: the one job people struggle with most. From there, write a short requirements doc and build the smallest version. With Mythex you can describe that version in chat and have a working web app with a database on a shareable link, ready to use in your next round of solution interviews. The effective prompts guide shows how to turn interview notes into a clear build request. For the full validation process around interviews, see how to validate an app idea.