The Mom Test: Stop Asking People If Your Idea Is Good

This post is part of an ongoing series on the books that I have read as part of my continual professional development (CPD). All of my CPD posts are available at the following link: Continual Professional Development

Earlier this month I argued that we are measuring the wrong thing: when an agent manufactures the code, developer effort stops telling you anything useful, and the measure that matters is value delivered. A fortnight later I followed that argument into the ceremony we built on top of our estimates and asked how much of it survives. Both posts arrive at the same place. Output is no longer the scarce thing.

That leaves a harder question underneath. If building is cheap, then building the wrong thing is cheap too, and it happens quickly. A team with well-directed agents can ship a feature nobody wanted in an afternoon, and it will look like progress on every dashboard you own. The expensive mistake used to be building slowly; now it is building confidently in the wrong direction. So how do you find out what people actually need, when almost everyone you ask is too polite to tell you?

Rob Fitzpatrick’s The Mom Test is the most practical answer to that question I have read. It earned a brief mention in my 2022 reading round-up, and it deserves more than that now. It is a short book about customer conversations, written for founders. Its answer applies just as well to the product owners, lead developers and CTOs deciding what their teams build next: stop asking people about your idea, and start asking them about their lives.

Why It’s Called The Mom Test

The familiar advice is that you shouldn’t ask your mum whether your business idea is any good, because she loves you and will lie to you. Fitzpatrick calls that “technically true, but it misses the point.” You shouldn’t ask anyone, because “everyone will lie to you at least a little.” People want to be encouraging, and a compliment costs them nothing.

His fix is to change the questions rather than the audience, and the book boils it down to three rules:

1. Talk about their life instead of your idea.
2. Ask about specifics in the past instead of generics or opinions about the future.
3. Talk less and listen more.

In his words, “It’s called The Mom Test because it leads to questions that even your mom can’t lie to you about.” Fitzpatrick’s title uses the American “mom”, so I’ve kept it when quoting him; everywhere else on this site, she’s “mum”.

The book is aimed at founders talking to potential customers, but the people a software team needs to hear from are rarely customers in that sense. They are the operations manager who will live with the new system, or the developer on another team who will consume your API. The rules work on all of them.

Everyone Is Optimistic About the Future

The worst type of fluff-inducing question is, “Would you ever?” Of course they might. Someday. That doesn’t mean that they will.

Requirements workshops are full of these. Would you use a dashboard that showed this? Would it help if the report exported to Excel? The answer is nearly always yes, and it is nearly always worthless, because agreeing costs the stakeholder nothing and disagreeing feels rude. Those answers then land in the backlog as though they were evidence.

For most of the history of software, cost filtered them out again. A speculative feature needed a developer’s time, time needed an estimate, and somewhere between the estimate and the sprint planning session someone would ask who had actually asked for it. Agents remove most of that friction. An agent will not ask whether anyone really needs the Excel export; it will build a very good one, with tests, by Friday. When building stops being the expensive part, the question that used to happen by accident has to happen on purpose.

While using generics, people describe themselves as who they want to be, not who they actually are. You need to get specific to bring out the edge cases.

Ask a team how they handle deployments and you will hear the process document: every change reviewed, and releases on a schedule. Ask them to walk you through the last release, the one that went out late on a Thursday, and you will hear about the hotfix, the manual step only one person remembers, and the spreadsheet that tracks what is really in production. The first answer describes the team they would like to be. The second tells you what to build.

The edge cases Fitzpatrick mentions are worth more than they used to be, too. In the first of this month’s posts I argued that an estimate was always a proxy for how clearly the work had been specified. The same is true of an agent’s output: give it a generic requirement and you get a generic feature, confidently built around the happy path. The hotfix, the manual step and the spreadsheet are the acceptance criteria, and they are exactly what an agent needs to be told.

To get toward this truth, you just need to reject the generic claims, incidental complaints, and fluffy promises. Instead, anchor them toward the life they already lead and the actions they’re already taking.

This is what a good user story should contain, and it is the part most of them leave out. “As a manager, I want a report so that I can see performance” is a fluffy promise with a job title attached. A story anchored in what that manager already does every Monday morning, copying figures out of three systems into a slide, gives the team something to verify against and gives an agent something specific to build.

Most of this comes down to rewording. The questions on the left invite opinions about the future; the ones on the right ask about things that have already happened, which are much harder to be polite about.

None of the questions on the right mention the feature. That is the first rule doing its job: the moment you describe your idea, you have given the other person something to be kind about.

The Truth Is in What People Already Do

