A practical interview guide for replacing opinions and hypothetical praise with specific past behavior, constraints, alternatives, and next-step evidence.
Good interviews reconstruct a real episode
A customer interview is not a polite referendum on your idea. Its job is to reconstruct what happened before, during, and after a real problem. When founders ask whether someone “would use” a product, the conversation rewards imagination and kindness. When they ask about the last time the problem occurred, the answer has dates, tools, people, delays, tradeoffs, and consequences.
Start with one recent episode. You are looking for evidence that helps a decision: which segment feels the problem most sharply, which trigger begins the search, what workaround already exists, and what would have to change before the buyer acts.
The most useful answer describes something the customer already did, not something they might do for you.
Use a sequence that follows the customer’s timeline
- Open with the last occurrence. Ask: “Tell me about the last time this happened.” If the answer stays general, ask where they were, what triggered it, and what happened next.
- Reconstruct the old workflow. Ask which tools, documents, people, and manual steps were involved. A workaround reveals the job more clearly than a feature request.
- Find the cost in the customer’s terms. Ask what was delayed, repeated, lost, or made risky. Do not convert every inconvenience into money if the customer experiences it as time, confidence, or coordination.
- Trace the search for alternatives. Ask what they tried, why they chose it, what nearly worked, and why they stopped. This exposes real decision criteria.
- End with a natural next step. Ask what they expect to do the next time the trigger appears. A calendar commitment, introduction, data sample, or trial is stronger evidence than praise.
Capture evidence, not a transcript-shaped archive
After each interview, write a short evidence card while the context is fresh:
- Customer and role, without unnecessary personal detail.
- Triggering event and the job they needed to complete.
- Current workaround, including the part they refuse to change.
- Cost or consequence in the customer’s own language.
- Alternatives considered and the reason each was accepted or rejected.
- Observable next step, unanswered question, and confidence level.
Questions that quietly damage the interview
“Would you use this?” It asks the customer to predict a future with too little friction. Replace it with what they did last time and what they have already committed.
“Do you like this feature?” It makes your solution the center of the conversation. First understand the job and constraints; show a solution only when you know what it must prove.
“How much would you pay?” too early. Price without a real buying situation becomes theatre. First learn what budget, authority, alternative, and urgency existed in the last decision.
Interviewing only friendly users. Supporters are useful, but they can hide rejection reasons. Include people who stopped, chose another option, or never completed activation.
Connect interviews to public evidence without merging them
Private interviews explain a few cases deeply; public discussions reveal whether similar situations recur across people and time. SeeVoid can help surface source-linked community signals that you compare with interview notes. Do not treat a public post as consent to contact its author, and do not let an AI cluster replace the original context.
A ten-minute debrief is part of the interview
Before the next call, write one sentence for what changed: a segment assumption, a trigger, a rejected alternative, a product risk, or the next experiment. If nothing changed after several interviews, the question may be too broad or the participants may be too similar. A good interview does not merely make the founder feel informed; it narrows the next decision.
For a broader distinction between existing-source research and direct customer research, see the U.S. Small Business Administration’s market research guide.