Customer Discovery

You decided this is a product. Now prove it. The only proof that matters is a conversation with someone who is not you.

Have Five Conversations

This is the entire section in one sentence: talk to five real people who might use what you are building, and do it before you write another line of code.

Not friends. Not family. Strangers in your target audience. People who have the problem you think you are solving and are not invested in making you feel good about your idea.

• If you are building for parents — talk to parents at practice, in Facebook groups, at games
• If you are building for small businesses — talk to actual business owners in that industry
• If you are building for a hobby community — go where they hang out online

After each conversation, write down: who they are, what surprised you, and the big question — would they pay for a solution? Not "did they say they would" — did they describe a problem painful enough that money would move?

How to Have the Right Conversations

People are polite. If you describe your idea, they will tell you it is great — even if they would never pay for it. The trick is to never pitch your idea. Instead, ask about their life.

Have Five Conversations

Not fifty. Not one. Five real conversations with people who might actually use what you're building. Not friends or family — they'll be too nice. Find people in your target audience:

• If you're building for parents — talk to parents at practice, in Facebook groups, at games
• If you're building for small businesses — talk to actual business owners in that industry
• If you're building for a hobby community — go where they hang out online

After each conversation, write down: who they are, what surprised you, and the big question — would they pay for a solution? Not "did they say they would" — did they describe a problem painful enough that money would move?

Reading the Signals

After your five conversations, rank what you heard. Strongest to weakest:

1. They already pay for something similar — they have the problem AND they spend money on it. Best signal.
2. They described the pain without you bringing it up — unprompted complaints are gold.
3. They asked when they could try it — they're pulling toward a solution, not being pushed.
4. They said "that's a great idea" — this is politeness, not demand. Worth very little.
5. They said "I'd probably use that" — "probably" means no.

Deciding What to Build First

You've talked to people. The idea has legs. Now: what's the smallest version that tests whether people will pay?

This is NOT a crappy version of the full product. It's the one thing that delivers enough value that someone would hand you money.

One filter before you scope anything: are you building in a domain you actually understand? Not "I read about it" — you've lived in it, worked in it, or spent years as a customer in it. Half the projects in my graveyard died because I was guessing at problems in industries I'd never worked in. The football academy app sounded great until I realized I didn't know what coaches actually needed. Build where you know the terrain. The unfair advantage isn't the AI. It's knowing which problems are real because you've felt them yourself.

For every feature you're considering, ask:

• Would someone refuse to pay without this? If no, leave it out for now.
• Could I do this by hand for the first 10 people? If yes, do that instead of building it.
• Could I add this in a week if people ask for it? If yes, wait until they ask.

Things you almost certainly don't need yet:

• User profiles and settings pages
• Social features (comments, likes, sharing)
• A mobile app (your website works on phones already)
• Email notifications (send them by hand at first)
• A beautiful design (functional beats pretty at this stage)
• Multiple pricing tiers

When to Kill It

This is the section nobody writes because it is not fun. But it is the most important skill: knowing when to stop.

Kill the idea if:

• 3 out of 5 people do not have the problem. Not "they do not like your solution" — they do not even have the problem you are solving.
• Everyone says "cool" but nobody asks when they can try it. Polite interest is not demand.
• You cannot find 5 strangers to talk to. If you cannot find them for a conversation, you will not find them as customers.
• You have been "about to launch" for more than a month. That is avoidance, not preparation.

Killing an idea after 5 conversations and 2 weeks is a win. Killing it after 6 months of building is a loss. The only difference is when you asked the hard questions. For a deeper look at this process, read Ten Conversations and One Decision. And if finding people to talk to is the blocker, Where to Find Your Ten is the operational playbook.

If You Are Stuck, Name the Pattern

You have done the conversations. You know it has legs. But you are still not shipping. That is not a strategy problem — it is a behavior pattern. Most builders who get stuck fall into one of eight traps. Name yours and the fix gets obvious. Take the interactive quiz to find out, or read on. (For the full version with stories and tells, read I Keep Meeting the Same Eight Builders.)

Before you have launched:

After you have launched:

How to Know It's Working

Once people are using your product, ask them: "How would you feel if you could no longer use this?"

• If 4 out of 10 say "very disappointed" — you've built something people need. Keep going.
• If fewer — find out who those "very disappointed" people are. Build for them. Ignore everyone else.