If you don’t know what you’re trying to learn, you shouldn’t bother having the conversation.

“Let’s get the client on a call to understand their needs” is a calendar invitation, and plenty of discovery work never gets further than that. A learning goal sounds more like “find out whether the finance team re-keys invoice data, and how often”. The same applies well beyond customers. “I want to learn Japanese” is a wish; “I want to hold a conversation about Pokémon in Japanese” tells you which words to learn first.

Agents add a new temptation here. When a working prototype costs an afternoon, it is very easy to skip the conversation and take the prototype along instead, on the basis that people understand software better when they can click on it. They do. They also start being kind about it straight away, because a prototype is your idea with a user interface, and showing it breaks the first rule before anyone has said a word. A prototype is a fine way to test a specific assumption once you know what you are trying to learn. It is a poor way to find out what that should be.

Watching someone do a task will show you where the problems and inefficiencies really are, not where the customer thinks they are.

People are poor narrators of their own work, because the painful parts have long since become habits. The workarounds someone has stopped noticing, like the sticky note of codes beside the keyboard, are usually where the value is, and they rarely make it into a requirements document. Our assumptions about how a system is used can be wildly different from the reality, and half an hour of watching will correct them faster than a week of interviews.

This is also the part of the job that agents cannot do for you. An agent can read the codebase and the tickets, and both describe the system as it was designed. Neither shows the sticky note. Someone has to sit next to the person doing the work, and that someone is increasingly the person a team can least afford to lose.

The Meeting Anti-Pattern is the tendency to relegate every opportunity for customer conversation into a calendar block.

Formalising a conversation changes it. Once there is an invitation and an agenda, people prepare their answers, and prepared answers drift towards who they want to be. The quick question asked while someone is in the middle of the task is far more likely to get the truth.

There is a second cost. In my post on Slow Productivity I wrote about pseudo-productivity, where visible activity stands in for real value. A calendar full of booked customer interviews is exactly that. It looks like diligent research and it fills a status report, and it can still leave you knowing no more than when you started. AI meeting tools make this easier to fall into. Every call now produces a transcript and a list of action items, which is a great deal of evidence that a conversation happened and none at all that anyone learned something from it.

A useful check before any discovery session, formal or otherwise, is to write down the goal in the form the book encourages:

If you can’t fill in the right-hand column, you are not ready for the conversation yet.

Nobody Else’s Answer Fits Your Business

Every business is different. Don’t just copy what someone else is doing. Consider your own situation, and then get clever.

I have consulted for a lot of companies that have told me some version of the same story: we implemented Agile, adopted Spotify’s squads and tribes, followed whichever model was fashionable that year, and we still can’t ship any faster. They copied what another organisation did without asking why it worked there, which is the argument at the heart of Start With Why.

There was also less to copy than it seemed. Henrik Kniberg and Anders Ivarsson described their 2012 paper as “only a snapshot of our current way of working”, and Joakim Sundén, one of Spotify’s own agile coaches, later called it “part ambition, part approximation”, as former Spotify employee Jeremiah Lee records. Companies adopted a picture of how Spotify hoped to work while Spotify itself kept changing.

Agents make copying cheaper as well. Ask one for a team structure or a delivery process and you will get a fluent, well-organised version of whatever is most common in its training data, which is to say someone else’s situation. That can be a reasonable place to start. Whether it fits is something only your own team can tell you, and the Mom Test works just as well pointed inwards. Instead of asking your developers whether the new process is working, which invites the same polite yes as any other opinion question, ask them about the last piece of work that took longer than expected and what held it up. Instead of asking whether retrospectives are useful, ask what changed as a result of the last one. The answers describe the team you actually have, and that is the only team a process has to work for.

Serve Someone First

Before we can serve everyone, we have to serve someone.

When Jira launched in 2002, it was issue-tracking software aimed at software developers. The agile boards, and the teams far outside software planning their work in it, came much later, once that first someone had been served well.

Agents make it tempting to skip that step: if a feature costs an afternoon, it is easy to justify building for every persona in the workshop at once. The afternoon was never the whole cost, though. Every feature still has to be tested, secured, supported and understood by the next person to change the code. A feature built for a vague “everyone” is harder to do all of that for, because nobody can tell you what it is supposed to do for them. Serving someone first gives you a person to ask when the edge cases turn up, and they always turn up.

Next week’s post is about a company that built the smartphone fifteen years before the iPhone, and what happened when it had the freedom to build everything at once.

If your team is shipping faster than ever but you are not sure it is shipping the right things, that is a conversation I have with engineering leaders regularly. Let’s talk.