---
name: customer-interviews
description: Plan, run and synthesise customer discovery interviews that surface how people actually behave, using The Mom Test rules and Teresa Torres's story-based method rather than opinion and hypothetical questions. Carries the real rules: talk about their life not your idea, ask about specific past events not the future, listen for about 80 per cent of the time; open with "tell me about the last time you..."; recruit with a screener instead of qualifying in the interview; run to saturation (stop when two or three interviews in a row add no new pattern, usually after five to eight per segment) rather than hitting an arbitrary count; write one interview snapshot each, tag every quote to a source, and never upgrade a single mention to a pattern. Use it when someone says talk to users, run discovery or customer interviews, write an interview guide or screener, what should I ask, or synthesise these interview notes. Do NOT use it to choose which problem to build (see opportunity-solution-trees), to model the underlying job and forces of a purchase (see jobs-to-be-done), or to run a usability test of an existing design.
licence: CC BY 4.0. Free to use and adapt with credit to Afeez Adebayo, linking afeezadebayo.com, https://www.linkedin.com/in/afeez-adebayo/ and the skill's download page at https://afeezadebayo.com/skills-md/product-management/product-discovery/customer-interviews/.
---

# Customer interviews

A customer interview exists to learn how someone actually behaves, not to collect opinions about your idea. People are generous with encouragement and poor at predicting their own future, so an interview that asks what they think or what they would do returns comfortable answers that feel like progress and teach you nothing. A good interview stays in the past, stays specific, and lets the person talk while you listen.

This skill makes an AI agent plan a round of interviews, write a screener and an interview guide, run or coach the conversation, and synthesise the notes into findings that trace back to real quotes. It uses two sources that agree with each other: Rob Fitzpatrick's The Mom Test, for keeping questions honest, and Teresa Torres's story-based interviewing, for grounding every answer in a specific past event. It decides what to ask and how to make sense of the answers. It does not choose which customer problem to pursue; that is the opportunity-solution-trees skill. It does not model the job a customer is hiring the product to do, or the forces behind a switch; that is the jobs-to-be-done skill. Interviews feed both.

## When to use this skill, and when not to

Use it when someone needs to understand a customer's behaviour, context, pains or desires before deciding what to build, when they ask to talk to users, run discovery, write an interview guide or a screener, work out what to ask, or turn a pile of interview notes into something they can act on. Use it for generative interviews in the problem space, and for churned-customer and win-loss conversations where you want the real story of a decision.

Do not use it to pick which problem is worth solving from the evidence; that is opportunity-solution-trees. Do not use it to reconstruct why a customer bought or left through the four forces of progress, or to write a job statement; that is the jobs-to-be-done skill, and this one hands off to it when the question is about a purchase or a switch. Do not use it to test whether an existing design is usable; that is a usability test, which watches someone attempt a task rather than asking about their life. And do not run interviews at all when no decision hangs on the answer. If the finding would not change what the team does next, the interview is theatre; say so and suggest the decision to frame first.

## What the agent needs from you before starting

Ask for these before writing a single question. Do not proceed on assumptions.

1. The decision this research will inform. What will the team do differently depending on what they hear? If there is no decision, stop and find one first.
2. The research question behind it, in plain words, for example "how do operations leads handle a late shipment today?" One or two questions, not ten.
3. The target segment, described tightly enough to recognise one person and to screen for them. "Operations lead at a logistics firm with 10 to 50 staff who has dealt with a late shipment in the last month" is usable; "businesses" is not.
4. How you will reach them, and what you can offer for their time. Existing users, a waiting list, a panel, a community, sales contacts, or a recruiter.
5. What already exists to work with: past interview notes or transcripts to synthesise, support tickets, survey verbatims, or product analytics. If you are being asked to synthesise, you need the raw notes, not a summary.
6. Any constraints: a deadline, how many conversations are realistic, B2B stakeholders who must each be heard, or privacy limits on recording.

If the decision or the segment is missing, stop and ask. Do not invent a persona, a quote or a number to fill the gap.

## How to run a round of customer interviews, step by step

Follow these in order. The thresholds are deliberate; they are what keep the round honest and stop it running forever.

### Step 1. Frame the decision, then the question

Write the decision first, then the one or two questions that would move it. Keep the questions about behaviour and context, never about your solution. If the only questions you can write are about a feature you already plan to build, you want a usability test or an assumption test, not a generative interview. Say so and stop.

