The Mom Test

The Mom Test

Asking "would you buy a product that did X?" is a question almost nobody can answer honestly, not because people are dishonest, but because the question rewards a nice answer over a true one.

Your mother, asked whether your new startup idea sounds good, has every incentive to say yes: she loves you, she doesn't want to crush you, and she probably doesn't understand the idea well enough to critique it anyway. She isn't unusual. Everyone you pitch behaves like a version of your mother.

A question passes the Mom Test when it's specific enough, and past tense enough, that even she couldn't lie to you while answering it. "Do you think a subscription box for chef's knives is a good idea?" fails instantly, it begs for a supportive opinion. "When's the last time you bought a new kitchen knife, and what made you finally do it?" passes, because it asks for a fact from her actual life, not a verdict on your concept.

Three rules generate Mom Test questions on their own:

• Talk about their life instead of your idea. The moment you describe your solution, you've told the other person what answer would make you happy, and most people will hand it to you.
• Ask about specifics in the past, not generics or opinions about the future. "What did you do the last time this happened" beats "what would you usually do" beats "would you ever do this."
• Talk less than you listen. Every minute you spend explaining your idea is a minute you're not spending learning whether it needs to exist.

The tell that you've broken all three at once is a response like "that's nice, dear": warm, noncommittal, and completely uninformative. For a product manager, that response is not a green light with lukewarm enthusiasm, it's a closed door dressed as an open one.

Any time a stakeholder, exec sponsor, or user in a hallway test responds to a pitch with generic warmth instead of a specific reaction tied to their own work, the right move is to stop pitching and start asking what they've actually done about the problem, which is the entire subject of the next two chapters.

Avoiding Bad Data

Bad customer data isn't usually a lie so much as three specific, avoidable shapes: compliments, fluff, and ideas, and a founder or PM who can't recognize the shape is going to build a roadmap on top of it.

A compliment costs the person giving it nothing. "This is such a cool idea" or "I'd definitely use that" feels like validation because it's phrased like enthusiasm, but nobody has committed anything, remembered anything, or risked anything to say it. The fix isn't to distrust the person, it's to redirect: thank them, then immediately ask a specific question about their own life that the compliment can't answer.

Fluff is a claim dressed as a fact but built from a generic, a future tense, or a hypothetical: "I usually check prices before I buy," "I would probably use this weekly," "I might recommend it to my team." None of those sentences describe something that has actually happened.

The fix is to anchor: "when's the last time that happened, walk me through it," which either produces a real, specific memory or reveals that the "usually" was aspirational rather than observed.

Ideas, meaning unsolicited feature requests, are the trickiest because they feel like gold: a customer handed you a spec for free. But a request is the symptom, not the diagnosis.

An enterprise customer who asks for a customizable analytics dashboard, then a CSV export, then a PDF export, doesn't actually want a data platform, they want something pretty to show their own boss in a weekly meeting; the requests were three different guesses at solving one motivation the customer never stated outright.

Recording the request without asking "what would this let you do that you can't do now" means building the guess instead of the need.

For a PM, this chapter's sharpest translation is into stakeholder and user-research meetings generally, not just founder customer calls. A senior stakeholder's feature request in a roadmap review deserves the exact same treatment as a stranger's in a discovery call: write it down, then ask what underlying job it's solving for them, because the feature they asked for is rarely the cheapest way to solve it.

Asking Important Questions

A question is only worth asking in a customer conversation if the answer could change what you do next. Fitzpatrick's test for this is blunt: you should be a little afraid of at least one question on your list, because a question you're not afraid of is a question whose answer can't hurt your plan, which means it isn't actually testing anything.

Two separate kinds of risk hide inside most business ideas, and conversations can only ever de-risk one of them. Market risk is the possibility that nobody wants what you're building badly enough to change their behavior for it.

Product risk is the possibility that you can't actually build it, or can't build it well enough. A customer conversation is built to surface market risk; asking a customer whether your planned architecture will scale is a waste of the fifteen minutes they gave you.

Before a conversation even happens, it's worth naming the three biggest things you don't know yet, because different conversations, with different kinds of people, answer different unknowns. A skeptical non-user teaches you something different than a lapsed user or a power user, and preparing a shared "list of three" per conversation type keeps a team's research from drifting into whichever question is top of mind that week.

Three specific questions do a disproportionate amount of the real work:

• "Why do you bother?" pushes past a stated problem to the actual motivation underneath it, since the first problem someone names is often a proxy for something they haven't said yet.
• "What are the implications of that?" turns a shrug-worthy inconvenience into either a costly problem worth paying to fix or a minor annoyance not worth building for, and gives an early signal about what someone might actually pay.
• "What else have you tried?" reveals whether someone cared enough to already build a workaround, which is a far stronger signal than any stated interest, and it exposes what you're really competing against.

