pm-method-mom-test

《The Mom Test》 · Don't ask "would you use it", ask about their actual past

When to use me

You need to do user/customer interviews and are afraid of eliciting a pile of well-meaning lies → use [Three Iron Rules] + [Good Question Rewrites]
After the interview you have a pile of "sounds good" → use the [Signal Filter Checklist] to judge which are real signals
You want to validate whether a need is real or fake → use the [Talk About the Past, Not the Future] framework
Not suitable for: quantitative validation of scale, A/B experiments, usability testing of a solution—this book only solves "how to talk with people to get real signals". To discover rhythm and opportunity structure see pm-advisor-torres; to structure needs see pm-method-story-mapping.

Core Frameworks

Framework 1: The Three Iron Rules (the definition of the Mom Test, Foreword & Chapter 1)

The book's title comes from a counterintuitive point: you should not ask "does Mom think my business is good" (she loves you and will lie). The real fault is not hers, it is your question. A good interview follows three rules:

Steps (go through them once in every interview):

Talk about their life, not your idea → your solution does not appear in the question
Ask about specific past events, not vague futures or opinions → change "would you" into "last time you… when was it"
Listen more, talk less → the less you say, the more truth you get; when the topic drifts into praising you, pull it back to facts

Output: an interview outline that can be asked "without mentioning your own idea".

Framework 2: Talk About the Past, Not the Future (Chapters 1, 3)

Applicable scenario: validating whether a need truly exists.

Steps:

Lock onto the behavior you want to validate → find its traces in the user's past life
Dig into the past with specific questions: when did it last happen? How was it handled then? What tools were used/how much money was spent/how much time was spent? How bad was it that time?
Judgment: he has actually paid real money for this problem (time/money/self-built solution) = real signal; merely "yeah, it's pretty annoying" = weak signal
Output: a conclusion on whether this need "has already been voted for by users through action"

Framework 3: Chasing Commitment & Advancement (Commitment & Advancement, Chapter 5)

Applicable scenario: judging whether the other party's enthusiasm is real (especially B2B/sales-style interviews).

Steps:

After the other party says nice things, ask for a "costly next step": time (next deep talk/referral), reputation (referral to a colleague/boss), money (prepayment/intent)
Willing to pay a cost → real interest; only giving "praise + no commitment" → polite brush-off
Output: a judgment on whether this lead "is worth continuing to invest in"

Decision Rules (with source annotations)

If your question mentions your own idea, then this question is invalid—rewrite it into a version that only asks about the other person's life. (Chapter 1)
If you are asking "would you/would you want", then change it to "when was the last time you encountered this problem, and what did you do then". (Chapters 1, 3)
If the other person is praising your idea, don't get excited—steer the conversation back to concrete facts and past behavior. Praise is the most dangerous false signal. (Chapter 2)
If what the other person gives is a vague opinion, a future promise, or a hypothetical "if," label it as "fluff" and do not treat it as evidence. (Chapter 2)
If a pain point is real, the user must have paid some cost for it in the past; if you can't find any cost, treat it as a false need. (Chapter 3)
If the interview ends without securing any commitment or progress, then it was not a successful conversation, no matter how good the atmosphere was. (Chapter 5)
If you are "pitching" rather than "learning," stop immediately—the purpose of an interview is to get information, not approval. (Chapter 4)
Write down in advance "the three answers I'm most afraid to hear," proactively ask about them, and don't just ask questions that make you comfortable. (Chapters 6 and 7)

Checklist: Signal filtering for a single interview (synthesizing Chapters 2, 3, and 5)

I did not pitch my own idea at any point
I asked about specific past experiences, not future intentions
The pain points the other person mentioned are backed by evidence of past time/money/self-built solutions
I labeled all "praise, vague opinions, future promises" as fluff and did not treat them as evidence
I obtained at least one commitment or advance that came at a cost (otherwise review why I did not get one)
What I recorded was the other person's exact words and facts, not my interpretation

Three forms of fluff to watch out for: vague opinions ("I usually..."), future promises ("I will definitely buy"), and hypothetical praise ("This idea sounds good").

Anti-patterns (explicitly warned against in the book)

Treating an interview as a pitch—introducing your product as soon as you open your mouth, after which all answers are contaminated. (Chapter 4)
Collecting praise and treating it as validation—"everyone says they like it" is the sweetest self-deception in entrepreneurship. (Chapter 2)
Asking leading/closed questions—"Would you pay for this time-saving feature?" will almost inevitably get a fake "yes." (Chapter 1)
Only talking to people who are easy to schedule and friendly to you, and avoiding people who might contradict you. (Chapter 6)
Not ending the conversation with a next step, relying on "it felt good" memory, and leaving no checkable facts. (Chapters 5 and 7)

Boundary Statement

Published in 2013, the method is stable and has hardly gone out of date; but it only addresses "extracting true signals from qualitative interviews" and does not replace quantitative validation and scale judgment
Applicable to: whether needs are real or false, pain point intensity, and B2B lead quality; not applicable to: usability testing, interface preferences, and market size estimation
It teaches you "how to ask," not "whom to ask / how to prioritize opportunities"—sample and prioritization need to be combined with the discovery structure of pm-advisor-torres
A single interview sample is small; conclusions can only be trusted after cross-validation across multiple interviews

Workflow

After receiving the user's question:

Match the scenario → choose a framework (design an outline / judge whether signals are true or false / judge commitment)
If core inputs are missing (the specific behavior to validate, the type of interview subject) → list in one go the information that needs to be supplemented; when industry facts are needed, use WebSearch and do not make them up
Execute according to the framework steps: help the user rewrite each "bad question" into a "good question" sentence by sentence, and provide an outline that can be used directly
Use the signal filter checklist to review the user's existing interview records and mark item by item which are fluff and which are real signals
End with a boundary statement, suggesting that the perspective can be changed for cross-validation (e.g., "Torres will help you hang these interviews into the opportunity solution tree")

This Skill was generated by career-skill-factory. The content is distilled from the original work, and the copyright belongs to the original author Rob Fitzpatrick. For personal learning only.