Customer Interviews Without Turning Them Into a Research Project

Most founders know they should talk to customers. The problem is that “talk to customers” quickly becomes another project: recruit people, write a research script, schedule calls, record everything, transcribe it, tag every sentence, and eventually discover that the team learned one obvious thing.

You can get useful evidence with a much smaller loop.

For an indie SaaS or early-stage product, the goal of an interview is usually not statistical confidence. It is to understand a specific behavior well enough to make a better product decision.

That changes how you run the conversation.

Start with one decision

Do not open your calendar with a vague goal such as “learn about our customers.”

Pick one decision that is currently expensive or uncertain.

Examples:

• Should onboarding ask for more information or less?
• Is the reporting page actually used after the first week?
• Why do trial users stop before inviting a teammate?
• Are customers buying the product for the feature you think they are buying?
• Is a missing integration blocking deals, or is it simply something users mention?

A good interview question sits behind a real decision.

If there is no decision, interviews tend to become conversations that feel productive but do not change anything.

Ask about the last real event

The strongest answers usually come from something that actually happened.

Instead of asking:

Would you use an automatic weekly report?

Ask:

Tell me about the last time you needed to prepare that report. What did you do?

The difference matters.

Future-looking questions invite polite guesses. Recent behavior gives you details: the tools the person opened, the workaround they used, how long the task took, who was involved, and what made the task frustrating.

When someone says, “I would definitely use that,” keep going.

Ask:

• When did you last have this problem?
• What did you use instead?
• How often does it happen?
• What happens if you do nothing?
• Who else is involved?
• What part takes the most time?

You are looking for behavior, not compliments.

Separate the problem from the requested feature

Customers are often good at describing their frustration and less reliable at designing the solution.

A customer may request a CSV export. The actual problem might be that they need to send a weekly status update to a manager.

Those are different product decisions.

Write down both:

Observed problem: The customer spends 20 minutes every Friday collecting numbers for a status update.

Requested solution: Add a CSV export.

The first statement describes the job. The second describes one possible implementation.

Keeping them separate prevents the interview from becoming a feature voting exercise.

Capture exact language

Save short phrases customers actually use.

If three different people describe a workflow as “the Friday scramble,” that phrase may be more useful than a page of abstract research notes.

Customer language can improve:

• onboarding copy
• pricing explanations
• empty states
• help documentation
• feature names
• sales pages
• product positioning

Do not manufacture a quote from a summary. If you publish customer words, preserve the meaning and obtain whatever permission your publishing process requires.

Look for repeated friction

One interview can reveal a surprise. Several interviews can reveal a pattern.

Create a simple table after each conversation:

The frequency column is not a scientific prevalence estimate. It is a decision aid.

Five interviews do not prove that 80% of your market has a problem.

They do tell you that the same problem appeared repeatedly in the conversations you conducted.

Do not confuse enthusiasm with urgency

A customer can love an idea and still never pay for it.

Pay attention to cost.

Useful signals include:

• time already spent on the problem
• money spent on workarounds
• people involved in the workflow
• frequency of the task
• consequences when the task fails
• whether the customer has already searched for another solution

A painful problem usually leaves evidence somewhere.

If the only evidence is “that sounds cool,” label it accordingly.

End every interview with one concrete question

A useful closing question is:

If we solved this problem next month, what would change for you?

The answer often reveals the outcome the customer actually values.

Another useful question is:

What would make you trust this enough to use it in your normal workflow?

That can uncover adoption barriers that a feature request misses.

Turn interviews into product decisions

The interview is not finished when the call ends.

Spend five minutes writing:

1. What happened?
2. What surprised us?
3. What repeated?
4. What did the customer already do to solve it?
5. What decision does this evidence affect?
6. What would we need to observe next?

Then attach the note to the relevant product decision.

Over time, this creates a decision history instead of a pile of transcripts.

A simple weekly interview loop

For a small team, one or two conversations a week can be enough to maintain contact with real users.

A practical loop looks like this:

Monday: choose one product question.

Tuesday–Thursday: conduct one or two short interviews.

Friday: compare observations and decide whether the evidence changes the roadmap.

The important part is continuity.

You are not trying to run a research department. You are creating a feedback channel between the product and the people using it.

What makes an interview useful?

A useful interview produces evidence about behavior, context, and consequences.

It does not need perfect methodology. It needs a clear question, recent examples, careful listening, and a documented decision afterward.

For an indie founder, that is often enough to replace a week of speculation with a much smaller amount of real customer evidence.

Quick checklist

Before the next interview, ask:

• What decision am I trying to make?
• What recent event do I want the customer to describe?
• Am I asking about behavior instead of hypothetical preferences?
• Can I separate the problem from the requested feature?
• What exact language should I preserve?
• What evidence would change my mind?

If you can answer those six questions, the interview is already doing useful work.