Plans, runs, and synthesizes customer research — interviews, surveys, win-loss analysis, and message testing — into findings that change decisions. Use this when the customer is being guessed at, before positioning or a major launch, when churn or conversion has an unexplained cause, or when a team is arguing from anecdotes. Also use to turn raw interview notes into usable findings.
Scanned 9/1/2026
Install to Claude Code
npx -y skills add cbrock84/headcount --skill customer-research --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Customer Research?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/cbrock84-customer-research)More formats (shields.io, HTML) on the badges page.
---
name: customer-research
description: Plans, runs, and synthesizes customer research — interviews, surveys, win-loss analysis, and message testing — into findings that change decisions. Use this when the customer is being guessed at, before positioning or a major launch, when churn or conversion has an unexplained cause, or when a team is arguing from anecdotes. Also use to turn raw interview notes into usable findings.
---
# Customer research
Research earns its cost only if a decision hangs on it. Name that decision before recruiting anyone.
## Choose the method by question
- **Why did this happen / what do they actually do** — interviews. Small n, deep.
- **How common is this** — survey. Only after interviews have told you what to ask; a survey written
from assumptions returns your assumptions.
- **Why did we win or lose** — win-loss, with losses weighted higher. Losses are where the truth is
and are systematically under-sampled.
- **Which framing works** — message testing against a real choice, not a preference rating.
## Interviewing
Ask about the past, not the future. "What did you do last time" is evidence; "would you use this"
is politeness.
- Open broad, follow the energy, and go quiet after their first answer — the second one is where the
substance is.
- Chase specifics: when, what happened next, what did that cost you, who else was involved.
- Never describe your solution before you have their problem in their words. Once they know what you
want to hear, the interview is over.
- Watch for the workaround. Anything someone has built a spreadsheet to survive is a validated
problem.
## Synthesizing
Code the transcripts before forming a view — findings assembled to support an existing belief will
be. For each finding record: the claim, how many independently said it, a verbatim quote, and what
would change if it is true. A finding that changes nothing is trivia.
Separate what people **said**, what they **did**, and what you **inferred**. Conflating the three is
the most common way research misleads.
## Never
- Recruit only happy customers. The sample that answers your email is not your market.
- Lead: "How much would this feature help?" has one answer.
- Present a single interview as a finding.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!