mom-test

Validates business ideas through customer conversations using Rob Fitzpatrick's Mom Test framework. Use when planning user interviews, getting product feedback, validating ideas, designing discovery questions, or extracting honest signal from biased customer responses. Covers good vs bad questions,

By getagentseal · 487 installs

npx skills add getagentseal/founder-playbook --skill mom-test

Source repository · Upstream listing

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 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 Decision Tree Bad 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 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? 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: 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. 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](frameworks.md) VFWPA email template, ACA framework, deeper question hierarchy, finding conversations playbook [cases.md](cases.md) Earlyvangelist concept (Steve Blank's term, used by Fitzpatrick), case style examples [examples.md](examples.md) Note taking symbols, full email scripts, conversation walk throughs [integration.md](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.