The Mom Test is a set of rules for asking questions that even your mom can't lie to you about. The name comes from Rob Fitzpatrick's book. The idea is simple: stop asking questions that invite polite lies.
The problem with most interview questions
Most people who run customer interviews make the same mistake: they ask questions that sound reasonable but actually invite dishonesty. Not malicious dishonesty. Just the polite kind. The kind where someone tells you what they think you want to hear.
"Would you use something like this?" Almost everyone says yes. It costs nothing to say yes. It makes you feel good. And it tells you nothing about whether they'd actually pay for it or change their behavior.
The Mom Test offers a different approach: ask about the past, not the future. Ask about behavior, not opinions. And never mention your idea until you've learned what you came to learn.
Three rules for better questions
The Mom Test boils down to three principles. They're easy to understand and surprisingly hard to follow in the moment.
1. Talk about their life, not your idea
The moment you pitch your idea, the conversation shifts. People start reacting to your idea instead of telling you about their reality. Keep the focus on them.
Instead of: "Would you use an app that helps you track expenses?"
Ask: "How do you currently keep track of your expenses?"
2. Ask about the past, not the future
People are bad at predicting their own behavior. They're much better at describing what they've already done. Past behavior is the best predictor of future behavior.
Instead of: "Would you pay for this?"
Ask: "What have you tried to solve this? How much did that cost?"
3. Talk less, listen more
If you're talking more than the other person, something is wrong. You're there to learn, not to convince. Every minute you spend explaining is a minute you're not learning.
Questions that actually work
The key is to ask questions that follow these principles. What you ask depends on what you're trying to learn.
When you're trying to understand the problem, start broad: "Tell me about the last time you dealt with [problem]." Then dig into specifics: what made it difficult, how often it comes up, what happens if it doesn't get solved. The goal is to understand whether this problem is real and how much it actually matters.
When you want to learn about their current solutions, ask how they handle things today. What do they like about their current approach? What's frustrating about it? Have they tried anything else? These questions reveal what you're up against — the status quo you'd need to displace.
To find the stakes, ask what this problem actually costs them — in time, money, or stress. Ask if they've looked for a solution before and what happened. Ask why they think this hasn't been solved yet. These questions separate mild annoyances from genuine pain.
Finally, test for commitment. If they say it's a big problem, ask what they've done about it in the last month. Would they be willing to try something new this week? Who else should you talk to about this? These questions cut through polite enthusiasm and reveal actual motivation.
Questions to avoid
Some questions feel productive but rarely are. Watch out for these patterns.
"Would you use X?" — Hypotheticals invite hypothetical answers. Ask what they've done, not what they'd do.
"Do you think this is a good idea?" — You're asking for approval, not information. Most people will say yes to avoid conflict.
"How much would you pay for this?" — Without context, this question is meaningless. Ask what they currently pay to solve the problem instead.
"What features would you want?" — Feature requests often lead you astray. Focus on the underlying problem, not their proposed solutions.
When someone gives you a compliment
Compliments feel good but teach you nothing. When someone says "That's a great idea," redirect back to their experience.
"Thanks. But help me understand — you mentioned you've struggled with this before. What did you try?"
The goal isn't to be rude. It's to keep extracting real information instead of collecting empty validation.
Signals that matter
Not everything someone says carries equal weight. The strongest signal is past behavior: have they spent money on this problem? Have they invested time building workarounds? Can they describe specific instances in detail, or do they speak in vague generalities?
Vague complaints — "it's kind of annoying" — often mean mild annoyance, not urgent problems. Specific stories — "last Tuesday I spent three hours on this" — suggest real pain. And if someone asks when they can buy what you're building, that's worth more than any amount of enthusiasm about the concept.
After the interview
The interview is only useful if you extract the right lessons. Within an hour, write down what they actually did, what they care about, what they've tried, and what they didn't mention. Separate facts from interpretations. "They said the process takes 2 hours" is a fact. "They're frustrated" is an interpretation. Both are useful, but don't confuse them.