Founder pack
Claude Skill

First-Customer Interview Loop

Designs the first 10 customer interviews for a new product/segment — questions that produce insight, not validation.

What it does

Helps you design and run the first batch of customer interviews when entering a new segment, validating a new product, or pre-launch. Different from customer-interview-synthesizer (which processes finished interviews) — this is the upstream skill that prevents you from running 10 interviews that all confirm your priors. Forces falsifiable questions, asks about behavior not opinions, and builds in stop-conditions ("if 7/10 say X, pivot").

When to use

  • You're entering a new market segment and want to test if the pain is real
  • You're pre-launch and need to validate the value prop before building
  • You suspect your current customer signal is biased (e.g. only friendly customers will talk to you)

When not to use

  • You already have product-market fit — you need a different research instrument (NPS, retention cohort analysis)
  • You're looking for testimonials, not insight — those are different conversations

Install

Download the .zip, then unzip into your Claude skills folder.

mkdir -p ~/.claude/skills
unzip ~/Downloads/first-customer-interview-loop.zip -d ~/.claude/skills/

# Restart Claude Code session.
# Skill is now available — Claude will use it when relevant.

SKILL.md

SKILL.md
---
name: first-customer-interview-loop
description: Use when designing customer interviews to validate a new product, segment, or hypothesis. Triggers on "customer interview", "validate this", "talk to customers", or "user research" in the pre-PMF context.
---

# First-Customer Interview Loop

The point of these interviews is to get *disconfirming* evidence, not validation. Most founder interviews fail because they ask questions that bias the respondent toward agreement. This skill produces interview designs that make it possible — even likely — to discover you're wrong.

## Required inputs

1. **The hypothesis** — what you believe is true that needs testing
2. **The target buyer / user** — specific enough that you could list 50 of them by name
3. **The decision the research feeds** — if you learn X, you'll do Y. If you don't, you'll do Z.
4. **How many interviews** — 10 is the working batch size; smaller can't see patterns, larger is wasteful before iteration

If "the decision the research feeds" is fuzzy, the interviews will be fuzzy. Force clarity here first.

## The design

### 1. The disqualifying hypothesis
The single statement that, if 7+/10 respondents disagree with it, kills the plan.

Most founders skip this. Don't. Without it, you'll interview 10 people, hear nuance, and keep going anyway.

### 2. The questions, in three layers

**Layer 1: Their world (5 min)**
- "Walk me through how you currently [do the thing the product would help with]."
- "When did you last [do this]? Tell me about that specific time."
- "What part of [this] do you find most frustrating?"

These produce concrete narrative, not abstractions. **Never** ask "would you" / "could you" / "do you think you might" — those generate hypotheticals, not data.

**Layer 2: The pain (10 min)**
- "What do you do when [pain]? What workaround have you built?"
- "How much time / money does [pain] cost you in a typical month?"
- "What have you tried that didn't work? Why didn't it?"

Quantify the pain. If they can't quantify it, the pain isn't big enough to support a product.

**Layer 3: The reaction (5 min, optional)**
Only if Layers 1–2 surfaced real pain.
- "If [your solution] existed, how would you find it?"
- "Who would have to approve buying it? What's their concern?"
- "What would have to be true for you to switch from your current workaround?"

Notice: NO "would you buy this?" That's the worst question in research. It produces enthusiastic yeses that never convert.

### 3. Stop conditions

Write these BEFORE running the interviews:
- "If 7+/10 say [X], we pivot to [Y]."
- "If <3/10 mention [pain] without me prompting, the pain isn't real."
- "If 0/10 have a current workaround, the problem isn't pressing."

Otherwise you'll find a way to interpret any data as supporting the plan.

### 4. Recruitment that doesn't bias

- Don't interview friends, advisors, or existing customers — they're biased to please you
- Do interview people you found via cold outreach, ICP-matched LinkedIn searches, or paid recruitment ($50–150 per qualified interview is normal)
- Don't tell them what you're building until Layer 3 — describing the solution biases everything earlier

### 5. The synthesis loop

After every 3 interviews:
- What pattern is emerging?
- What pattern am I HOPING is emerging?
- Are those the same? (If yes, suspect confirmation bias.)

After all 10:
- Quantify. Of 10, how many had the pain, the workaround, the budget, the buying authority?
- The number is the answer. Don't anecdote your way to a different one.

## Output

```
## Interview design
- Hypothesis being tested: ...
- Disqualifying hypothesis: ...
- Decision this research feeds: ...
- N = 10, recruitment plan: ...

## Question script
[Layer 1, Layer 2, Layer 3 with timing]

## Stop conditions
- ...
- ...

## Synthesis template
[A short form you'll fill in after every 3 interviews]
```

## Anti-patterns

- "Would you use this?" — banned
- "Do you think other people might want this?" — they don't know
- "What features would you want?" — they don't know that either
- Pitching the product in the first 20 minutes — it kills the data
- Interviewing only people who responded enthusiastically to outreach — they're the friendly tail, not the buyer

## Tone

- Curious, not selling
- Quantitative when possible — "how much," "how often," "how many"
- Willing to hear the disconfirming answer and not argue with it

Example prompts

Once installed, try these prompts in Claude:

  • Design 10 first-customer interviews for our new compliance product. Target buyer: [details]. Hypothesis: [details].
  • I've done 5 of these interviews. Help me redesign the questions for the next 5 so I stop just hearing validation. [paste notes]