### Step 2. Choose the conversation type

Match the type to the question. For how a person experiences a problem today, run a generative, story-based interview (this skill). For why someone bought, switched or churned, run a switch interview and hand to the jobs-to-be-done skill, which carries the four forces and the purchase timeline. For whether a design is usable, run a usability test instead. If the question mixes these, run them as separate conversations; a single session that tries to be all three gets shallow answers to each.

### Step 3. Write a screener and recruit the right people

Recruit with a screener, not by qualifying people live in the interview. Screen on behaviour, not opinion: "In the last month, how many times have you dealt with a late shipment?" sorts better than "Are you interested in logistics software?" Keep the segment narrow. If twenty conversations return twenty unrelated answers, the segment was too broad; split it and re-screen. In B2B, map the buying group and plan to hear the budget owner and the day-to-day user, because the person who feels the pain is often not the person who pays. Recruiting, sending invitations, and paying incentives commit money and reach real people: draft the screener, the invitation and the incentive, and put them to a human to send rather than contacting anyone yourself.

### Step 4. Decide how many, by saturation not by a fixed number

Treat interviewing as a continuing habit rather than a one-off project; a weekly touchpoint with one or two customers beats a single burst every quarter, because the feedback loop stays warm. For a bounded round, run to saturation: stop when two or three interviews in a row surface no new pattern. For a single, well-defined segment that point usually arrives after about five to eight interviews; a study spanning several segments needs that many per segment, so the total climbs. The often-quoted range of roughly seven to fourteen is a sanity check, a floor below which you have too little and a ceiling past which one segment gives diminishing returns, not a target to hit. Never report a pattern from a single interview; a theme needs at least two or three independent sources before it counts.

### Step 5. Write the guide with honest questions

Build a short guide, not a questionnaire, around three or four areas you want stories about. Apply The Mom Test rules to every question: talk about their life instead of your idea; ask about specific events in the past instead of opinions or the future; plan to talk less and listen more, aiming for roughly an 80 to 20 split in their favour. Open each area with a story prompt: "Tell me about the last time you [did the thing]", not "Tell me about your experience with [thing]", because the second invites a tidy generalisation. Run each drafted question through three checks and rewrite any that fail: does it ask about something that actually happened; could the person answer it without guessing about the future; does it avoid naming or hinting at your solution? Replace "Would you use a tool that did X?" with "Walk me through how you did X last time, step by step." Keep a few neutral probes ready: "tell me more about that", "what happened next", and "why?" asked gently two or three times to reach the cause.

### Step 6. Run the interview

Get explicit consent before recording, and say how the recording will be used. Open warm and low-key; if it feels like a favour they are doing you, it is too formal. Anchor on a specific recent instance and walk it forward through what actually happened, in order. Let the person do most of the talking. When they drift into generalities ("I usually...", "normally we..."), wait for a natural pause, then guide them back to the specific time. Capture their exact words rather than your paraphrase. Listen for commitment and advancement, the signals that something matters: time spent, reputation risked, or money already paid against the problem. Treat compliments and opinions as noise, not data. Close by asking who else you should talk to.

### Step 7. Write an interview snapshot straight after

Within a day, while it is fresh, write one snapshot per interview: who they were (anonymised), the specific story in their own words with two or three verbatim quotes, what they actually did and what it cost them, the pains and desired outcomes you heard, and any surprise. Tag every quote with a source label such as "Interview 4, Nov 2026". Do not take notes by typing through the conversation; it reads as rude and splits your attention. Share the snapshot with the team the same day so the learning does not sit in one person's head.

### Step 8. Synthesise across interviews

Bring the snapshots together and tag recurring needs, pains and behaviours, then group the tags into themes (an affinity map, or a sortable column per signal). For each theme, keep two columns honest and separate: what the person did (evidence) against what they said they thought or wanted (weaker, and worthless if it was a compliment). Separate pain from pull: a pain tells you a problem exists; pull, a person paying or persisting with a rough workaround, tells you it is worth solving. Count the independent interviews behind each theme and rank by that count and by the strength of the behavioural evidence, not by how loud or recent a single quote was.

### Step 9. Report findings and hand off

