Module 2: Talking To Users
The Mom Test
Overview
Lesson 2 gave you one rule: ask about the past, not the future. Rob Fitzpatrick, in his book The Mom Test, generalizes that idea into a three-rule framework, designed to solve a specific problem: your own mom is going to lie to you about your business idea, because she loves you and doesn't want to hurt you. If you ask her "would you use an app that helps you cook?", your mom is going to say yes, even if she's never going to open it — because she loves you, and saying no feels like disappointing you. The Mom Test is the set of rules for asking questions that not even your mom, wanting to please you, could answer with a comfortable lie.
How this connects to the module. Lesson 2 covered the Mom Test's Rule 2 (past, not future) in detail. This lesson presents the full framework —all three rules together— and builds momTestCheck(), which applies two of them to a question and returns exactly which rule it violates, if any. The third rule —talk less, listen more— can't be measured from text alone, so it's practiced, not calculated; it comes back in more depth in lesson 5.
An everyday analogy: the waiter who only asks questions that answer themselves
Imagine a waiter who, at the end of dinner, asks you: "Wasn't that delicious?". It's almost impossible to say no — the question already carries the right answer built in, and saying "actually, I didn't like it" feels like a personal attack on the waiter. Compare that to: "What did you like most about the dish?" — it still assumes you liked something, but at least it leaves you room to qualify it. And compare it to the best version: "What did you order the last time you came, and would you order it again?" — a question that points at a concrete, verifiable fact, not an opinion the waiter already suggested.
The Mom Test names this same problem in the product context with three rules, all pointing at the same thing: getting the user's real life out of them, not an opinion about your idea.
THE 3 RULES OF THE MOM TEST
──────────────────────────────────────────────────────────────
1. Talk about THEIR life, "How did you solve X the last
not your idea. time?" instead of "what do you
think of MY idea?"
2. Ask for specifics from "When was the last time
the past, not opinions that...?" instead of "what do
or generalities. you think of...?" or "would
you use...?"
3. Talk less, let the awkward silence get
listen more. filled by the user, not you
──────────────────────────────────────────────────────────────
Worked example: momTestCheck() over the first script draft
Mercado's team wrote a first draft of questions to understand the reaction to recommendations. Before using it with a real buyer, we run it through a check that combines two of the Mom Test's three rules: does the question mention your idea instead of the user's life (Rule 1)? Does it ask for an opinion or prediction instead of a past fact (Rule 2, reusing detectTense from lesson 2)?
// L3: we operationalize 2 of the Mom Test's 3 rules (the third, "talk less",
// isn't verifiable from text -- it's practiced, not measured).
// Rule 1: talk about THEIR life, not your idea. Rule 2: ask for past specifics, not opinions/future.
function detectTense(question) {
const q = question.toLowerCase();
const futureSignals = ['would you use', 'would you buy', 'would you like', 'would you pay', 'would you install', 'would you prefer'];
const pastSignals = ['what did you do', 'when was the last time', 'how did you solve', 'what did you use', 'do you remember the last time'];
if (futureSignals.some((s) => q.includes(s))) return 'future';
if (pastSignals.some((s) => q.includes(s))) return 'past';
return 'unclear';
}
function momTestCheck(question) {
const q = question.toLowerCase();
const pitchesIdea = ['personalized recommendations', 'our new feature', 'the feed we\'re building', 'this idea'];
const opinionSignals = ['what do you think', 'do you believe', 'do you feel like'];
const violatesRule1 = pitchesIdea.some((s) => q.includes(s));
const tense = detectTense(question);
const violatesRule2 = tense === 'future' || opinionSignals.some((s) => q.includes(s));
const violations = [];
if (violatesRule1) violations.push('rule 1: talks about your idea, not the user\'s life');
if (violatesRule2) violations.push('rule 2: asks for an opinion or prediction, not a past fact');
return { question, passes: violations.length === 0, violations };
}
const draftQuestions = [
'What do you think about Mercado showing you personalized recommendations?',
'Would you use our new feature for recommendations?',
'When was the last time you bought something because someone recommended it to you?',
'What do you think of the idea for the feed we\'re building?',
];
console.log('=== momTestCheck() over the first script draft ===\n');
draftQuestions.forEach((q) => {
const r = momTestCheck(q);
console.log(' "' + r.question + '"');
if (r.passes) {
console.log(' -> PASSES the Mom Test\n');
} else {
console.log(' -> FAILS: ' + r.violations.join(' | ') + '\n');
}
});
What to expect. When you run the file with Node, the output is exactly this:
=== momTestCheck() over the first script draft ===
"What do you think about Mercado showing you personalized recommendations?"
-> FAILS: rule 1: talks about your idea, not the user's life | rule 2: asks for an opinion or prediction, not a past fact
"Would you use our new feature for recommendations?"
-> FAILS: rule 1: talks about your idea, not the user's life | rule 2: asks for an opinion or prediction, not a past fact
"When was the last time you bought something because someone recommended it to you?"
-> PASSES the Mom Test
"What do you think of the idea for the feed we're building?"
-> FAILS: rule 1: talks about your idea, not the user's life | rule 2: asks for an opinion or prediction, not a past fact
Three of the four questions in the original draft violate both rules at once — that's not a coincidence. When a question names your idea explicitly ("personalized recommendations", "the feed we're building"), it almost always also ends up asking for an opinion or prediction about that idea, because there's no way to ask "what do you think of my feed?" without pointing at the future. The two rules reinforce each other: naming your idea invites the hypothetical question, and the hypothetical question almost always needs to name your idea to make sense. The only question that passes —"when was the last time you bought something because someone recommended it to you?"— doesn't even mention Mercado, or "personalized recommendations", or any feature name: it asks the user about their life, in any context, not about your product.
The rule code can't measure: talk less, listen more
The Mom Test's Rule 3 —talk less, listen more— doesn't show up in momTestCheck() because it isn't a text pattern in the question: it's a pattern of behavior during the conversation. Fitzpatrick describes a very common, very damaging habit: when the user goes quiet for a few seconds while thinking, the interviewer —uncomfortable with the silence— fills the gap by talking, sometimes suggesting the answer without realizing it ("maybe because you didn't trust the quality?"). That awkward silence is, almost always, the exact moment the user is about to say something true and unrehearsed. Interrupting it with a suggestion robs the interviewer of their own evidence.
This principle returns in more detail and with executed code in lesson 5, where you're going to measure how much of an interview was the interviewer talking about their own idea (pitchRatio) instead of leaving room for the user.
Common mistakes
Using your product or feature's name inside the question. What happens: the team writes questions that sound natural in an internal meeting —"what do you think of Mercado's personalized recommendations?"— without noticing that mentioning the feature's name automatically turns the question into a pitch disguised as a question. Why it happens: for the team, "personalized recommendations" is the central topic of the conversation, so naming it feels natural and necessary — but for the user, naming the idea is an invitation to evaluate it in the abstract, not to tell their real experience. How to spot it: underline every mention of your product's name, feature name, or "this idea" in the script — each mention is a potential Rule 1 violation. How to fix it: rewrite each question to talk about a situation from the user's life without naming your solution — like the only question that passed momTestCheck() in today's example.
Confusing "asking a lot of Mom Test questions" with "running a whole good interview". What happens: the team writes five perfect questions according to Rules 1 and 2, but during the real interview, the interviewer interrupts every answer with comments, finishes the user's sentences, and suggests examples before the user mentions them — violating Rule 3 without the written script ever giving it away. Why it happens: a script gets reviewed in writing and in silence; behavior during a live conversation is much harder to audit before it happens. How to spot it: record (with permission) an interview and measure how much time the interviewer talks versus how much time the user talks — if the interviewer talks more than a third of the total time, something's off. How to fix it: practice silence deliberately — count to five in your head after every user answer before speaking again; almost always, if you wait, the user keeps talking on their own and says something more valuable than what you were going to ask.
Exercises
Exercise 1 — Apply the two measurable rules. For this question, say which Mom Test rules it violates, if any, and why: "Do you believe the recommendations feed we're designing would save you time?"
See solution
It violates both measurable rules. Rule 1: it mentions "the recommendations feed we're designing" — names the idea directly. Rule 2: it starts with "do you believe...?", one of the opinionSignals in momTestCheck() — it asks for an opinion/prediction, not a past fact. A rewrite that would pass both rules: "When was the last time you wasted time looking for something on an online store, and what did you do about it?" — it doesn't name any idea of your own, and it asks for a concrete past fact.
Exercise 2 — Find your own mom's example. Think of any product idea (it can be made up). Write the question you'd ask your mom if you wanted a genuinely honest answer (not one that makes her feel like she's supporting you), applying Rules 1 and 2.
See solution
There's no single correct answer, but a reasonable one follows the lesson's exact pattern: without naming the idea, asking for a concrete past fact. For example, if the idea is a recipe app: instead of "would you use a recipe app that suggests what to cook?", you'd ask "what did you do the last time you didn't know what to cook and had little time?" — without mentioning the app, asking for a real memory. The test of whether it worked: if your mom can answer with a specific fact ("last Tuesday I ate Sunday's leftovers because I didn't feel like thinking") instead of an encouraging phrase ("I'd love that, it sounds great!"), the question truly passed the Mom Test, not just in theory.
Exercise 3 — Spot the Rule 3 trap. Read this partial transcript and identify the moment the interviewer breaks Rule 3 (talk less, listen more):
Interviewer: "When was the last time you bought something you hadn't planned to?" User: "Hmm, let me think... " Interviewer: "Was it maybe because you saw a deal, or because someone recommended it to you?" User: "Yeah, I think it was because of a deal."
See solution
The interviewer breaks Rule 3 right after the user's "Hmm, let me think..." — that two-second silence is exactly the moment the user is retrieving a real memory, and the interviewer interrupts it with a multiple-choice question ("was it because of a deal, or because someone recommended it to you?") that suggests both possible answers. The "yeah, I think it was because of a deal" that follows isn't necessarily what the user was going to say — it's the option the interviewer put on the table, picked out of social convenience rather than certainty. The right version: wait in silence, or at most say "take your time", and let the user complete the memory in their own words, with no options suggested.
Summary and next step
The Mom Test gives you a three-rule framework for questions that not even your own mom, wanting to please you, could answer with a comfortable lie: talk about her life, not your idea (Rule 1); ask for past facts, not opinions or predictions (Rule 2); talk less, listen more (Rule 3). You saw momTestCheck() run live, combining the first two rules, and found that three of four questions in Mercado's first draft failed both at once — and understood why naming your own idea almost always drags a question toward the hypothetical.
Before moving on you should be able to: name the Mom Test's three rules from memory; identify, in any given question, whether it mentions your own idea; and explain why Rule 3 can't be measured with a text classifier.
Lesson 4 takes on a related but distinct trap: leading questions, which don't necessarily mention your idea or ask for a prediction, but still plant the expected answer inside the question itself. That's where you're going to assemble classifyQuestion(), the full three-category classifier you'll use for the rest of the module.
Resources
- Rob Fitzpatrick, The Mom Test: How to talk to customers & learn if your business is a good idea when everyone is lying to you — momtestbook.com. This lesson's direct source; the full book, short and very practical, devotes its first chapters exactly to today's three rules. In English.
- Teresa Torres, "Why You Are Asking the Wrong Customer Interview Questions" — producttalk.org/customer-interview-questions. Reinforces Rule 2 with the jeans-shopping example: asking for a specific fact instead of a general opinion. In English.
- Steve Portigal, Interviewing Users: How to Uncover Compelling Insights (2nd edition) — rosenfeldmedia.com/books/interviewing-users-second-edition. A more extensive book on the full practice of interviewing, useful as a next step after mastering the Mom Test's basic rules. In English.