Reading The Mom Test

Recently I made notes on a classic little book: The Mom Test.

It isn’t a new book, nor some complicated theory.

But I think it’s very much worth rereading today, especially for indie developers, product managers, designers, or anyone building products with AI.

Because AI makes “building it” easier and easier.

But a more dangerous problem comes with it:

we may be building something nobody needs, faster and faster.

1. What is this book about?

The Mom Test is by Rob Fitzpatrick.

Its subtitle says, roughly:

how to talk to customers and learn if your business is a good idea when everyone is lying to you.

Why is it called the Mom Test?

Because the author’s point is:

if you ask your mom,

“Is my startup idea any good?”

she’ll most likely say yes.

Not because she’s really assessed the market, but because she loves you and doesn’t want to hurt you.

But what the book really wants to say isn’t “don’t ask your mom.”

It’s:

don’t ask anyone whether your idea is good.

Because that’s a bad question to begin with.

Ask a bad question, and naturally you get a useless answer.

2. The book’s core idea

The core of The Mom Test is actually simple:

don’t talk about your idea; talk about what actually happened in the other person’s life.

When doing user interviews, many people instinctively ask:

“What do you think of this product?” “If I built it, would you use it?” “Would you pay for it?” “Isn’t this feature really useful?”

These questions sound natural, but almost all of them are dangerous.

Because users may give you a positive-sounding answer out of politeness, encouragement, imagination or social pressure.

And those answers aren’t real demand.

Someone saying “I’d use it” is a different thing from them actually running into the problem in their life, actively looking for a solution, even being willing to pay for one.

3. What makes a good question?

The Mom Test encourages questions like:

• When was the last time you ran into this problem?
• What happened then?
• How do you deal with it now?
• What did this problem cost you?
• Have you tried other ways of solving it?
• Have you ever spent money on this problem?
• If it goes unsolved, what do you usually do?

What these questions have in common:

they ask about what actually happened in the past, not imagined attitudes about the future.

Because promises about the future are cheap.

Past behavior is closer to evidence.

A user saying:

“This feature is pretty good.”

carries very little information.

But if they say:

“Last month I spent three hours sorting this out by hand, and I even paid for a template, but I didn’t stick with it.”

that’s far more valuable.

You start to learn:

whether the problem is real; how often it happens; how much it hurts; how users currently work around it; whether they’ve already spent time, money or effort on a solution.

4. Why does it matter more now?

Because today’s indie developers are easily accelerated by AI.

It used to be slow to build a demo, so you might have been forced to think things through first.

Not anymore.

With AI you can quickly make:

• a landing page;
• forms;
• a dashboard;
• an app prototype;
• an automation workflow;
• small tools;
• copy and visual packaging.

That’s a good thing, of course.

But it also means you may have built something that “looks like a product” before you’ve validated the problem.

So the question shifts from:

“Can I build it?”

to:

“Does anyone actually need this?”

That’s where The Mom Test earns its keep.

It reminds us not to comfort ourselves with “users said they like it.”

Look at whether users are already paying a price for this problem in real life.

5. The most important advice for indie developers

First, don’t ask “would you use it”

Questions like that usually get polite answers.

A better way to ask:

“When was the last time you ran into this problem?”

If they can’t remember, the problem may not hurt as much as you think.

Second, don’t rush to introduce your product

Once you start explaining your solution, they start evaluating you instead of talking about their real life.

In the first half of a user interview, it’s best not to pitch.

First understand:

how they do it now; what’s annoying about it; whether there are alternatives; whether there’s a real cost; whether they’ve ever tried to solve it themselves.

Third, listen less to opinions and watch behavior more

Opinions float easily.

Behavior is closer to fact.

“I think this is pretty useful” is worth less than “I just did it by hand yesterday.”

“I’d be willing to pay” is worth less than “I’ve already bought a similar tool.”

“I wish it had this feature” is worth less than “without this feature, here’s how I work around it now.”

Fourth, look for commitment, not compliments

A compliment is praise.

A commitment is a promise and an action.

For example:

• willing to book another in-depth conversation;
• willing to introduce other relevant users;
• willing to join a waitlist;
• willing to try it;
• willing to pay in advance;
• willing to bring real material to test with;
• willing to put it into their own workflow.

What users do matters more than nice words.

Fifth, treat “bad news” as good news

I think this one is very important.

Many indie developers doing user interviews aren’t actually looking for the truth; they’re looking for confirmation.

Hoping users will say:

“This idea is great.” “I have this problem too.” “If you build it, I’ll definitely use it.”

But what’s truly valuable is often the bad news:

users don’t actually feel the pain; users already have a cheap alternative; users don’t want to change their existing process; users don’t think the problem is worth paying for; users like it in words but won’t commit to the next step.

None of that sounds nice.

But it can save you months of waste.

6. This book should also be read with care

The Mom Test is very valuable, but it isn’t a universal formula either.

First, it’s better for exploring problems; it isn’t full user research

It’s great for early validation:

whether the problem exists; whether users care; how they solve it now; whether there are signs of payment or investment.

But it can’t replace every research method.

If you want to study usability, information architecture, emotional experience or how a brand feels, you may also need usability testing, prototype testing, data analysis and long-term observation.

Second, not every user can clearly describe what they really need

Users are very good at telling you what happened in the past.

But not necessarily good at summarizing what they truly need.

So an interview isn’t about having users design the product for you.

You have to distill patterns from their behavior and pain points.

Users provide the raw material.

Product judgment is still your responsibility.

Third, early interviews are prone to sampling bias

The people easiest for you to talk to are often friends, peers, your own bubble, or people inclined to support you.

They may not represent the real target users.

So don’t assume the market exists because three people said “looks good.”

And especially don’t mistake friends’ encouragement for the product being validated.

7. Takeaways for people working in the field

This book isn’t only for indie developers.

It’s just as useful for product managers, designers, founders, even content creators.

Because we all easily ask leading questions:

“Do you like this direction?” “Isn’t this feature more convenient?” “Is this page clear to you?” “If we added this capability, would you use it?”

What’s wrong with all of these:

they ask the other person to evaluate your solution.

A better question goes back to their real situation first:

• How do you deal with this problem now?
• When was the last time?
• Where did you get stuck?
• What alternative did you use?
• What happens if this problem isn’t solved?
• Have you spent time, money or favors on it?

In product work, what really matters isn’t getting users to say they “like” it.

It’s seeing whether there’s already a strong enough pull in their lives.

8. My own take

If Build to Last reminds me:

don’t build a system you don’t understand yourself,

then The Mom Test reminds me:

don’t build a product users only politely like but don’t actually need in real life.

In the AI era, both matter more.

Because we can build faster.

So it’s also easier to make mistakes faster.

It used to take months to build the wrong product.

Now, with AI, building the wrong product may take only days.

So the most important skill for an indie developer isn’t just prompting, isn’t just coding, and isn’t making the interface beautiful.

It’s:

asking questions closer to reality before you start building.

When users say “looks good,” keep asking:

“When was the last time you actually ran into it?”

When you badly want to be validated, still being willing to hear bad news.

That’s the most brutal and most valuable thing about The Mom Test:

don’t let your users’ politeness become your product illusion.