Write findings as behaviour-backed statements, each traced to its sources, with the quotes that support it and the count behind it. Mark anything resting on a single interview as unconfirmed. Recommend the next step and hand off by name: to jobs-to-be-done to model a switch or write the job, or to opportunity-solution-trees to pick which of these problems to pursue. The interview round informs the decision; a human still makes it.

## Worked example

Decision: whether to invest in faster onboarding for a logistics tool, framed because activation predicts paid conversion. Research question: how do operations leads get their team set up and running today, and where does it stall?

The agent writes a behavioural screener ("in the last month, have you set up a new tool for your team?"), an invitation, and a small incentive, and hands them to the PM to send. It recruits eight operations leads at firms of 10 to 50 staff.

Guide, three areas, each opened with a story prompt: "Tell me about the last time you rolled out a new tool to your team"; "Walk me through the first week after you signed up for [current tool]"; "Tell me about a time setup went wrong." The agent rewrites a drafted question, "Would you use a guided setup wizard?", into "The last time you set a tool up, what was the first thing you did?", because the original asked about the future and named a solution.

In the interviews the leads talk; the agent redirects generalities back to the specific rollout and records exact phrases. Snapshots capture quotes such as "I set it up at 11pm and my team never saw the invite" (Interview 3) and "I wanted to prove it worked before I pulled anyone else in" (Interviews 1, 4, 6, 8).

Saturation arrives at interview seven: the last two add no new theme. Synthesis surfaces two patterns with behavioural weight: solo leads trial alone before inviting anyone (four independent interviews, backed by what they did), and invitations sent out of hours go unseen (two interviews, one of them a single strong quote, marked lower confidence). The agent reports both with counts and quotes, flags the invite-timing theme as unconfirmed, and hands the problem set to opportunity-solution-trees to choose a target. It does not decide the roadmap itself.

## Templates you can use verbatim

Screener (behavioural):

```
Screen for: <segment in one line>
1. In the last <period>, how many times have you <done the behaviour>?   [exclude 0]
2. Which of these did you do most recently? <list real activities, no "none">
3. What is your role in <the relevant decision>?   [map to buyer / user / blocker]
4. Can you talk for <30-45> minutes and walk through a recent specific example?
Incentive: <amount or equivalent>   Recording: <ask consent in the invite>
```

Interview guide skeleton:

```
Consent + recording ask (verbatim)
Warm-up: one easy question about their role and a recent day
Area 1: "Tell me about the last time you <did X>."  then: tell me more / what happened next / why?
Area 2: "Walk me through <the specific episode>, step by step."
Area 3: "Tell me about a time <X went wrong>."
Close: "What have I not asked that I should? Who else should I talk to?"
```

Interview snapshot (one per interview):

```
Source: Interview <n>, <month year>, <anonymised role/segment>
The specific story: <what happened, in order>
Verbatim quotes: "<exact words>"  x2-3
What they did + what it cost (time / money / reputation):
Pains heard / desired outcomes:
Pull signals (paid, persisted, workaround built):
Surprise:
```

Question fix table (rewrite any question that reads like the left column):

```
Do you think this is a good idea?            -> How do you handle <problem> today?
Would you buy / use a tool that did X?       -> Walk me through the last time you did X.
How much would you pay for X?                -> What does <problem> cost you now, in time or money?
What features do you want?                    -> Where did the last attempt break down?
If you could wave a magic wand, what...?      -> Tell me about the most recent time this annoyed you.
```

## Common mistakes and how to avoid them

1. Pitching the idea or leading the witness. The moment you describe your solution, you are fishing for compliments. Spot it when the transcript has you talking more than the customer, or the customer praising a plan. Fix it by giving as little about your idea as possible and keeping every question about their life.
2. Hypothetical and future questions. "Would you...", "do you think...", "how often do you usually..." all return the idealised self, not the real one. Spot them in the guide before you run it. Fix by converting each to a specific past event, and get frequency from analytics rather than from memory.
3. A segment too broad to learn from. If twenty people give twenty different answers, no pattern can form. Spot it when themes will not cluster. Fix by narrowing the screener to one behaviour and re-recruiting.
4. Treating opinions and compliments as findings. "That sounds great" and "I'd definitely use that" cost the person nothing and carry no data. Spot them when a finding rests on enthusiasm rather than something the person did. Fix by recording only behaviour and commitment, and parking opinions separately.
5. One person's memory, and single-source patterns. Notes trapped in one head, or a theme built from one vivid interview, both mislead. Spot it when a finding cites one source or no source. Fix by writing a shared snapshot within a day and requiring two or three independent interviews before anything is called a pattern.

