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.
The Mom Test
"How to talk to customers and learn if your business is a good idea when everyone is lying to you" - Rob Fitzpatrick
The 3 Core Rules
- Talk about their life, not your idea
- Ask about specifics in the past, not generics or opinions about the future
- Talk less, listen more
Decision Tree
Need customer feedback?
├─ Pre-product, no idea what to build → Mom Test (this skill)
├─ Have validated market, packaging product → 100m-offers
├─ Have offer, need traffic → 100m-leads
└─ Selling enterprise → spin-sellingIn a customer conversation?
├─ They're complimenting you → DEFLECT to current behavior
├─ They're speaking in generics ("usually", "always") → ANCHOR to last specific instance
├─ They're requesting features → DIG to underlying motivation
└─ They're committing nothing → PRESS for time/reputation/moneyBad Questions (Never Ask)
| Question | Why It Fails |
|---|---|
| "Do you think it's a good idea?" | Only the market can tell. Opinions are worthless. |
| "Would you buy a product which did X?" | Everyone says yes. Hypotheticals are lies. |
| "How much would you pay for X?" | Numbers feel rigorous but are still lies. |
| "Do you ever..." / "Would you ever..." | Invites fluff and future-tense promises. |
Good Questions (Use These)
| Question | What It Reveals |
|---|---|
| "Why do you bother?" | Real motivation behind perceived problem |
| "What are the implications?" | Must-solve vs nice-to-have |
| "Talk me through the last time that happened." | Concrete past behavior |
| "What else have you tried?" | Whether they care enough to search |
| "How are you dealing with it now?" | Current solution + price anchor |
| "Where does the money come from?" | Budget and purchasing process |
| "Who else should I talk to?" | Tests if they care enough to make intros |
| "Is there anything else I should have asked?" | Catches missed points |
Three Types of Bad Data + Responses
| Bad Data | Example | Response |
|---|---|---|
| Compliments | "That's really cool, I love it." | "Thanks - but how are you dealing with this stuff at the moment?" |
| Fluff | "I usually..." / "I would definitely buy that." | "When's the last time that happened? Walk me through it." |
| Ideas/Features | "Can you add X feature?" | "Why do you want that? What would it let you do? How are you coping without it?" |
Commitment Currencies
Real interest = giving up something valuable. Compliments cost nothing.
| Currency | Examples |
|---|---|
| Time | Clear next meeting, using trial for real, sitting down for feedback |
| Reputation | Intro to peers, intro to boss, public testimonial |
| Money | Letter of intent, pre-order, deposit |
Good Meeting Endings
- "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?"
Polite Rejections (Bad Endings)
- "That's so cool, I love it!"
- "Let me know when it launches."
- "I would definitely buy that."
Critical Principle
They own the problem. You own the solution.
You aren't allowed to tell them what their problem is. They aren't allowed to tell you what to build.
The Filter Test
If they haven't even Googled for a solution, they don't actually care enough to pay for yours.
Customer Slicing
Signs Your Segment Is Too Broad
- 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)
The Slicing Process
- Within this group, who would want it MOST?
- Why do they want it? What's their specific problem?
- What are they already doing to solve it?
- Where can we find them?
Good segment test: A segment is useful only if you know WHERE to find them.
Conversation Length Guide
| Duration | Goal |
|---|---|
| 5 min | Does problem exist? Is it important? |
| 10-15 min | Workflow details, what they've tried |
| 1+ hour | Industry deep-dives with experts |
Keep It Casual
- 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
Process Checklist
Before
- Choose focused, findable segment
- Decide 3 big learning goals with team
- Decide ideal next steps and commitments
- Do basic desk research first
During
- 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
After
- Review notes and key quotes with team
- Update beliefs and plans
- Decide next 3 big questions
Signs You're Doing It Wrong
- 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
Quick Rules
Rules not already captured in the tables and checklists above:
- Customer conversations are bad by default. Your job to fix them.
- People know problems but not solutions. Don't ask what to build.
- You should be terrified of at least one question you're asking (terrified of the answer, not the asking).
- There's more reliable information in a "meh" than a "Wow!"
- It's not a real lead until you've given them a concrete chance to reject you.
Timeline
Spend a week, maybe two. Get your bearings, then give them something to commit to. Don't spend months theorizing.
Context: Founders vs. Product Teams
This framework is written for founders validating whether a new idea is worth pursuing at all. If you're a product manager at an established company, your situation is different: you already know customers want the product. Your interviews are doing problem discovery (what's broken?) or feature discovery (which direction next?) with existing users - not testing whether a market exists. The "press for commitment" and customer-slicing sections are largely irrelevant. The core questioning mechanics (past behavior, avoid hypotheticals, anchor fluff) still apply directly.
When This Doesn't Apply
- 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)
Red Flags (Customers to Avoid)
Even enthusiastic, paying customers can derail you:
- 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
Supporting Files
- 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
The Nuance
- "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.