The Mom Test: understand the work before building a solution

A team shows customers a new dashboard and asks whether it seems useful. People praise the screen, suggest filters and say they would like to try it. Months later, almost nobody changes their current process. The conversation was friendly, but it mixed courtesy with evidence. Rob Fitzpatrick’s The Mom Test teaches readers to reduce that mistake: ask about a person’s life and work, investigate episodes that already happened and seek facts that could change a decision.

The book in brief

The book is a short handbook for discovery conversations with people who need to understand customer problems and decisions before investing in a solution. Its thesis is not that customers deliberately lie; compliments, hypothetical questions and vague answers are often shaped by politeness, a desire to help and the difficulty of predicting one’s own behavior. The official site presents The Mom Test as a practical guide to getting useful learning from customer conversations, even when the idea does not exist yet (official book site).

Why read it: developers, designers and leaders often enter interviews with a solution already in mind. The book offers a simple method for postponing that pitch, hearing how work happens today and assessing whether a concrete, recurring and costly need deserves investment.

Rules that make a question useful

The first principle is to talk about the person’s life, not sell your idea. “Would you use a tool to automate reports?” asks the person to evaluate your proposal and imagine a future. “How did you prepare your last report?” invites them to reconstruct a specific situation. The first question produces an opinion about a concept; the second can reveal data sources, steps, delays, exceptions and who receives the result.

The second is to ask about concrete past behavior, not generic predictions. Instead of “Does this happen often?” ask for a recent example: when it happened, what they did, who was involved, what the consequence was and which alternative they tried. Detail does not guarantee perfect truth—memory and interpretation can fail too—but it leaves less room for an idealized answer. If someone cannot recall an episode, that is evidence for the hypothesis, not an invitation to offer hints until they say yes.

The third is to talk less and listen better. An interview is not a product demo, roadmap presentation or debate meant to convince someone. Short questions let people reveal their own sequence and vocabulary. When a team fills silence with explanations, it begins testing whether the interviewee can be agreeable, not whether the problem exists.

These rules also change note-taking. “The manager sent three spreadsheets to the team every Friday” is a reported fact; “she needs a centralized dashboard” is an interpretation; “the company will buy our product” is a business hypothesis. Keeping these levels separate protects the team from turning a convenient idea into a supposedly confirmed requirement. The distinction between problem, solution and purchase is one of the book’s most valuable contributions.

From conversation to commitment

Fitzpatrick recommends looking for evidence stronger than praise. Someone might offer time for a follow-up, introduce the person who does the work, share an authorized example or participate in a test. Each commitment has a different cost and meaning. The team needs to ask what it demonstrates: access to a user, permission to observe a workflow, interest in learning or actual buying intent.

A commitment is not a sale either. The person experiencing the problem may not control the budget; the person approving the purchase may not do the work. In a company, users, buyers, security, legal and operations can have different goals. A useful conversation maps those relationships without pretending one interviewee represents the entire organization. Before requesting data, documents or introductions, explain the purpose, use, retention and who can access the material.

The book focuses on conversation quality, not a rigid script for every product stage. An interview can help discover what happens and why; when a problem is already well defined, it may also inform a validation decision. Fitzpatrick warns that interviews are not the right validation tool for every situation and that vague problems produce learning, not proof (“Customer convos are the carpenter’s hammer”). That caveat helps keep the book from becoming interview dogma.

An applied case: automating operations reports

Consider this hypothetical scenario: a software team is thinking about a service that generates a weekly incident report automatically. Before discussing a dashboard, it speaks with the people who prepare and use the report. Instead of asking “Would you like automatic reports?” it asks someone to describe the last one they prepared: which systems they consulted, how they matched identifiers, when they noticed missing data, who reviewed the document and how a decision followed from it.

The account might show that assembling the table takes little time; the delay comes from getting authorization to access logs in two systems. Another person might say the report rarely affects a decision and that the manual process is acceptable. The first finding suggests an access and governance dependency, not just text automation. The second questions whether the feature is worth building. Both are more valuable than a list of filters suggested by someone who saw an attractive screen.

The team separates notes into reported facts, open questions and interpretations. Then it compares conversations with people in different roles and, with consent, observes the process or examines an anonymized example. If the hypothesis is that manual review causes delays, a next step might measure production time in real cases. If the hypothesis is that a data source is missing, the team might test a narrow integration. In neither case can an interview alone estimate how many teams share the problem or prove they will buy the solution.

A useful follow-up is what the person has already tried and what it cost in time, money, risk or rework. “What happens if the report is late?” reveals impact better than “Is this important?” “Who has to approve a change to this workflow?” uncovers decision constraints. Questions like these help understand consequences without putting words in someone’s mouth. This example is an editorial application, not a story attributed to the book.