The Mom Test Explained for Solo Founders

A founder I've been following for two years just ran her first real customer interview. She spent ninety minutes asking questions, took three pages of notes, and walked away saying the most useful sentence I've heard from her all year: "I have been solving a problem nobody described in those words."

That sentence is the entire reason this article exists.

She had spent the previous eleven months writing code for a workflow she assumed her customers used. She had not asked them. Not because she didn't intend to — interview prep was always on next week's list — but because nobody had told her, in a way she believed, that the interview itself is the work. The product is not the work. The product is the output of the work. The work is the conversation.

I've heard versions of this story from a few other solo founders since. Some had run a customer interview and ignored the signal. Some had run zero. The pattern is consistent enough that you can name the failure mode before the founder finishes the sentence: someone told them their idea was good, and they treated the encouragement as evidence.

Rob Fitzpatrick's The Mom Test (2013, self-published; revised edition 2018) is the shortest, most useful book on that conversation. It is nineteen pages long and has saved me, conservatively, six months of building things nobody asked for. Every customer-discovery article on this site — including the pillar on finding first customers — borrows from it. This article is the long-form distillation: the rules, the questions, the failures, and a script you can run this week.

If you've ever come back from a "great conversation" feeling encouraged, then watched nothing happen — this is the article that explains why.

Key takeaways

• The Mom Test's three rules: (1) talk about their life, not your idea; (2) ask about specifics in the past, not generics or hypotheticals about the future; (3) talk less and listen more. Each rule solves a specific failure mode that polite-audience interviews produce.
• "Would you buy this?" is a useless question. People lie to be kind. They will say yes to almost any pitch delivered by someone they like, in a context where disagreeing would be awkward. You cannot build a six-month decision on the answer.
• The only question that matters is whether they have a problem, and what they've already done to solve it. "Tell me about the last time this came up" + "what did you do?" + "how much did it cost?" is the entire interview compressed to three sentences.
• You are looking for commitments and consequences, not compliments. A compliment is free. A spreadsheet the customer built last Tuesday is real evidence. A competitor they already pay $400/month for is real evidence. Someone introducing you to a colleague is real evidence.
• Five interviews is enough to learn something. Eight is enough to find a pattern. Twelve is enough to write a confident summary. More than twelve is rarely worth it before you've shipped an MVP.

Quick answer

The Mom Test is the rule that you should never ask people whether they would buy your product, because they will lie to be polite, and instead ask them about the last time they tried to solve the problem your product would solve. It was written by Rob Fitzpatrick in 2013 and revised in 2018. The book's three rules are: talk about your customer's life, not your idea; ask about specifics in the past rather than opinions about the future; and talk less than you think you should. The book is 19 pages long and has been cited by Y Combinator, Lenny's Newsletter, and most modern customer-discovery writing as the canonical short reference on the topic. For a solo founder without research staff, it is the single most useful piece of customer-discovery literature in existence.

Why this matters

The single largest cause of failed indie launches is not a bad idea. The most common pattern I see is a founder who talked to a few friends, got encouraging noises, and treated those noises as validation. Friends are polite. Strangers at meetups are polite. People on Twitter are polite. Polite people say "yeah I'd use that" with the same enthusiasm they say "yeah I'll come to your birthday."

The reason this matters more in 2026 than it did in 2013 is the volume. A solo founder in 2013 had maybe forty early conversations to choose from. A solo founder in 2026 has access to thousands of strangers through Reddit, Slack communities, LinkedIn, Discord, and X — and the same percentage of those strangers are polite. The signal-to-noise ratio is worse, not better, because the channels make it easy to mistake reach for evidence.

A real interview takes thirty minutes and produces one useful observation. A polite conversation takes five minutes and produces one piece of misinformation. The discipline is to convert as many of the second into the first as possible.

What is The Mom Test?

The Mom Test, by Rob Fitzpatrick, is a short book (originally published in 2013; revised edition 2018) on how to have customer conversations without lying to yourself. The title comes from a simple rule: if you wouldn't be comfortable telling your mom your idea and trusting her honest reaction, you are not asking a real question — you are pitching, and her positive answer is not data.