## Quality bar: check the output against this before handing it over

- A real decision is named that the research will inform; the research question is about behaviour, not about the solution.
- The segment is narrow enough to screen for, and recruiting was done by screener, not by qualifying people in the interview.
- Every guide question asks about a specific past event, avoids the future, and does not name or hint at the solution.
- The round ran to saturation (two or three interviews with no new theme), with the count recorded, not to an arbitrary number.
- Each interview has a snapshot with verbatim quotes tagged to a source, written up and shared.
- Findings separate behaviour from opinion and pain from pull, and each theme shows how many independent interviews support it.
- No quote, participant or number is invented; single-source themes are marked unconfirmed.
- The output recommends a next step and hands off to jobs-to-be-done or opportunity-solution-trees by name rather than deciding the roadmap itself.

## Guardrails

- Irreversible actions need a human. Sending recruiting messages, scheduling, paying incentives and emailing a survey all reach real people or spend money. Draft them and ask for explicit confirmation; never contact participants yourself.
- Never fabricate. If there are no interviews to synthesise, the honest output is "there is nothing to synthesise yet; here is the screener and guide to run first", not invented quotes, personas or percentages.
- Protect personal data. Interview notes and recordings hold names, employers, voices and sometimes commercially sensitive detail. Get consent before recording, refer to people by anonymised labels such as "Interview 4, Nov 2026", and do not paste raw transcripts, names or contact details into prompts or third-party tools. Keep recordings where they already live and delete them when the study is done if you said you would.
- Mind the cost. Interviews cost people's time and sometimes money. Prefer a steady weekly cadence of one or two over a large one-off batch, and stop at saturation rather than running interviews no one will read.
- Stay in scope. This skill plans, runs and synthesises interviews. It does not choose the problem to solve (opportunity-solution-trees) or model the job and the forces of a switch (jobs-to-be-done). Hand off to those skills by name.

## Tool-specific appendix

The method above is tool-agnostic: a screener, a guide, a recording with consent, a snapshot per interview, and an affinity map hold the whole process on paper or in any document. For recruiting panels (User Interviews, Respondent, or similar), screen on behaviour in the panel's own screener and still have a human approve the spend. For transcription and note-takers (Otter, Grain, tl;dv, Fathom, or similar), get consent before the bot joins, and remember the transcript is personal data: keep it in your own store rather than pasting it into a public model. For research repositories (Dovetail, Condens, Notion, or similar), store one snapshot per interview, tag quotes to their source, and build themes from the tags. Whatever the tool, the rules in the steps above do not change; the tool only decides where the notes live and how they are tagged.

## Sources

- Rob Fitzpatrick, The Mom Test (the three rules; opinions and compliments are worthless; commitment currencies of time, reputation and cash; bad questions and their replacements). Last verified 12 November 2026.
- Teresa Torres, "Story-Based Customer Interviews Uncover Much-Needed Context", producttalk.org/2024/04/story-based-customer-interviews (past not future, the "tell me about the last time" opening, recruiting with screeners, redirecting generalisations, at least weekly cadence). Last verified 12 November 2026.
- Teresa Torres, Continuous Discovery Habits (weekly touchpoints by the product trio; the interview snapshot; updating understanding every few interviews). Last verified 12 November 2026.
- Looppanel, "Customer interviews" guide (focused findable segment, twenty answers from twenty people as a breadth signal, B2B buyer versus user, notes after not during, share to avoid a learning bottleneck). Last verified 12 November 2026.
- Pawel Huryn, interview-script PM skill, and refoundai customer-interviews skill, reviewed for structure and gaps (80/20 talk split; the seven-to-fourteen heuristic; pain versus pull). Last verified 12 November 2026.
- BuildBetter, "Agent Skills for Customer Discovery" (evidence before confidence; synthesis must cite specific moments; skills structure the work, they do not conduct the interviews). Last verified 12 November 2026.

---
1.0.0, 12 November 2026: first release. Use, adapt and share this skill under CC BY 4.0: credit Afeez Adebayo, link afeezadebayo.com and the skill's download page. This is decision-support guidance, not a substitute for talking to your own customers.
