The Mom Test, and the Questions I Would Cut From My Own List

A while back I wrote down the questions we use when we talk to customers. It is one of the more useful things I have put on this blog, and I still send people the question list when they ask how we do customer development.

This week I reread it next to Rob Fitzpatrick’s The Mom Test, and I would cut about half of it.

The book’s premise is simple. Don’t ask your mom if your business idea is good. She loves you, so she will say yes, and she will mean it. The problem is that almost everyone you interview behaves a little like your mom. They are polite, they want to be helpful, and they don’t want to crush you to your face. So you walk out of a call with a warm feeling and no information.

Fitzpatrick’s fix is not to find more honest people. It is to ask questions that even your mom can’t lie to you about.

The three rules

He boils it down to three rules. Talk about their life instead of your idea. Ask about specifics in the past instead of generics or opinions about the future. Talk less and listen more.

That is it. The rest of the book is what happens when you break them.

The three kinds of bad data

The part I found most useful is his list of the things that feel like signal but are not.

Compliments are the first one. He calls them “the fool’s gold of customer learning,” which is exactly right. “This is really cool” costs the other person nothing to say, and it tells you nothing about whether they will ever use or pay for the thing. When you get one, the move is to deflect it and get back to their actual process.

Fluff is the second. Generic claims like “I always” or “I usually,” hypotheticals like “I would,” and promises about the future like “I will definitely try it.” People are wildly optimistic about their future selves. What they did last Tuesday is far more reliable than what they say they will do next quarter.

Ideas are the third. Feature requests, suggestions, “you know what you should build.” They are worth understanding and almost never worth obeying as written. The job is to dig underneath the request and find the problem that produced it.

Where I got this wrong

When we first built Process Street, we listened to customers and built what they asked for. It worked for a while. We grew fast, and every customer call came with a new request. Add forms here. Let me import the process diagram I already drew. Add branches and approvals.

We built all of it, and without really noticing, we had built a business process management tool that tried to serve every process for every business. That made it very hard to sell.

The requests were ideas. The real signal was sitting in the behavior. When we finally looked at who brought in the most users, built the most processes and stayed the longest, it was the teams doing high-stakes work, where skipping a step had a real cost. Health and safety. Regulated money. Compliance. None of them had asked for “a compliance platform.” Their behavior told us anyway, and it is a big part of why we now sell Process Street the way we do.

I made a version of the same mistake with Vitoto, my video startup before Process Street. I was sure that if we built the features I had planned, we would hit product market fit within our runway. Nine months in, we realized we needed at least another year, and we had nothing with enough traction or retention to justify raising more. What I had was belief. I had not gone looking for the behavior that would have told me how far away we really were.

I still catch myself. At a CFO round table in Palo Alto, we asked the room: if you could automate anything in your business with AI, what would it be? The answers came back exactly as you would guess. Sales, marketing, then operations. That is a hypothetical question, so we got a generic answer. The better question would have been: what is the last thing you tried to automate, and what happened?

Rereading my own question list

Going back through my list with the three rules in mind, some questions hold up well:

“Describe your current process for X. What works? What doesn’t?”

“How long has this been a problem?”

“What solutions have you tried? Did they work?”

These are about their life, and they are about the past. You can’t answer them with a compliment.

Others fail the test:

“What would be an ideal solution to this problem?” That invites an idea, and they will design your product for you, badly.

“In a perfect world, how quickly would you solve this issue?” Pure hypothetical.

“What would you do, or do more of, if you had more time in your day?” Future tense, and the answer is always something flattering.

I would rewrite each of them to point backwards. Instead of the ideal solution, ask what they did the last time this broke. Instead of the perfect world, ask what it cost them last month. Instead of what they would do with more time, ask what they dropped the last time they were underwater.

Commitment is the real test

The last idea in the book is the one I think founders skip most. A good conversation ends with facts, a commitment or an advancement. Fitzpatrick describes commitment as someone giving up something they value: their time, their reputation or their money. Another meeting with their boss. An introduction to the person who owns the budget. A pilot with real data. A deposit.

If a call ends with “this is great, keep me posted,” it went badly, no matter how good it felt. You have a zombie lead that will keep saying nice things and never move.

These days I judge a customer conversation by one question. Did they give up anything to be in it? If they didn’t, I learned less than I think I did, and the next call has to be sharper.