The failure mode worth watching for is trying to convince a lukewarm respondent that they should care more. "That's pretty neat" is not skepticism to be argued past, it's the answer, and a PM who treats indifference as an objection to be overcome instead of data to be logged will keep hearing what they want to hear indefinitely.

Keeping It Casual

A scheduled thirty-minute call with a calendar invite, an agenda, and a slide deck produces worse data than five minutes of unplanned conversation, because formality itself introduces bias. The moment a meeting feels like a favor the other person is doing you, they start being careful with you instead of honest with you.

The tell to watch for is your own posture going in. If you feel like you need to justify why they should give you their time, that's already too formal, and the fix usually isn't a better pitch, it's a smaller ask. A five-minute hallway conversation about a real, specific problem beats a calendared meeting where both people know they're "doing customer discovery" at each other.

Casual conversations tend to self-correct toward better data in a few concrete ways. They stay naturally short, which keeps you from filling airtime with your own idea once the real questions run out. They stay focused on the other person's actual problem rather than drifting into your solution, since there's no slide deck pulling the conversation there.

And because they're cheap to start, you can have many of them instead of over-investing emotional weight in one big meeting, which matters because any single conversation, formal or not, is still just one data point.

None of this means winging it. The questions still need to be prepared in advance, per the "list of three" from the previous chapter; casual describes the tone and format of the conversation, not the discipline behind it.

For a PM running internal stakeholder interviews as much as external customer ones, the same principle applies: a formally scheduled "requirements gathering session" produces politer, less useful answers than the same questions asked over coffee or in the two minutes before a standup, because the formality is what triggers people to perform rather than to actually think.

Commitment and Advancement

Interest that costs the other person nothing isn't interest, it's politeness, and the only way to tell them apart is to ask for something real before the conversation ends. Fitzpatrick names three currencies someone can spend to prove they mean it: time (agreeing to a follow-up, a trial, a beta), reputation (an introduction to a colleague, a public testimonial), and cash (a deposit, a pre-order, a signed letter of intent).

A meeting can be judged almost entirely by what it ends with. Strong signals sound like "what are the next steps" or "can I put down a deposit for one of the first units." Weak signals sound like "that's so cool" or "let me know when it launches," both of which feel positive in the room and mean nothing afterward, since neither one asks the person to do anything or give up anything.

The people worth chasing hardest are what Steve Blank calls "earlyvangelists," a term Fitzpatrick borrows directly: people who already have the problem, already know they have it, already have budget to fix it, and have already cobbled together some makeshift solution of their own. That fourth trait, an existing hacky workaround, is the single strongest evidence that a problem is real and costly, stronger than any stated opinion could ever be.

This chapter also resolves an apparent contradiction in the book's own advice. If you're not supposed to pitch your idea, how can anyone commit to it?

The answer is sequencing: you earn the right to ask for a commitment only after a conversation has established that the problem is real, costly, and unsolved for this specific person, and the ask itself can be for the next step in the relationship (a follow-up, a pilot slot) rather than a yes to a fully revealed product.

For a PM, the discipline transfers directly to internal roadmap conversations: an executive sponsor's enthusiasm for a feature is worth nothing until they've committed headcount, budget, or their own reputation to it.

Finding Conversations

The goal of a cold conversation is to stop needing to have cold ones. Fitzpatrick treats cold outreach as a bootstrapping tool, not a permanent channel, because every cold conversation that goes well is a chance to convert into a warm one for the next.

There are three practical ways to find people to talk to. Going to them means cold outreach (calls, LinkedIn messages, showing up where they already gather), accepting a high rejection rate in exchange for needing only a handful of yeses.

Bringing them to you means building a small amount of credibility that makes people come looking for you instead, through a blog, a talk, a workshop, or an event you organize; an organizer is assumed to have authority even with a small audience.

Warm introductions leverage the fact that everyone already knows someone: advisors, investors, professors, and past favors are all underused sources of a direct, credible introduction.

The VFWPA structure for a cold ask