The book's argument is that most "customer research" in startups is not research. It is a sequence of leading questions designed to elicit the answer the founder wants. The founders who run this kind of research get the answer they want, and then are surprised when the product doesn't sell. The founders who learn to ask real questions get answers that hurt in the short term and save them months in the long term.

Three rules hold the whole book up:

1. Talk about their life, not your idea. A conversation about the customer's day, their workarounds, and the tools they already pay for produces evidence. A conversation about your product produces compliments.
2. Ask about specifics in the past, not generics or hypotheticals about the future. "How many times did this happen last month?" produces a number. "Would you use a tool that did X?" produces a guess, and the guess is almost always optimistic.
3. Talk less and listen more. The founder's job in an interview is to ask the next question, not to explain the next slide.

Everything else in the book — the question scripts, the warning signs, the "advance commitments" concept — is downstream of these three.

Steve Blank's The Four Steps to the Epiphany (2005) covers similar ground at greater length for enterprise software companies. Cindy Alvarez's Lean Customer Development (2014) extends the framework to product teams. The Mom Test is the shortest version, and the one best suited to a solo founder who needs to learn it in an afternoon.

Why most founders ask bad questions

The pattern is consistent enough to name.

A founder decides on an idea. They open a Google Doc. They write a paragraph describing the product. They open Twitter, find five people who might plausibly be their customer, and send a short message: "Hey, I'm building X. Would you use it? Would you pay for it? Quick call this week?" Four of the five say yes. The fifth is busy. The founder takes the four yeses as evidence, builds for eight months, launches, and gets two paying customers.

The mistake is in the question. "Would you use a tool that did X?" is unanswerable honestly. The person on the other end of the message is not your customer — they are a stranger being asked to evaluate a hypothetical. They have no skin in the game. Saying yes costs them nothing. Saying no might end the conversation or feel rude. So they say yes.

This is what Fitzpatrick calls the "three bad answers" problem. Almost any question about the future produces one of three responses:

• Compliments. "That sounds cool." This is what nice people say. It tells you nothing about your idea.
• Hypotheticals. "Yeah I would probably use that." Hypotheticals are not commitments. People who "would probably" use something almost never do.
• Flat lies. "Yes, definitely." A stranger who has never paid for anything like this is telling you they will pay for it. The lie is not malicious — it is social.

The test of whether your question is good is whether it could produce a "no" you'd believe. If the question cannot produce a believable no, it cannot produce a believable yes.

How to run a good customer interview

The structure of a good interview is short, predictable, and almost mechanical once you've done it twice.

Before the call

Write down the three to five assumptions you most need to test. The point of an interview is not to be polite — it is to learn whether those assumptions hold. Common ones:

• That the person has the problem often enough that solving it would change their week.
• That they have already tried to solve it (with a workaround, a paid tool, or time spent).
• That they are reachable through a specific channel.
• That they have budget to pay for a solution.

Pick the three whose truth would change your plan the most. The interview tests those.

During the call (25–30 minutes)

First three minutes: set the rules. Don't pitch. Tell them: "I'm not selling you anything. I want to ask about how you handle [problem domain] today. There are no wrong answers and I'd rather hear the truth than anything nice. Can we talk for 25 minutes?" This single sentence does most of the work. Most strangers will relax.

Next twenty minutes: ask about their life. The opening question is: "Tell me about the last time [problem] came up. What did you do?" Then:

• "How often does this happen?"
• "What did it cost you — in time, money, or stress?"
• "What did you try before this? What worked, what didn't?"
• "If you could wave a magic wand and change one thing about how you handle this, what would it be?"

The order matters. The opening question gets the story. The follow-ups get the structure.

Last five minutes: ask for commitment. The closing question is the most underrated. "Is there anyone else I should talk to about this?" If they introduce you to a colleague, they have just vouched for the relevance of the conversation. If they say no, that's information too.

After the call

Within an hour, write down: one thing you learned that you didn't already know; one thing that surprised you; one thing you want to test next. These notes are the output. The conversation was the cost. Most founders skip the notes and then forget what they heard.

