- Published on
Your Customers Are Lying to You (And It's Your Fault)
- Authors
- Name
- Andrew Blase
The Mom Test is the shortest path from "I think people want this" to "people are paying for this." Here's what it says, why it matters, and how to use it before you build the wrong thing.
For technical solo founders, this is the customer-discovery layer of the broader business education solo founders need: learn the market before you spend months building.
The Problem Every Technical Founder Has (Before They Know They Have It)
You built something. You showed it to people. They said it was interesting. They said they'd use it. A few even said they'd pay for it.
Then you launched. And nobody came.
This is not a marketing problem. It is not a positioning problem. It is a research problem — specifically, the problem of asking the wrong questions.
Rob Fitzpatrick wrote The Mom Test to name this trap and hand you a way out. The core argument fits in one sentence: people will lie to you about your product not because they're dishonest, but because they're polite. Ask your mom if your startup idea is good. She'll say yes. She loves you. She doesn't want to crush your dream.
The problem is that everyone behaves like your mom when you ask them about your ideas.
What The Mom Test Actually Is
The Mom Test is a set of rules for customer conversations that makes it impossible for the person you're talking to to lie to you, even if they want to.
The title comes from a test Fitzpatrick proposes: your questions should be so grounded in facts and past behavior that even your mom couldn't give you a false positive.
The three core rules:
Rule 1 — Talk about their life, not your idea. The moment you describe your product, the conversation is over. The person shifts into politeness mode — they are now managing your feelings, not giving you signal. Ask about their workflow, their frustrations, what they tried last time this problem came up.
Rule 2 — Ask about the past, not the future. "Would you use this?" is a useless question. "How did you handle this last time it happened?" is a useful one. Past behavior is real data. Future intention is a wish. The only thing that matters is what people have already done.
Rule 3 — Listen for actions, money, and time — not compliments. "That's really cool" is not validation. Someone saying "I've been trying to solve this for six months, I've tried three tools, none of them work" is validation. Someone showing you the spreadsheet they've been maintaining manually to work around the gap is validation.
Why Technical Founders Get This Exactly Backwards
Most technical founders validate by pitching. They describe the product, the person nods, they call it "user research." This is the most expensive mistake in early-stage product building.
It is also why technical founders struggle with marketing: they lead with the product before they understand the customer's language, urgency, and buying context.
There are three specific failure modes:
The pitch disguised as a question. "What would you think about a tool that automatically [the thing you've already built]?" You're not asking a question. You're asking for a compliment.
The hypothetical future trap. "If we added X, would you use it?" This feels like product research. It is not. Nobody knows what they'd do in a hypothetical future. They know what they did last Tuesday. Ask about last Tuesday.
Talking to the wrong people. Most founders talk to people who are easy to reach rather than people who have the problem. Friends, colleagues, warm intros. These people are invested in you. They will say kind things. Find strangers with the problem.
How to Find Customers Who Actually Want to Buy
The book's most practical insight is that validation happens before you ask anyone about your product. You're looking for evidence that a problem is real, painful, and unsolved — not for someone to say "yes" to your solution.
Here is the sequence:
Start with the problem narrative, not the product. "We're trying to understand how developers manage AI agent observability across different LLM providers" reveals far more than "We're building an LLM routing tool." One invites honest answers. The other invites politeness.
Look for the committed problem-haver. The customer you want is not the person who says the problem is annoying. It is the person who has already tried to solve it, failed, and is either living with the gap or has cobbled together a workaround. They have proved the problem is real with their time and money. A person who has paid for three failed solutions is a thousand times more valuable than one who says "yeah, that'd be useful."
Listen for the budget signal. Even if money isn't discussed, you can hear it. "We have someone dedicated to this" and "we've tried three vendors" are budget signals. "That would be nice" is not.
Get to specifics every time. Generic answers ("it's just a pain to manage") are not useful. Specific answers ("last week I spent four hours debugging why our OpenRouter calls were silently failing before the board demo") are. Train yourself to push for the specific: "Tell me about the last time that happened."
Who to Talk To First
This is where most founders stall. They know they need to talk to customers but they don't know who or how to find them. Fitzpatrick's answer: find people who are already in the problem. Not people who might have the problem. People who are actively living it.
For developer tools and AI products, the fastest paths:
| Channel | How to use it |
|---|---|
| Communities | Reddit (r/SaaS, r/webdev, r/LLM), Discord servers, Hacker News. Don't pitch. Read the threads. Find people posting about the exact problem. Message saying you're researching this specific issue and would love 20 minutes. |
| LinkedIn targeting | Role + industry + company size. Name the specific problem, not your solution. "I'm researching how AI founders handle multi-provider LLM routing" gets replies. "I'm building a tool that helps with LLM routing" does not. |
| Warm network | Use your network for one thing: introductions to people you don't know. "Do you know any technical founders struggling with [problem]?" is the right ask. |
| Public complainers | Find Twitter threads, blog posts, Hacker News comments about the problem. The person who wrote a detailed breakdown of why existing tools fail at X is your ideal first conversation. They've already done your research for you. |
The number to aim for: 10 to 20 conversations before you write a line of code. Not 3. Not 5. Twenty conversations will surface patterns that one or two never will.
The Conversation Itself: What to Say and What to Listen For
You have 20 minutes. Here is how to use them.
Open with context and permission:
"I'm trying to understand how teams like yours handle [problem area]. I'm not pitching anything — I want to understand your workflow before we build anything. Can you tell me about the last time you ran into [problem]?"
Follow the thread. When they describe something specific, ask "how did you handle that?" When they describe a workaround, ask "how long has that been the solution?" When they express frustration, ask "have you tried to fix it?"
Listen for these five things:
- The specific moment the problem appears
- What they've already tried
- What they're currently doing instead (the workaround)
- What it costs them (time, money, embarrassment, missed opportunity)
- Whether they've told anyone else — this signals how important it is to them
End with one question: "Is there anything I should have asked that I didn't?" This surfaces the thing they wanted to tell you but couldn't find an opening for.
What you're NOT doing: pitching, demoing, validating features, asking "would you pay for this." The goal is a map of the problem, not a vote on your solution.
What Changes When You Read The Mom Test
| Before | After |
|---|---|
| Customer discovery = getting people excited about your idea | Customer discovery = getting out of the way and letting people tell you what's real |
| "Do you find X frustrating?" | "Tell me about the last time X happened." |
| Counting enthusiasm as signal | Counting commitments — time, money, introductions |
| Scheduling discovery calls after you've already built the thing | Having conversations before you've committed to anything |
| Talking to people who'll be nice | Finding strangers with the problem |
The book is under 150 pages and reads in three hours. The cost of not reading it is building a product nobody wants, which costs considerably more.
The Real Test Your Idea Has to Pass
Before you close the next customer call, ask yourself three questions:
- Did I learn anything that could change what I'm building?
- Did they tell me about specific past behavior, not future intention?
- Did I hear any signal beyond politeness?
If the answer to any of those is no, the call didn't count.
The Mom Test is not a book about talking to customers. It is a book about designing conversations that produce truth instead of encouragement. Every developer-founder who has burned six months shipping the wrong feature would trade anything to have read it in month one.
Stop Building in the Dark
If you're building a product and you haven't read The Mom Test, you are making decisions based on politeness rather than evidence.
The book costs $10 and three hours. What's your current burn rate?
Read The Mom Test this week. Then go have ten conversations using what you've learned — before writing a single line of code or scoping a single feature. At Full Stack Data Solutions, we build systems that automate the marketing side once the customer signal is real. But the signal has to come first. Follow us on LinkedIn for more frameworks on building AI products that actually ship to paying customers.