User Research for Beginners: The Mom Test and How to Watch

Ask your mom if she likes your business idea and she will say yes. Not because she’s lying, but because she loves you. The trouble is, most of the people you interview will do the same thing for the same reason: they want to be nice.

That single fact quietly ruins more product decisions than any technical bug. If you can learn to ask questions that even a kind, biased person cannot answer dishonestly, you will know more about your users than competitors who spent ten times as much. This is how you do that.

Why this matters

You cannot design well for a user you have only imagined.

Good product sense is not a gift you’re born with. It’s built from evidence about how real people actually behave. User research is just the practice of gathering that evidence on purpose, instead of guessing.

It fights two costly mistakes. The first is building for yourself and assuming everyone else is like you. The second is trusting what people say over what they actually do.

Picture a developer who decides print-shop owners “probably want bulk discounts,” builds it, and ships. Now picture sitting beside an owner at 9pm while she fumbles to quote a 500-business-card job from memory. The second person knows what to build. The first only has a hunch wearing a costume.

The Mom Test: how to talk to people who want to be nice

The best starting point for beginners is a short book called The Mom Test by Rob Fitzpatrick. The title is the whole lesson.

Because people will say nice things to spare your feelings, the burden is on you to ask questions that don’t invite flattery. That means asking about facts and past actions, not feelings about your idea.

The three rules

1. Talk about their life, not your idea. The moment you mention your solution, you contaminate the conversation. They own the problem; you own the solution.
2. Ask about specific things in the past, not opinions about the future. What someone did matters infinitely more than what they say they will do. The past is concrete. The future is a wish.
3. Talk less, listen more. If you’re doing most of the talking, you’re pitching, not learning.

The three kinds of bad data to throw away

• Compliments. “Great idea!” or “I’d totally buy that.” A compliment costs nothing, so it’s worth nothing. It feels like validation. It’s noise.
• Fluff. Generic claims (“I always…”, “I never…”), future promises (“I would…”), and hypothetical maybes (“I might…”). All speculation.
• Ideas. Users tossing you feature requests. Write down the problem or emotion behind the idea, not the idea itself. You’re already drowning in ideas.

Here’s the difference in practice:

Biased question	Mom-Test question
”Would you use an app that automated your quotes?"	"Walk me through the last time you quoted a big custom job. What did you do? How long did it take? What went wrong?"
"Do you think pricing is a problem for print shops?"	"When was the last time you lost a customer over a price quote? Tell me what happened.”

The biased questions ask for a prediction or an opinion. The good ones ask for a story that already happened. Stories can’t flatter you.

Enthusiasm is not a result

The single trickiest trap is treating a smile as a signal. It isn’t.

A real signal is commitment: the person gives up something they value. That comes in three currencies:

• Time - they agree to a real follow-up meeting.
• Reputation - they introduce you to their boss or peers.
• Money - they put down a deposit or pre-order.

A compliment is free. Commitment costs something. Only the second one means anything.

Generative vs evaluative: the one model to remember

Almost all research falls into two buckets, and beginners constantly mix them up.

Generative research (done early)

This happens before a solution exists. The goal is to discover problems, needs, and context. It answers the question “What should we even build?” Methods include interviews, field observation, and diary studies. The Mom Test is really just good hygiene for generative interviews.

Evaluative research (done later)

This happens on a design, prototype, or live product. The goal is to test how well a specific solution works. It answers “Does the thing we built actually work, and where do people get stuck?” Methods include usability testing, A/B tests, and feature analytics.

In one line: generative research reveals what to test; evaluative research measures how well the solution works. They’re partners, not rivals. Use one to find the right problem and the other to sharpen the answer.

Usability testing and the “5 users” rule

Usability testing means watching real people try to finish a real task with your product, and noting where they struggle.

A well-known finding from usability researcher Jakob Nielsen is that you only need about five users to uncover most problems. One average user finds roughly 31% of the issues. By five users you’ve seen about 85%. By fifteen you approach 100%, but with sharply diminishing returns.

The practical takeaway isn’t “run one big study of fifteen.” It’s to run three small studies of five, fixing problems between each round. Iteration beats sample size, because after the first five you mostly keep seeing the same issues.

How to actually run one

• Give a realistic task, not a tour: “Set up a product and get a price for 500 business cards.”
• Stay silent and watch. The hardest skill is not helping. Don’t answer their questions, don’t rescue them. Their getting stuck is the data.
• Use the think-aloud method: ask them to narrate their thoughts out loud as they work.
• When they go quiet, wait ten to twenty seconds, then prompt neutrally: “What are you thinking?” Silence usually means reading or deciding, which is valuable.
• Ask only behavioral questions: “What did you expect to happen there?” Never “Did you find that confusing?” or “What would you change?” Both are leading.