Examples of good questions

The good questions share one trait: they could produce a believable no.

"Tell me about the last time this came up. What did you do?" This is the canonical opener. It forces a specific story from a specific day. The story will include workarounds, costs, and emotional valence — exactly the data you need.

"How often does this happen — daily, weekly, monthly?" Specific frequencies are the strongest signal that a problem is real. "Every Tuesday" is real. "Sometimes" is not.

"What have you already tried? What worked, what didn't?" This question is gold. People who have already tried three things have a real problem. People who haven't tried anything probably have a hypothetical one.

"How much does this cost you today — in time, money, or frustration?" Quantified cost. The more specific, the better. "About three hours a week" beats "a lot."

"Who else feels this pain?" This is your channel-narrowing question. If they say "everyone at my company," you have a B2B product. If they say "me and maybe two friends," you have a small wedge.

"What's the worst part about how you handle this today?" The "worst part" framing surfaces the part of the pain your product actually has to solve.

"If we were three years into the future and this problem was solved, what would be different?" A future-projection question is fine after you've established the past. Without the past, it's a hypothetical. With the past, it's a forecast from someone who has lived the problem.

Examples of bad questions

The bad questions all share a different trait: they could only produce a yes.

"Would you use a product that did X?" The most common founder question. The answer is almost always yes, because refusing is rude. Fitzpatrick calls this the worst question in startup-land, and he is right.

"Do you think this is a good idea?" They have known you for the length of one email. Their opinion is worth exactly what you'd expect.

"How much would you pay for this?" In isolation, this question produces guesses that are usually 2-3x what people actually pay. It is only useful after you have established they already pay for a workaround at a known price.

"Would you be interested if I built it?" Polite interest is not payment. The question confuses enthusiasm with intent.

"What features would you want?" People are good at describing their problems and bad at describing solutions. If you ask this question first, you will end up building a feature list full of items that solve problems you don't have evidence for.

"Can I show you a mockup and get your feedback?" Showing a mockup before you've earned the right to ask questions is a pitch disguised as research. The mockup will do the talking. The customer will tell you what you want to hear.

"Would you sign up for a free trial?" Free trials are not payment. A yes to a free trial tells you the customer is curious, which is roughly equivalent to knowing nothing.

"Do you know anyone else who might want this?" This question is okay as a closing, after they've told you about a real problem. Asked cold, it produces nothing useful.

Common mistakes

Most interview failures fall into a small set of named patterns.

Treating polite agreement as evidence. The single most common mistake. A founder runs five interviews, gets four yeses, builds for eight months, and is confused when nothing converts. The four yeses were never evidence. The pattern is consistent enough that you should treat any interview response that could not have been a believable no as zero data.

Talking more than the customer. The first instinct of a founder who has spent three weeks thinking about the product is to explain it. The interview is not the place. The interview is for the customer to talk. A good rule: if you have spoken for more than 30 seconds, you are pitching, not interviewing.

Asking leading questions. "Would you use a tool that automated the thing you just said you do manually every week?" You have already put the answer in their mouth. They are now agreeing with you, not telling you the truth.

Falling in love with one enthusiastic answer. One founder I know ran an interview where the customer said "I would pay $500/month for this tomorrow." He built for two years on the back of that quote. The customer never paid. The quote was enthusiasm, not commitment. Real commitment looks like: introducing you to a colleague, scheduling a follow-up, sending you a document about their workflow. Words without a follow-up are not commitments.

Skipping the interview to build. "I'll build the MVP and get feedback after" is the most expensive sentence in startups. The MVP you build will reflect your assumptions. The feedback you get will tell you whether your assumptions were right — which you could have learned in five interviews for one-tenth the cost.

Recruiting from the wrong pool. If you interview other founders, you will learn what other founders think. If you interview your friends, you will learn what your friends think. The interview pool must be people who would actually pay, or at least who have the problem. Filter accordingly.

Stopping too early. The interview that changes your mind is rarely the first. Most founders stop after two or three because they're getting answers they like. The interesting interview is the seventh, when the pattern is clear enough to argue with.

