Run user interviews that surface past behavior instead of polite predictions, recruited and synthesized honestly. Use when gathering qualitative evidence for product decisions.
Installs into .claude/skills of the current project.
Are you the author of Customer Interviews?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/amey-thakur-customer-interviews)
---
name: customer-interviews
description: Run user interviews that surface past behavior instead of polite predictions, recruited and synthesized honestly. Use when gathering qualitative evidence for product decisions.
---
# Customer interviews
People are terrible at predicting their behavior and excellent at
being polite. Interviews extract truth only when they ask about the
past, chase specifics, and never pitch: the mom-test discipline.
## Method
1. **Ask about the past, never the hypothetical.** "Walk me
through the last time you handled X" beats "would you use a
tool that does X" every time: the second question harvests
compliments. Chase the specifics: when, what did you do
next, what did it cost, who else was involved, what did you
try before (the workaround hunt: see product-discovery
step 3).
2. **Never pitch in a learning interview.** The moment you
describe your solution, every answer becomes a kindness.
Keep solution demos in separate usability/feedback sessions
with their own rules; a learning interview about the
problem space mentions your product last or never.
3. **Recruit for the segment, screen hard.** Define who has
the problem (role, context, recent behavior: "managed a
team budget in the last 90 days"), screen with behavioral
questions, and pay fairly. Five to eight interviews per
segment surfaces the pattern; friends, fans, and whoever
answers fastest produce warm noise (see
product-discovery's evidence grades). In B2B, interview
buyer, user, and admin separately: they disagree in
load-bearing ways.
4. **Run it as listening with a spine.** A discussion guide of
topics (not a script), open questions, then silence: let
them fill it. Follow surprise: "say more about that"
outperforms your next planned question. Capture verbatim
quotes (record with consent); your paraphrase already
contains your bias.
5. **Synthesize across interviews, tagged to evidence.**
Within 24 hours per interview: key quotes, observed
behaviors, pains with frequency/severity. Across the set:
cluster into themes with counts ("6 of 8 rebuilt the
report manually each month"), separating observations from
interpretations (see research-synthesis for the general
method). Themes feed the opportunity map (see
product-discovery) and experiment designs (see
ab-test-design for what quals cannot answer).
6. **Close the loop into decisions.** Each round ends with:
what we believed, what we heard, what changes (a killed
assumption, a re-ranked opportunity, a new experiment):
recorded (see decision-journals). Interviews that end in
a slide deck nobody acts on teach the org that talking
to users is decoration.
## Boundaries
- Interviews establish existence and texture of problems,
not market size or preference shares; pair with behavioral
data and experiments for magnitudes (see product-metrics,
ab-test-design).
- What people say they do and what logs show diverge; when
they conflict, logs win on frequency, interviews win on
why.
- Usability testing (can they operate the interface) is a
different protocol with tasks and think-aloud; do not mix
it into discovery interviews and call both "research"
(see accessibility-review and design-critique for
adjacent lenses).