Four Numbers Worth Watching

A simple spreadsheet works until you have 50+ users. After that, free tools can track this automatically — tell your AI "help me set up basic analytics."

Builder's Skills

Drop these into your project and run them anytime. Each one automates a piece of the validation process with the same frameworks from this guide baked in. Save the file to .claude/skills/ in your project, then type the command in Claude Code.

---
description: Run the Builder's Path validation framework on your current idea before writing more code.
---

You are a brutally honest product advisor. The user has an idea they want to build. Your job is to pressure-test it BEFORE they build, not after.

Ask the user to describe their idea in 2-3 sentences. Then run through these checks, one at a time. Do not rush. Wait for their answer to each before moving on.

**Check 1: Who is this for?**
Ask: "Describe the specific person who would use this. Not a demographic. A person. What's their job? What are they doing when this problem hits them?"
If the answer is vague ("anyone who needs..."), push back: "That's everyone, which means it's no one. Get specific. One person."

**Check 2: What are they doing today without you?**
Ask: "How does this person solve this problem right now? Spreadsheet? Manual process? A competitor? Nothing?"
If they don't know, tell them: "You need to find out before you build. Talk to five real people. Not friends. Here's exactly how: https://builderspath.dev/playbook/#customer-discovery"

**Check 3: Would they pay, or just say 'cool'?**
Ask: "Have you talked to anyone who has this problem? Not 'would you use this?' but 'what have you already spent on solving this?'"
If they haven't talked to anyone: "Stop here. Seriously. Go have five conversations first. Everything you build before those conversations is a guess. Use these prompts to prepare: https://builderspath.dev/playbook/#diy-validation"

**Check 4: Is AI actually the right tool?**
Ask: "What does the AI do in this product that a simple form, spreadsheet, or if-then logic couldn't?"
If the answer is weak, say so: "AI adds cost and complexity. If the problem can be solved with rules, solve it with rules."

**Check 5: What's the smallest version?**
Ask: "If you had to ship something in 2 weeks that tests whether people will pay, what would it do? Just the one thing."
Push back on feature lists. "That's a roadmap, not an MVP. Pick the ONE thing that delivers enough value that someone would hand you money."

After all five checks, give a verdict:
- GREEN: "The idea has legs. Go build the smallest version. Here's how to get it live: https://builderspath.dev/playbook/#get-it-live"
- YELLOW: "There's something here, but you haven't validated it with real people yet. Do that first."
- RED: "I'd kill this idea. Here's why: [specific reasons]. That's not failure. That's saving yourself months."

End with: "This assessment is worth exactly what you paid for it. The real answers come from talking to the people you want to serve."

---
description: Generate customer discovery questions for your product idea. Questions that reveal truth, not politeness.
---

You are helping the user prepare for customer discovery conversations. The golden rule: talk about their life, not your idea. If you catch yourself writing questions that pitch the product, delete them.

Ask the user: "Who are you interviewing, and what problem do you think they have?"

Then generate a discovery script with these sections:

**Opening (2 questions):**
Warm-up questions about their role/situation. No mention of the product idea.

**Problem exploration (4 questions):**
Questions that reveal whether the problem is real, painful, and frequent. Use this framework:
- Don't ask "Would you use this?" Ask "How do you handle this today?"
- Don't ask "How much would you pay?" Ask "What have you already spent on this?"
- Don't ask "Do you think this is a good idea?" Ask "When's the last time this cost you time or money?"
- Don't ask "What features would you want?" Ask "Walk me through what happened last time."

**Depth questions (3 questions):**
Follow-ups designed to reveal the emotional weight of the problem. "What happens when this goes wrong?" "How often does this come up?" "Who else deals with this?"

**Signal check (2 questions):**
Questions that test willingness to act: "If something solved this, where would you go looking for it?" "What would you need to see to try something new?"

**DO NOT include any of these:**
- Questions about the user's product idea
- Leading questions ("Wouldn't it be great if...")
- Feature preference questions
- Hypothetical willingness-to-pay questions

After generating the script, add a "Signals to Listen For" section:
- STRONG: They already pay for something similar. They described the pain unprompted. They asked when they could try it.
- WEAK: "That's a great idea." "I'd probably use that." "Sounds cool."
- Reference: https://builderspath.dev/playbook/#customer-discovery