Stopping too late. The flip side: running fifty interviews before shipping anything is also a failure mode. Interviews are for learning, not for postponing. Five to twelve is the productive range. Past that, you're collecting confirmation for a decision you've already made.

A practical checklist

Run these before, during, and after the interview.

Before

• Write down the three assumptions this interview is meant to test.
• Confirm the person actually has the problem. Not "might have" — actually has.
• Prepare three open-ended questions. Memorise the opening one.
• Decide whether you'll record. Ask permission. Most say yes.

During

• Set the rules in the first three minutes: not selling, no wrong answers, 25 minutes.
• Ask about specifics in the past. If they say "I would probably," redirect to a specific day.
• Listen for the three signals: commitments, consequences, and follow-ups.
• Stay quiet for two seconds after they finish answering. The next sentence is usually the most useful.

After

• Write down one new fact within an hour.
• Note the most surprising thing they said.
• Decide: do they have the problem (yes/no)? Have they tried to solve it (yes/no)? Have they paid anything to solve it (yes/no)? Those three yeses are the strongest signal you can collect.
• If they offered an introduction, send the follow-up within 24 hours.

How many interviews are enough

The honest answer is "when you stop hearing new things." That is usually between five and twelve.

Five interviews. You will learn whether the problem is real for more than one or two people. If three of five have the same workaround, you have something.

Eight interviews. Patterns emerge. You can start to write down themes.

Twelve interviews. You have enough to write a one-paragraph summary that an outside reader would find convincing.

More than twelve is rarely useful before you have shipped something. Past twelve, you are usually collecting confirmation for a decision you've already made, or stalling because you are afraid to ship.

The number matters less than the composition. Five interviews with the right people is more useful than fifty with the wrong people. The right people are people who have the problem often enough that they have built a workaround.

How The Mom Test connects to the rest of the validation work

The Mom Test is the conversation layer of a broader validation sequence. It pairs with three other pieces:

• Problem interviews (what this article covers) — confirming the problem is real and felt.
• Solution interviews — once you've sketched a possible solution, testing whether the solution actually solves the problem. Different questions, same rules.
• Pricing and willingness-to-pay tests — confirming that the problem is real enough that money changes hands. Money is the only test of money.

The full sequence lives in the Startup Validation Checklist. The Mom Test is the first half — the conversations that come before you have anything to show.

Worked example

A solo founder I know spent four months building a scheduling tool for independent tutors. She had used one herself for two years. She assumed the problem was universal. She ran five interviews in week one using the script above.

Interview 1: Tutor with 12 students. "I schedule everything in a Google Sheet and send texts manually. Last Tuesday I double-booked and had to email two parents to reschedule. It was embarrassing." Real problem. Real workaround. Real cost.

Interview 2: Tutor with 8 students. "I use Calendly. It works. I don't love it but it works." Real problem, but already solved by something good enough. The founder learned that her ICP was "tutors who don't already use Calendly" — a smaller market than she thought.

Interview 3: Tutor with 30 students. "I have an assistant who handles all of it. She uses Calendly and a spreadsheet. If I lost her I'd be in trouble." Real problem, but not one this tutor would pay to solve herself. Different ICP.

Interview 4: Tutor with 6 students. "I don't really have a scheduling problem. Parents text me and I write back." No problem.

Interview 5: Tutor with 18 students. "Calendly works for booking but I lose two hours a week tracking who paid. That's the part I hate." Real problem, but not the one the founder was solving. The founder's product was about scheduling, but the customer's pain was about billing.

The interviews changed her plan. She stopped building scheduling features and started building the billing tracker that the last tutor actually wanted. Six months later that tutor was her first paying customer, and three of the five she interviewed had pre-ordered. None of that would have happened if she'd asked "would you use a scheduling tool?"

The pattern: real problems emerge from the workarounds. The workaround reveals both the problem and the part of the problem that is most painful. Listen for the workaround. Build for the workaround.

FAQ

How long should a customer interview be?

Twenty-five to thirty minutes. Shorter than that and you won't reach the specifics that produce real signal. Longer than that and the customer will start being polite again — they'll say whatever ends the call fastest.

