Table of Contents
The most dangerous sentence in customer research is “That sounds like a great idea.” I have heard it from users who never returned, prospects who never bought, and senior stakeholders who wanted the meeting to end pleasantly. Praise feels like validation; it is usually just politeness with good intentions.
Rob Fitzpatrick’s The Mom Test is valuable because it attacks that problem directly. The framework is not about tricking customers into honesty. It is about asking questions so grounded in real behavior that flattery, optimism, and hypothetical enthusiasm cannot contaminate the answer.
The common approach fails because founders and product teams interview people about an idea they already want to believe in. They describe a feature, explain why it matters, then ask whether the person would use or pay for it. The interviewee can either discourage someone who is clearly excited or offer encouragement at no personal cost.
People are remarkably generous with hypothetical support and remarkably selective with actual behavior. “I would definitely use an AI dashboard for that” means nothing beside “I spent 45 minutes exporting a CSV last Tuesday because the current dashboard failed me.” One is social lubrication; the other is evidence.
I learned this painfully while researching a workflow tool for a 12-person B2B SaaS team. We ran 18 discovery calls, showed an early concept, and heard some version of “I’d love that” from 14 participants; after launch, only two activated the feature. When we revisited the recordings, we realized we had asked about our solution in nearly every interview and had not asked what participants did before the call.
Naive questions create three predictable distortions. First, users want to be helpful, especially when a researcher has put effort into a concept. Second, they are poor forecasters of their future behavior, just like the rest of us. Third, once you reveal your preferred answer, they begin optimizing for agreement rather than accuracy.
The result is false-positive validation: a team interprets positive conversation as demand, builds the wrong thing, then rationalizes weak adoption as a launch or messaging problem. In my experience, the problem was usually visible before development began. We just did not ask questions capable of exposing it.
Fitzpatrick’s framework has three rules: talk about the customer’s life instead of your idea, ask about specific past behavior rather than general preferences or future intentions, and talk less than the person you are interviewing. Together, they turn a pleasant conversation into a useful research instrument.
The Mom Test does not make users brutally honest; it makes vague reassurance irrelevant. Even your mother can tell you your idea is wonderful. She cannot credibly invent a detailed account of how she handled the problem last week, what she tried, who was involved, and what it cost her.
The first rule means avoiding a product pitch until you have learned about the existing workflow. If you are building a tool for product managers to investigate retention drops, do not ask, “Would you use an AI tool that explains churn?” Ask, “Tell me about the last time retention dropped unexpectedly. How did you notice it? What happened next?”
The second rule forces specificity. General questions invite idealized answers; past-tense questions reveal actual priorities, workarounds, and constraints. “How do you usually collect customer feedback?” is acceptable as an opener, but “Walk me through the last feedback item that changed a roadmap decision” will teach you far more.
The third rule is harder than it sounds. Researchers often fill silence because they want to demonstrate competence, clarify the concept, or rescue an awkward answer. Silence is productive. A participant who pauses, remembers an incident, and starts explaining what happened is usually giving you the material that a tidy five-minute pitch would have buried.
The best questions start broad, then move toward a specific incident. I want a sequence: trigger, action, tools, people, friction, workaround, consequence, and stakes. That sequence tells me whether a problem is a mild annoyance, a recurring operational failure, or a genuine buying signal.
Replace this question: “Do you think a tool that automatically summarizes customer interviews would be useful?”
Ask this instead: “When was the last time you had more interview feedback than you could synthesize? What did you do with it, and what got left out?”
Replace this question: “Would you pay for a way to understand why users abandon onboarding?”
Ask this instead: “Tell me about the last onboarding drop-off your team investigated. What data did you look at first? How long did it take to reach a conclusion, and how confident were you?”
Replace this question: “Is customer research a priority for your team?”
Ask this instead: “What research did your team conduct in the past quarter? Who requested it, what decision did it inform, and what happened after the findings were shared?”
Replace this question: “Would this integration save you time?”
Ask this instead: “Show me how you complete that task today. Where do you switch tools, copy information, or wait for someone else?”
Notice what changes. The improved questions do not ask users to evaluate your idea, predict their future, or compliment your judgment. They ask for a verifiable story. If the participant cannot recall an example, the problem may not be frequent or painful enough to deserve your roadmap.
Specifics also reveal the language customers use when no product marketer is feeding them words. That language is gold for positioning. If five product managers independently say, “We can see the drop, but we can’t see why,” I would use that phrasing in messaging long before “AI-powered behavioral intelligence.”
A single past-tense question is not enough. Participants can describe a problem that happened once, was easily fixed, or belongs to someone else’s budget. Good follow-ups distinguish a compelling story from a market signal.
These are not a script to fire mechanically at every participant. They are probes for the moments where someone says “that was annoying,” “we struggled with that,” or “we really need a better way.” I want them to define “annoying” in operational terms: two hours per week, three people in Slack, missed renewals, delayed releases, or a decision made on incomplete evidence.
In a study for a six-person design platform team, I interviewed eight UX managers about handoff problems. One manager said approvals were “a nightmare,” but follow-up revealed it happened twice a year and cost about 30 minutes each time; another described a weekly workaround involving screenshots, spreadsheets, and four stakeholders across time zones. The second story—not the stronger adjective—pointed to the real opportunity.
Be especially skeptical when someone says they would pay. Payment intent is not a prediction question; it is a behavior question. Ask what they currently spend, what budget owns the problem, who approves purchases, and what they have already tried to buy or build. Past spending and active workarounds are stronger evidence than declared willingness to pay.
Most researchers know not to ask leading questions, yet leading often enters through explanation rather than wording. The moment you say, “We are seeing that teams struggle to connect analytics with qualitative feedback,” you have handed the participant a sensible answer. They may agree because it is plausible, not because it describes their reality.
I aim to speak for no more than 35% of a discovery interview, and less is often better. That does not mean being passive. It means using short prompts—“What happened next?” “Can you give me an example?” “Why was that difficult?”—instead of long summaries, pitches, and interpretations.
When you must test a concept, delay it until the final third of the conversation. First establish whether the underlying problem exists, how participants solve it now, and what it costs them. Then present the smallest possible description and ask what they would change, distrust, or need before trying it; do not ask whether they like it.
A useful concept-test question is: “Based on what you told me about your last investigation, where would this fit—or fail to fit—in your process?” That phrasing invites criticism and grounds the reaction in a known workflow. If they answer with a concrete adoption obstacle, such as security review, unreliable data, or lack of a budget owner, you have learned something actionable.
Human moderators drift, particularly after the tenth interview when fatigue sets in and they think they know the answer. An AI-moderated interviewer can be instructed to hold Mom-Test-style discipline across every session: remain concrete, ask in the past tense, probe for examples, and avoid leading participants back toward a pitch. Tools such as Usercall are useful here because they combine those deep researcher controls with research-grade qualitative analysis at a scale that makes patterns easier to test rather than merely notice.
A strong customer interview is not one where participants praise your idea. It is one where the evidence could force you to narrow the audience, change the problem framing, abandon a feature, or stop building altogether. That is not a research failure; it is the cheapest possible form of product learning.
Before every interview, review your guide and remove questions that begin with “Would you,” “Do you like,” “How useful would,” or “What do you think of.” Replace them with questions about the latest relevant event, the current workaround, and the consequences of doing nothing.
Then judge patterns by behavior, not volume of enthusiasm. Ten participants who describe the same recurring workaround, existing spend, and measurable consequence are far more persuasive than 30 people saying your concept sounds helpful. The Mom Test earns its reputation because it gives teams permission to stop collecting compliments and start collecting proof.
Related: How to Stop Getting Polite Answers in Research Interviews · 21 Interview Questions That Reveal What Users Actually Do · The User Interview Playbook
Usercall runs AI-moderated user interviews that collect qualitative insights at scale, with the depth of a real conversation and without the overhead of a research agency. Its interviewer can consistently apply Mom-Test-style probing while you retain researcher control over the questions, and Usercall is self-serve: start a free trial with no sales call required.
Related methodology: JTBD Interviews · Cognitive Interviewing