Observation and contextual inquiry: go to their world

The richest method of all is to watch people do their real work in their real environment.

This is sometimes called contextual inquiry: observation blended with a gentle, on-site interview. It surfaces the workarounds and habits people never think to mention because, to them, they’re just “how things are.”

It runs on a master-apprentice model. The user is the master of their craft. You’re the apprentice who learns by watching and quietly asking, “Why did you do that?”

Consider the famous milkshake study, associated with Clayton Christensen and Bob Moesta. A fast-food chain discovered that a large share of its milkshakes were bought before 8:30am by solo drivers who took them to go. The “job” the shake was hired for wasn’t dessert. It was making a long, boring commute less dull and holding off hunger until lunch. A thick shake lasts about twenty minutes through a straw, beating a banana or a bagel.

Only observation revealed that. Asking “How do we make our milkshake better?” never would have.

The same logic applies anywhere. Skip the video call once in a while and sit in a print shop for a morning. You’ll watch the owner juggle the counter, the phone, a half-finished proof, and a paper price book, re-quoting repeat jobs from memory and losing orders to slow turnaround. That tells you the real opportunity is fast quoting and reordering, not a fancy online designer. No interview would surface it.

Surveys, analytics, tickets, and recordings: support, never lead

These tools tell you how many and where, but never why. Lead with talking to people, then use numbers to confirm and size what you found.

• Surveys scale well for confirming a pattern you already discovered. They’re weak starting points: you can only ask about what you already thought of, there’s no follow-up, and self-reports suffer the same “people misremember” flaw.
• Analytics show behavior. A funnel where 70% abandon checkout proves a problem exists, not its cause. Pair it with watching five users to learn why.
• Support tickets are a free, standing stream of real problems in the user’s own words. Cluster them by theme; the most frequent and most emotional clusters point to the biggest pains. Steal that exact wording for your interface copy.
• Session recordings show rage-clicks and dead-end clicks, revealing where people get stuck without scheduling anything. You still need an interview for why.

The simplest way to hold this in your head: qualitative methods like interviews and observation discover and explain. Quantitative methods like surveys and analytics confirm and size. Don’t lead with numbers.

Common misconceptions

• “More users means better research.” For qualitative testing, five users per group catches most problems. The “five users” rule is for watching people, though. If you need statistics, you’ll want closer to forty.
• “If they say they’d buy it, that’s validation.” It isn’t. Only commitment of time, reputation, or money counts.
• “The user got confused, so they’re not very smart.” When a user struggles, the design is at fault, not the person. Don Norman called the everyday version of this a “Norman door,” the kind you push when you should pull. If an owner can’t find your “save price” button, that’s a design bug to fix, not a user to blame.
• “Asking what people want is research.” People are poor at predicting their own behavior. Ask what they did, not what they would do.

How to use this

Here’s a generative, Mom-Test-compliant interview script you can run today. The example imagines a print-shop owner, but the shape works for any user.

1. “Walk me through the last time you had to quote and produce a big custom order. What happened, step by step?” (past and specific)
2. “What was the hardest or most annoying part of that? Why?” (surfaces real pain)
3. “What did you do to work around it?” (reveals the current solution and its cost)
4. “How much does that problem cost you, in time, money, or lost customers?” (tests whether the pain is serious)
5. “The last time it happened, what did you try to find or buy to fix it? What happened?” (tests real demand without pitching your idea)

Close by asking for an introduction to one other person in their world. That small commitment signals the conversation was real.

And steer clear of these traps:

• Pitching your idea instead of asking about their life. It instantly triggers compliments.
• Leading questions: “Wouldn’t it be great if…?”, “Don’t you hate when…?”, “Would you use X?”
• Asking about the future (“Would you pay $X?”) instead of the past (“What did you pay last time?”).
• Treating compliments and fluff as validation, talking more than you listen, and filling silences.
• Only interviewing friendly, easy users and skipping distinct groups, like an owner versus their walk-in customer.
• Hearing what you want to hear, and forgetting to record people’s exact words.

Conclusion

If you remember one thing, make it this: what people do is the truth; what people say is a hope. Build your research around stories that already happened and behavior you can watch with your own eyes, and the flattery problem solves itself.

There’s a deeper question waiting on the other side of all this. Once you’ve gathered a pile of honest observations, how do you turn scattered quotes and behaviors into a single insight your whole team can rally behind? That’s the craft of synthesis, and it’s where good research becomes great product sense.