Should I record the interview?

If the customer agrees, yes. The transcript lets you re-read what they actually said, not what you remember they said. Memory edits. If they don't agree, take detailed notes — but write down the quotes verbatim, not your summary of them.

What if the customer is busy or uninterested?

Treat it as data. If the person you thought was your ICP won't spend thirty minutes with you, the channel might be wrong, the framing might be wrong, or they might not have the problem often enough to care. Adjust. Don't argue.

Can I do interviews by email or chat instead of video?

Yes for some questions, no for others. Async text is fine for factual questions ("how often does this happen"). It is bad for questions that require the customer to be vulnerable ("what does it cost you in frustration"). Video or phone is the default.

How do I find people to interview?

The discipline is to find people who already have the problem, in the rooms where they already are. The full playbook is in How to Find Your First Customers Before You Build. The short version: Reddit, Slack/Discord communities, LinkedIn (for B2B), and direct outreach to people who post about the problem publicly. Cold email works if the message is short and the question is specific.

What if I get conflicting answers?

Conflicting answers are the most useful kind. They mean there are at least two segments inside what you thought was one audience. Your job is to find the segments, not to average them.

What if I can't tell whether the answer is real or polite?

A useful test: would they have said the same thing to a stranger they had no interest in being polite to? If the answer would change based on the relationship, it's polite. If it would not, it's real. People who say "I'd use that" to a stranger are being polite. People who say "I lose two hours a week and it's killing me" are being real, regardless of who they are talking to.

Is The Mom Test still relevant in 2026?

The principles are. The channels have changed — Fitzpatrick wrote before Slack communities, before Discord, before the modern stack of niche forums. But the underlying discipline (talk about their life, not your idea; specifics in the past, not the future; listen more) is unchanged. AI makes it easier to find and summarise interviews. AI does not make the conversations easier or less necessary.

What if my idea doesn't have an obvious existing workaround?

Then it's probably not a real idea yet. The workaround is the evidence that the problem is real. If you can't find one, the problem might not exist. That is a useful answer too — better to find that out now than after six months of building.

Summary

The Mom Test is the rule that customer conversations should be about the customer's life, not your idea. It was written by Rob Fitzpatrick in 2013 to solve a specific failure mode: founders running polite conversations that produce no evidence and then building for eight months on the resulting misinformation. The book's three rules — talk about their life, ask about specifics in the past, listen more — are the shortest path to a customer interview that produces real signal.

The practical version is a 25-minute conversation with a person who has the problem, structured around "tell me about the last time this came up" and "what did you do about it" and "how much did it cost." Five such conversations, with the right people, is enough to learn whether the problem is real and felt. Twelve is enough to write a confident summary. Past twelve, you are stalling.

If you only do one thing after reading this article, send a message today to a stranger in your target market. Ask them about the last time they had the problem you're trying to solve. Listen for the workaround. Notice whether the answer is real or polite. Use that answer to decide what to do next week.

Next step

Apply the customer-discovery lens to your specific idea and ICP. Run a free Startup MRI analysis — the report returns the highest-signal channel and the assumption most worth testing in five minutes, with a per-dimension breakdown that names who to talk to first and which conversations matter most. The conversations in this article are still the work; the analysis just points you at the right room before you spend the next two weeks looking for it.

Related reading

• The Startup Validation hub — the canonical starting point for every pillar in this publication.
• Problem-Solution Fit Validation — the rung this conversation discipline produces evidence for; workaround analysis is what the polite-yes problem hides.
• How to Find Your First Customers Before You Build — the broader customer-discovery playbook this article fits into.
• Distribution Channels Ranked for Solo Founders — the second half of the funnel: once you have a real, validated problem, this article picks the channel.
• The Glossary — the vocabulary of validation, including customer discovery, problem interview, and ideal customer profile.
• How to Test Whether People Will Pay Before You Build — the willingness-to-pay pillar that pairs with customer interviews.
• Startup Validation Checklist — the full validation sequence, with The Mom Test as the customer-research stage.
• Why Founders Build Before They Validate — the founder-psychology piece on why the conversations in this article get skipped.