A useful startup customer interview asks about a real recent situation, observes the user's current workflow, tests the product through screen sharing, and records evidence, uncertainty, and the next decision in a consistent evidence card.
In an early-stage startup, the goal of a customer interview is not to collect compliments. It is to reduce uncertainty around a decision. On November 7 and 8, 2026, I taught teams to move from a friendly conversation to a repeatable evidence loop: observe a real workflow, record what happened, and review every five interviews before changing the roadmap.
| Interview section | Time | What to learn | Output |
|---|---|---|---|
| Context | 5 min | Role, situation, and trigger | Segment note |
| Last real event | 10 min | What actually happened | Behavior timeline |
| Screen-shared workflow | 10 min | Friction and workarounds | Observation notes |
| Evidence review | 5 min | Commitment, contradiction, next step | Evidence card |
What should a startup learn from a customer interview?
A customer interview should help answer one decision-sized question. Examples include whether a specific segment experiences the problem frequently, whether the current workaround is costly, where activation fails, or whether a proposed pilot is worth running.
Choose the decision before the call. Write it as: “After five interviews, we need to decide whether to ___ for ___ users.” This prevents the conversation from becoming a broad tour of every possible feature.
The strongest signals concern real behavior:
- a recent event the person can reconstruct;
- an existing workaround they already use;
- time, money, or political capital already spent;
- a repeated failure in the current workflow;
- willingness to share data, introduce a colleague, run a pilot, or pay.
Interest is not the same as commitment. “That sounds useful” is weak evidence. “I can connect you to the person who owns this process on Thursday” is a stronger next-step signal, but it still needs to happen before you count it.
What is the 30-minute customer interview script?
1. Set the boundary in the first minute
Explain that you are learning, not selling. Ask permission to take notes or record. State how the material will be used and whether quotes will be anonymized. Never turn a private conversation into public marketing evidence without permission.
Opening:
I am trying to understand how you handle [specific job] today. I am not testing you, and I would rather hear what is difficult or irrelevant than receive polite feedback.
2. Reconstruct the last real event
Ask for the most recent time the problem occurred:
- What triggered the task?
- What happened first?
- Which people and tools were involved?
- Where did the process slow down or fail?
- What did you do instead?
- What was the consequence?
Keep returning to concrete details. If the answer becomes general, ask, “Can you walk me through the last time?” Past behavior is more useful than a prediction about a hypothetical feature.
3. Observe the current workflow
For a web or app product, ask the participant to share their screen and complete the relevant task using their normal process. Do not lead them toward the button you want them to click. Watch where they pause, what they ignore, which external tools they open, and what language they use.
This is especially important when teams say users “do not understand” a feature. The failure may be positioning, onboarding, permission design, missing data, trust, or a job the product does not actually solve. Observation helps separate those causes.
4. Ask disconfirming questions
Do not only collect evidence that supports the idea. Ask:
- When is this problem not important?
- Who would never use this process?
- What would make you keep the current workaround?
- What is the strongest reason not to try the product?
- Which part of our assumption is wrong?
Disconfirming questions protect a team from turning five friendly calls into false confidence.
5. Close with one observable next step
Offer a specific next step that matches the evidence: a second workflow test, a small pilot, a data import, a team introduction, or a paid trial. Do not pressure the participant. Record the commitment only when the action occurs.
How do you use the customer interview evidence card?
Copy one card for each interview. Keep observation and interpretation in separate fields.
| Field | What to record |
|---|---|
| Interview ID and date | Stable reference, not a public identity |
| Segment and role | Only details needed for the decision |
| Trigger | The event that started the job |
| Current workflow | Steps, people, and tools observed |
| Friction | Specific delay, error, cost, or workaround |
| Desired outcome | What “done” means in the user’s language |
| Existing alternative | Product, spreadsheet, service, or manual process |
| Commitment signal | Time, data, introduction, pilot, or payment actually given |
| Contradictory evidence | What weakens the current hypothesis |
| Source | Recording, timestamp, screenshot, or notes—with consent |
| Confidence | High, medium, or low, with a reason |
| Decision affected | Positioning, onboarding, roadmap, pricing, or segment |
Do not paste sensitive customer data into an AI tool by default. Redact names, emails, commercial terms, health data, account identifiers, and third-party information unless you have a lawful and approved reason to process it.
How do you distinguish a product problem from an interview problem?
After a call, classify the observed failure before proposing a feature.
| Failure type | Evidence pattern | Next test |
|---|---|---|
| Positioning | User expected a different outcome | Test a clearer promise with the same product |
| Activation | User wants the outcome but cannot reach first value | Observe onboarding with no coaching |
| Workflow fit | Product adds steps or breaks an existing process | Prototype an integration or narrower job |
| Trust | User will not share data or rely on the result | Test proof, controls, and explainability |
| Priority | Problem is real but infrequent or low-cost | Compare a higher-frequency segment |
| Commercial | Value exists but buyer, budget, or package is unclear | Interview the economic buyer and test a pilot |
One interview can reveal a failure. It cannot establish prevalence. Use the classification to decide what to observe next.
How should a team review every five interviews?
A batch of five is a practical review rhythm, not a statistical law. Put the cards side by side and ask:
- Which behaviors repeated in the same segment?
- Which statements were contradicted by observed behavior?
- Which friction was frequent and costly?
- Which users made an observable commitment?
- Which evidence came from a different segment and should not be merged?
- What would disprove the leading hypothesis in the next batch?
End the review with one of four decisions: continue the same inquiry, narrow the segment, run a product experiment, or stop the hypothesis. Do not translate every comment into a roadmap item.
What evidence is strong enough for a pilot?
A pilot is justified when the problem, user, and next action are specific enough to test. Look for a combination of repeated behavior and real commitment rather than a fixed interview count.
| Signal | Weak version | Stronger version |
|---|---|---|
| Problem | “This is annoying” | Repeated delay with a named consequence |
| Alternative | “We use spreadsheets” | Screen-shared workaround maintained weekly |
| Urgency | “Maybe next quarter” | Owner and decision date identified |
| Access | “I can ask my team” | Introduction or data access completed |
| Payment | “We might pay” | Paid discovery, deposit, or approved pilot budget |
The workshop examples that motivated this template are first-party teaching material, not a promise that a certain number of interviews will produce a conversion rate. Quality depends on segment fit, evidence, and what the team does with it.
For additional primary guidance, Y Combinator’s startup library includes material on talking to users and building product. For the full evidence-to-decision workflow, use the Gingiris user-interview skill.
If your team has interview notes but no shared decision system, review the current advisory options. The useful deliverable is not a transcript archive; it is an evidence-backed next test.
Frequently asked questions
What questions should a startup ask in a customer interview?
Ask about the user's last real attempt, current workflow, alternatives, trigger, desired outcome, friction, switching cost, and what they have already spent in time or money. Avoid asking whether they like an imagined feature.
How long should a customer interview be?
Thirty minutes is usually enough for one focused workflow: five minutes of context, ten minutes on the last real event, ten minutes of screen-shared observation, and five minutes for evidence review and next steps.
How many customer interviews does a startup need?
Use batches of five as a decision checkpoint, not as a universal sample-size rule. After each batch, compare repeated behavior, contradictions, and segment differences before deciding whether to continue, narrow, or test.
How do you avoid biased customer interview answers?
Ask about past behavior instead of future intention, request concrete examples, observe the existing workflow, look for disconfirming evidence, and keep observation separate from interpretation.
What is a customer interview evidence card?
It is a compact record of the user context, trigger, current workflow, observed friction, existing workaround, commitment signal, contradictory evidence, source link, confidence, and the product decision affected.