Note: This skill is independent analysis and commentary, not a reproduction of the original text. It synthesizes the book's core ideas with modern startup practice, surfaces where frameworks are outdated or incomplete, and integrates perspectives from adjacent disciplines. For the full argument and context, read the original book.

"How to talk to customers and learn if your business is a good idea when everyone is lying to you" - Rob Fitzpatrick

1. Talk about their life, not your idea
2. Ask about specifics in the past, not generics or opinions about the future
3. Talk less, listen more

• "What are the next steps?"
• "When can we start the trial?"
• "Can I buy the prototype?"
• "When can you come back to talk to the rest of the team?"

• "That's so cool, I love it!"
• "Let me know when it launches."
• "I would definitely buy that."

• 10+ conversations, results all over the map
• Everything "sort of works" but nothing breaks through
• Cannot prove yourself right or wrong
• Every feature is someone's favorite
• Massive price variance ($10 vs $10,000)

1. Within this group, who would want it MOST?
2. Why do they want it? What's their specific problem?
3. What are they already doing to solve it?
4. Where can we find them?

• Strip the formality - reduce "meeting" to "chat"
• Pop your most important question immediately
• Goal: they don't even realize they've "had a meeting"
• 5-10 minute casual conversations yield as much as formal meetings

• Choose focused, findable segment
• Decide 3 big learning goals with team
• Decide ideal next steps and commitments
• Do basic desk research first

• Frame the conversation
• Keep it casual
• Ask questions that pass The Mom Test
• Deflect compliments, anchor fluff, dig beneath signals
• Take good notes
• Press for commitment and next steps

• Review notes and key quotes with team
• Update beliefs and plans
• Decide next 3 big questions

• You're talking more than they are
• They're complimenting you or your idea
• You don't have notes
• You got an unexpected answer and didn't change anything
• You weren't scared of any question you asked
• You don't know what happens next
• Meeting "went well" but no concrete commitments

1. Customer conversations are bad by default. Your job to fix them.
2. People know problems but not solutions. Don't ask what to build.
3. You should be terrified of at least one question you're asking (terrified of the answer, not the asking).
4. There's more reliable information in a "meh" than a "Wow!"
5. It's not a real lead until you've given them a concrete chance to reject you.

• Formal B2B/Enterprise: Some contexts require formal protocols
• Regulated industries: Healthcare, finance may need different approaches
• Truly novel innovations: Customers can't imagine what they want until they see it
• Cultural contexts: Japan, Germany, formal corporate cultures expect different protocols
• Domain experts: Expert opinions about THEIR domain carry weight (the rule is about opinions on YOUR IDEA)

• Needs so specific they'll pull you off-course
• Demand custom work that doesn't generalize
• "Visionaries" who want something completely different from your vision
• Will only commit if you build their pet feature first

• frameworks.md - VFWPA email template, ACA framework, deeper question hierarchy, finding-conversations playbook
• cases.md - Earlyvangelist concept (Steve Blank's term, used by Fitzpatrick), case-style examples
• examples.md - Note-taking symbols, full email scripts, conversation walk-throughs
• integration.md - How Mom Test feeds 100m-offers, 100m-leads, spin-selling, obviously-awesome; conflicts with hypothesis-testing approaches

• "Talk less" means don't pitch your solution, not don't talk at all. Strategic questions and redirections are talking.
• "Be terrified of a question" means terrified of the ANSWER (it might invalidate your idea), not asking aggressive questions.
• "Press for commitment" doesn't mean be pushy. Know when to back off. Burning a contact is worse than no commitment.
• "They can't tell you what to build" doesn't mean ignore domain experts. Sophisticated users may know implementation better than you - understand the WHY.