Cold requests for time work better with a specific structure, remembered by the mnemonic "Very Few Wizards Properly Ask": Vision (the problem you're trying to solve, not your specific idea), Framing (being upfront about your stage, and that you're not selling anything), Weakness (naming the specific thing you don't know and need help with), Pedestal (explaining why this particular person is unusually well placed to help), and Ask (a direct, explicit request).

The structure works because it reframes the entire request away from a sales pitch and toward a genuine ask for expertise. Treating the person you're meeting as an advisor whose expertise you're evaluating, rather than a prospect you're trying to win over, also removes most of the neediness that makes cold outreach feel bad to do and read as sales-y on the receiving end.

It's worth noting a real tension in this chapter's advice: some of Fitzpatrick's own suggested cold-outreach tactics, like using a cover story ("I'm writing a book" or "I'm doing academic research") to get a meeting, sit uncomfortably close to the same dishonesty the rest of the book is fighting against, and a PM adapting this for internal stakeholder access should stick to being upfront about the ask instead.

On volume, keep going until answers stop surprising you, which in practice tends to land somewhere between five and ten conversations per distinct segment.

Choosing Your Customers

If your product is good for everyone, it's good for no one, because a segment too broad to describe specifically is a segment you haven't actually chosen yet. The test Fitzpatrick proposes is concrete: can you name both a "who" (a specific kind of person) and a "where" (a place, physical or digital, they can actually be found and reached)? A segment that fails either half isn't ready to build a plan around.

Segmentation happens by repeatedly slicing a broad group down using a small set of questions: who within this group wants it most, do all of them need it or only some, why specifically does the group that wants it most want it, and which other kinds of people share that same underlying motivation?

Each pass narrows the group and sharpens the "where," since a more specific "who" usually has a more specific, more findable gathering place than a vague one does.

The chapter warns against over-theorizing this step. The goal isn't a perfectly reasoned segment defended in a strategy doc, it's a concrete, testable starting point you can go find and talk to this week, refined by what those conversations actually teach you rather than by more internal debate. Spend a few minutes reaching an initial answer, then go validate or revise it in the field.

For B2B and enterprise products specifically, this chapter adds a second layer PMs run into constantly: the person who uses the product and the person who buys or approves it are frequently different people with different problems, different vocabularies, and different things they're each trying to get out of the purchase.

Treating "the customer" as one undifferentiated persona in an enterprise sale means solving, at best, half the actual buying decision, and every stakeholder in that chain deserves its own "who and where" rather than being folded into a single generic buyer profile.

Running the Process

Everything in the previous seven chapters only compounds into real learning if it's run as a repeatable process rather than a series of one-off, well-intentioned conversations. Before each round of customer talks, a team should write down the three most important things it doesn't yet know, decide what commitment would count as a real signal, and lay out the specific assumptions a "no" or a "yes" would actually confirm or break.

Wherever possible, conversations should be run by two people, one asking questions and one taking detailed, near-verbatim notes, so the asker can stay present in the conversation instead of splitting attention between listening and writing. Involving more than one person from the team directly in customer conversations, rather than funneling everything through a single designated "customer contact," avoids what the book calls a feedback bottleneck, where one person's interpretation quietly becomes the whole team's understanding of the market.

Immediately after a conversation, not days later, the team should debrief together against the original assumptions: what did we learn, what surprised us, what does it mean for what we build next. Fitzpatrick also recommends lightweight documentation habits that hold up over time, shorthand and quick symbols during the conversation itself, and capturing a customer's exact phrasing when it's sharp or usable later in messaging, sales conversations, or a pitch.

The chapter's closing discipline is the most useful one for a PM running ongoing discovery rather than a founder validating a single idea: treat interviews as a tool aimed at a specific unknown, not a ritual owed to "being data-driven." Once a round of conversations stops producing anything you didn't already know, stop running that round, and only start again once a new specific unknown shows up that talking to people is actually the right tool to resolve.

The Entire Book in One Framework

Every rule in the book chains into the next one as a single system rather than eight unrelated tips. Talking about someone's life instead of your idea (Chapter 1) is what keeps compliments, fluff, and unvetted feature requests (Chapter 2) out of your notes in the first place. Asking questions that could actually break your plan (Chapter 3) only works if the setting is casual enough that the other person answers honestly instead of politely (Chapter 4).

None of it means anything unless the conversation ends in a real commitment (Chapter 5), and none of that happens if you're talking to the wrong people (Chapters 6 and 7) or running the whole thing as one-off luck instead of a repeatable process (Chapter 8).

The Mom Test isn't a trick for getting your mother, or anyone else, to like your idea more convincingly. It's a discipline for asking questions specific and past-tense enough that even someone who loves you and wants to spare your feelings can't lie to you by accident.

10 Most Important Takeaways

• Talk about the other person's life, not your idea; the instant you describe your solution, you've told them what answer would please you.
• Ask about specific things that already happened, never about generics, futures, or hypotheticals.
• A compliment costs nothing and proves nothing; redirect it into a specific question about their own life.
• "I usually," "I would," and "I might" are fluff; anchor every one of them with "when's the last time that happened."
• A feature request is a clue to a motivation, not a spec; ask what it would let them do that they can't do now.
• Customer conversations can only de-risk whether people want something, never whether you can build it.
• A meeting that ends without a real ask for time, reputation, or cash didn't test anything.
• The strongest early customers already have the problem, know they have it, have budget, and have already built their own hacky workaround.
• A segment too broad to name a specific "who" and "where" for isn't a segment yet.
• Run discovery as a repeatable process with prep, shared notes, and a team debrief, not as isolated, well-intentioned chats.

The single deepest idea in the book is that customer conversations don't fail because people lie maliciously, they fail because ordinary politeness is nearly indistinguishable from validation unless you deliberately design your questions to make the two impossible to confuse.