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.