Loading
Talk to customers without leading them using Mom Test rules: discuss their life not your idea, ask about specifics in the past, and talk less. Use when the user mentions "customer interviews", "valida
The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
npx skills add wondelai/skills --skill mom-test -a cursor -y
Talk to customers without leading them using Mom Test rules: discuss their life not your idea, ask about specifics in the past, and talk less. Use when the user mentions "customer interviews", "validate my idea", "users say they want it but dont buy", "leading questions", "The Mom Test", "customer feedback bias", or "interview script". Also trigger when preparing user-research questions, interpreting ambiguous feedback, or designing customer-discovery that avoids false positives. Covers commitment and advancement, avoiding compliments, and extracting signal from noise. For product-market fit, see jobs-to-be-done. For rapid prototype testing, see design-sprint.
Talk to customers without leading them using Mom Test rules: discuss their life not your idea, ask about specifics in the past, and talk less. Use when the user mentions "customer interviews", "validate my idea", "users say they want it but dont buy", "leading questions", "The Mom Test", "customer feedback bias", or "interview script". Also trigger when preparing user-research questions, interpreting ambiguous feedback, or designing customer-discovery that avoids false positives. Covers commitment and advancement, avoiding compliments, and extracting signal from noise. For product-market fit, see jobs-to-be-done. For rapid prototype testing, see design-sprint.
Framework for customer conversations that won't lead you astray, based on a fundamental truth: everyone is lying to you -- not maliciously, but because you're asking the wrong questions. The Mom Test provides rules for asking questions so good that even your mom can't lie to you.
Good customer conversations are about their life, not your idea. The moment you mention what you're building, people switch from sharing truth to performing politeness. Talk about their problems, their lives, and their existing behavior instead of pitching, and ask about specifics in the past, not hypotheticals about the future. Above all, talk less and listen more.
Goal: 7/7. Score a conversation (or interview plan) by the seven-row Quick Diagnostic below: 1 point per row that passes.
Always state the current score out of 7, name the failing diagnostic rows, and give the specific fix for each.
Core concept: Three rules that make it impossible for even your most supportive loved ones to give you false validation, shifting conversations from opinion-gathering to fact-finding.
Why it works: People are unreliable predictors of their own future behavior, so opinions are worthless. Past behavior is the only reliable data and can genuinely inform product decisions.
Key insights:
Product applications:
| Context | Application | Example |
|---|---|---|
| Idea validation | Ask about the problem, never the solution | "Tell me about the last time you tried to [problem area]" not "Would you use an app that does X?" |
| Feature prioritization | Discover what people do vs. what they say | "Walk me through how you handled this last week" |
| Pricing research | Anchor to existing spending behavior | "What are you currently paying to solve this?" not "Would you pay $X?" |
Copy patterns:
See: references/question-patterns.md when drafting an interview script -- a 5-tier question hierarchy, domain-specific question banks (SaaS/consumer/marketplace), and four formulation exercises.
Core concept: Most interview questions are broken because they ask people to predict the future, evaluate hypothetical products, or confirm your assumptions. Good questions anchor in observable past behavior and extract concrete facts.
Why it works: Asking "would you buy this?" is like asking "will you go to the gym next week?" -- the answer is always yes, the follow-through rarely there. Behavior that already happened can't be rationalized away.
Key insights:
Product applications:
| Context | Application | Example |
|---|---|---|
| Problem validation | Confirm the problem exists and matters | "When did this last come up? What did you do? What didn't work?" |
| Market sizing | Check if enough people share the problem | "Who else in your industry deals with this? How do they handle it?" |
| Competitive analysis | Find real alternatives already in use | "What tools/processes do you currently use for this?" |
Copy patterns:
Core concept: Three types of bad data feel like progress but actively mislead: compliments ("That's a great idea!"), fluff (hypotheticals, maybes, future promises), and ideas (feature requests disconnected from real problems). Deflecting these and digging for truth is the core skill.
Why it works: Compliments are the fool's gold of customer development -- they feel amazing but contain zero information about whether anyone will pay or use the product. Only specifics about real past behavior and genuine commitments provide signal.
Key insights:
Product applications:
| Context | Application | Example |
|---|---|---|
| Post-demo feedback | Deflect "this looks awesome" | "Thanks! What part of your current workflow would this replace?" |
| Feature requests | Dig for the underlying job | "Why do you want that? Can you show me the last time you needed it?" |
| Investor conversations | Separate encouragement from interest | Ask for customer intros, not "great idea" feedback |
Copy patterns:
See: references/avoiding-bad-data.md when a conversation feels good but yields no facts -- how to spot and deflect the three bad-data types (compliments, fluff, ideas) in real time.
Core concept: The currency of a customer conversation is commitment, not compliments. End every conversation with a clear advance toward adoption or a clear rejection -- the worst outcome is a "zombie lead" who is polite but never commits.
Why it works: Saying "I'd definitely buy that" costs nothing; offering an intro, a deposit, or a pilot invests something real. Commitment closes the dangerous gap between what people say and what they do.
Key insights:
Product applications:
| Context | Application | Example |
|---|---|---|
| Early validation | Request a commitment that tests interest | "Can I follow up with a prototype next week for 15 minutes of your time?" |
| B2B sales | Advance toward the decision-maker | "Could you introduce me to the person who handles the budget for this?" |
| Pre-launch | Collect pre-orders or letters of intent | "Launching in 8 weeks -- want to join the first cohort at 40% off?" |
Copy patterns:
See: references/commitment-advancement.md when a conversation ends without a commitment -- the currency ladder (time/reputation/money) and scripts for advancing instead of spinning wheels.
Core concept: The best customer conversations happen casually -- warm intros, industry events, online communities, coffee. Formal "customer interview" framing triggers performance mode; casual framing produces honest data.
Why it works: "Can I interview you about your problems?" makes people polished and guarded; "I'm trying to learn about the industry -- can I buy you coffee?" makes them open up. The framing determines the quality of the data.
Key insights:
Product applications:
| Context | Application | Example |
|---|---|---|
| Pre-idea exploration | Immerse in the target community | 3 industry events and 20 casual conversations before writing code |
| B2B prospecting | Warm intros through advisors | "Our advisor [Name] suggested I ask how you handle [problem area]" |
| Consumer research | Intercept at the point of behavior | Talk to people in line at the store, the gym, the coworking space |
Copy patterns:
Ethical boundary: Never disguise a sales call as a learning conversation -- if you already have a product and are selling, be transparent.
See: references/finding-conversations.md when you need to source interviews -- cold vs warm outreach templates, the five-part meeting ask (vision/framing/weakness/pedestal/ask), and how to keep it casual.
Core concept: Conversations are only useful if processed: distill raw notes into beliefs, update them regularly, and share with your team. Without a system you'll cherry-pick quotes that confirm your biases.
Why it works: Memory is biased toward recent and emotionally charged information, so teams selectively remember confirming data. Processing as a team prevents any one person's bias from dominating the narrative.
Key insights:
Product applications:
| Context | Application | Example |
|---|---|---|
| Team alignment | Review notes together weekly | 5 conversations per week reviewed as a team; belief board updated |
| Pivot decisions | Track evidence against core beliefs | 8 of 10 conversations reveal a different problem than expected -- pivot |
| Feature validation | Count unprompted mentions | A problem named by 7 of 10 people is real; 1 of 10 might not be |
Copy patterns:
See: references/processing-learning.md after a batch of interviews -- the notes-to-beliefs spreadsheet template, team-review cadence, and signals that it's time to stop talking and build.
| Mistake | Why It Fails | Fix |
|---|---|---|
| Pitching your idea instead of asking about their life | Triggers politeness; produces compliments, not facts | Don't mention your idea until the very end, if at all |
| Asking "would you buy this?" | Hypothetical yeses cost nothing | Ask what they've already done: "How much are you spending on this now?" |
| Accepting compliments as validation | "Great idea!" carries zero information about behavior | Deflect immediately: "Thanks -- but what are you doing about this today?" |
| Talking too much | You learn while listening, not talking | They should talk 80%+ of the time |
| No clear ask at the end | Produces zombie leads that go nowhere | Know your advance before the meeting: trial, intro, pre-order |
| Running formal "interview" sessions | Triggers performance mode and filtered answers | Keep it casual: coffee, hallway conversations, Slack DMs |
| Not processing notes as a team | Individual bias filters data into confirmation | Share raw notes weekly; update shared beliefs together |
| Question | If No | Action |
|---|---|---|
| Did the conversation focus on their life and past behavior, not your idea? | You ran a pitch, not a Mom Test conversation | Redo with zero mention of your solution |
| Did you get concrete facts about what they've already done? | You collected opinions and hypotheticals | Ask about the last time the problem occurred and what they did |
| Did they give a commitment (time, reputation, or money)? | Likely a zombie lead -- polite but not interested | Ask for a specific next step: trial, intro, or pre-order |
| Did they do most of the talking? | You talked too much and learned too little | Practice silence; let awkward pauses work for you |
| Did you learn something that could change what you're building? | You asked safe, confirming questions | Ask the scary questions you've been avoiding |
| Did you update your beliefs based on the conversation? | You're collecting data but not learning | Review notes with the team; update problem/segment/solution beliefs |
| Can you summarize the key facts (not opinions)? | Poor notes, or opinions confused with facts | Separate facts from interpretations immediately after |
See: references/case-studies.md when you want to see the rules applied end-to-end -- realistic SaaS, consumer, B2B, and marketplace interviews scored against this diagnostic.
This skill is based on Rob Fitzpatrick's Mom Test methodology:
Rob Fitzpatrick is an entrepreneur and educator who founded multiple venture-backed startups and learned the hard way that most customer conversations produce misleading feedback. The Mom Test (2013) distills his evidence-based approach, has been translated into 20+ languages, and is required reading at accelerators including Y Combinator and Techstars. He also wrote The Workshop Survival Guide and Write Useful Books.