The Mom Test Skill
This skill applies The Mom Test framework to product discovery tasks. Before
doing anything else, read references/principles.md to load the full framework.
Core Philosophy
The Mom Test is built on one insight: people will lie to you, not out of malice
but out of politeness. Your mom will tell you your app idea is great because she
loves you, not because it is great. The only way to get reliable signal from
customer conversations is to talk about their life and behavior, not your idea.
Three rules govern every question you write or evaluate:
- Talk about their life, not your idea
- Ask about specifics in the past, not hypotheticals about the future
- Talk less, listen more
Modes of Operation
When the user invokes this skill, determine which mode fits their request. If
ambiguous, ask.
Mode 1: Question Review
The user has draft interview or discovery questions and wants them evaluated.
For each question, classify it into one of three tiers:
- Safe: Past behavior, specifics, about their life. No changes needed.
- Sequencing-sensitive: The question follows the rules structurally, but it
reveals your focus area or hypothesis. Safe if asked later in the conversation
(after trust is built and broader context is established), but risky if asked
too early. Flag these with a note on where in the conversation they belong.
- Risky: Hypothetical, opinion-seeking, pitching-disguised-as-asking,
future-tense promises, or compliment-fishing. Explain why it's risky using
framework language, and provide a rewritten version that preserves the intent
but follows the rules.
Flag if the overall question set is leading the witness toward a predetermined
answer.
Format the output as a sequential review of each question. Don't just list
problems in the abstract; rewrite every risky question so the user walks away
with a usable set.
Mode 2: Question Generation
The user provides a hypothesis, assumption, feature idea, or problem space and
wants discovery questions generated.
Process:
- Restate the underlying assumption being tested (confirm with user if unclear)
- Generate 5-8 questions that test the assumption without revealing it
- For each question, include a parenthetical note on what signal a strong or
weak answer would look like
- Order questions from broad/warm-up to specific/commitment
- Include at least one "advancement" question that pushes for a concrete next
step (intro to another person, willingness to pay, letter of intent, etc.)
The questions should feel like a natural conversation, not an interrogation. If
the user provides context about who they're talking to, tailor the language and
framing accordingly.
After the questions, include a short "Things You Should NOT Say" section. List
3-5 specific phrases, framings, or question patterns that would accidentally
reveal the hypothesis, pitch the solution, or otherwise contaminate the
conversation. This helps the user stay disciplined during the live call when
they're tempted to ad-lib.
Mode 3: Conversation / Transcript Analysis
The user provides notes, a transcript, or a summary of a customer conversation
and wants it analyzed.
Analyze for:
- Compliment deflections: Where did the customer say nice things that
contain no actionable information? Flag these and note what follow-up question
would have extracted real signal.
- Hypothetical traps: Where did the conversation slip into "would you" or
"do you think" territory? Note what actually happened vs. what was explored.
- Missing specifics: Where did the customer make a general claim ("we spend
a lot on that") without being pressed for numbers, frequency, or examples?
- Buried signals: What offhand comments or complaints might indicate real
pain that wasn't followed up on?
- Interviewer bias: Flag any editorializing in the notes that reflects the
interviewer's feelings rather than observable facts. Phrases like "she seemed
really engaged," "he was excited about the idea," or "it was a really positive
call" are the interviewer's interpretation, not data. These are dangerous
because they inflate perceived signal and obscure what was actually said.
- Commitment check: Did the conversation end with any form of advancement
(intro, payment, follow-up meeting, access to data), or just a compliment?
Critically distinguish between offered commitments ("he said he'd intro me
to the CISO") and realized commitments ("he emailed the CISO and CC'd me
that afternoon"). An offered commitment is a weak signal until it actually
happens. Many offered intros, follow-ups, and meetings never materialize.
Score offered commitments one level lower on the commitment ladder than
realized ones.
Provide a summary scorecard at the end: what was learned that's trustworthy, what
sounded good but is unreliable, and what to dig into next time.
Mode 4: Assumption Extraction
The user provides a product idea, feature spec, PRD, or strategic initiative and
wants the riskiest assumptions surfaced.
Process:
- Sweep for assumptions across these categories systematically:
- Customer: Who has this problem? Are they who we think they are?
- Problem: Is the problem real, frequent, and painful enough to solve?
- Existing behavior: What are they doing today, and is it bad enough to
change?
- Market: Is the timing right? Is the market large enough?
- Willingness to pay: Will they spend money on this, and how much?
- Workflow/adoption: Will this fit into how they work, or does it require
behavior change?
- Technical feasibility: Can we actually build this?
- Go-to-market: Can we reach these customers, and through what channel?
- Rank them by risk: how bad is it if this assumption is wrong, and how
confident are we that it's right?
- For the top 3-5 riskiest assumptions, provide a concrete conversation-based
test: who to talk to, what to ask, and what answer would validate or
invalidate the assumption
- Flag any assumptions that can't be tested through conversation (e.g., pure
technical feasibility, market sizing) and suggest alternative validation
methods
General Guidelines
Across all modes:
- Never let the user accidentally pitch their idea inside a discovery question.
If a question contains the solution ("What if we built X?"), flag it
immediately.
- Treat "would you use this?" and "would you pay for this?" as red flags, always.
Past behavior and current spending are the only reliable predictors.
- Emotional language from customers ("I hate our current tool") is interesting
but not sufficient. Always push toward: what have they actually done about
the problem? Have they tried alternatives? Have they spent money? Have they
built workarounds?
- When generating or reviewing questions, bias toward questions that are hard to
answer with a polite lie. "How do you currently handle X?" is much harder to
lie about than "Would a tool that does X be useful?"
- Advancement and commitment are the real currency. A conversation without a
concrete next step is a conversation where you learned nothing about real
demand.