Skip to content
Back to skills

Customer Interviews

ASecurity

Run user interviews that surface past behavior instead of polite predictions, recruited and synthesized honestly. Use when gathering qualitative evidence for product decisions.

  • 7 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added September 5, 2026
ai-agentstesting

Security analysis

A100/100

Scanned September 5, 2026

npx -y skills add Amey-Thakur/AI-SKILLS --skill customer-interviews --agent claude-code

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.

Security grade badge for Customer Interviews
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/amey-thakur-customer-interviews/badge)](https://www.skillsdirectory.com/skills/amey-thakur-customer-interviews)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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).

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…