The Mom Test

Updated: Jun 28, 2021

A book on how developers should use interviews to validate their ideas



As an innovation engineer, I've often found myself in a project, having conceived a concept idea and believing that our certain idea might be just right. The next step here would be to test whether the concept is in the users' interest. In my study program we're taught how to do this in a multitude of ways: observing the users, creating pretotypes and test designs, and finally interviewing. However, interviewing can be a tricky affair. It is hard to do right and easy to screw up. And the worst part is; the users spoken interviewed are biased. To put it simply, like Rob Fitzpatrick programmer, entrepreneur, and author of this book: "The users are lying!".


After reading this book, the fact that the users are lying is an attribute that I have personally become very aware of in my development work. The users may not be aware that they lie and sincerely be trying their best to help you with the answers you need... And this is exactly the problem! As the users know they are being interviewed, they skew their answers in ways they see most fitting. The reason for their skewing of answers can be a multitude of things. It could be for social reasons such as liking you and thus not wanting to hurt your feelings with the truth. Maybe they are romanticizing an entrepreneurial-minded person and don't want to discourage you, or maybe they find the cause of the project meaningful and thus want you to succeed in solving it. The reasons for their lying can be many. Nonetheless, since you are the person doing the interview, it is your responsibility that their answers will be unaffected by their biases. You need to learn the truth!


As stated by author Rob Fitzpatrick: "They say you shouldn't ask your mom whether your business is a good idea, because she loves you and will lie to you". This is technically true. However, the essence of this book is that this question shouldn't be asked to anyone. Questions should be asked in ways that will make users unlikely to give biased answers. This is what the book The Mom Test is about - It teaches how to ask questions which not even your mom will lie to you about.


In this book review, I will run through my main takeaways and explain how one might go about doing user interviews to find the truth. I've listed my main takeaways on how this is done beneath and this is what I will elaborate on in the rest of the book review.


My main takeaways


The problem is theirs, the idea is yours

You learn nothing from explaining/pitching the idea. Talk about their lives instead.


False positives are the death

Some people will tell that they will buy your product if you make it. Them telling you this shouldn't be considered as validation.


The goal is: Getting commitment

Commitment is validation! Give your interviewees opportunities to show their commitment to your idea.


Always ask scary questions

Treat your idea as a hypothesis. You always want to ask at least one question that potentially can falsify your idea.


Discuss in the team before the conversation: What would we like to learn?

Make it clear with your team what you want to learn before the interview and prepare questions you have to ask to find out.


Discuss in the team after the conversation: What did we actually learn?

Evaluate the conversation and be critical of what you learned. Use your learnings to plan the next steps.


The problem is theirs, the idea is yours

The criteria in finding the truth to your users' problems exist in passing The Mom Test. This is achieved when the following three criteria are met in the interview.

  1. Talking about their life instead of your idea

  2. Asking about specifics in the past instead of generics or opinions about the future

  3. Talking less and listening more

Talking about their life instead of your idea

Your great product pitch is for when you want to sell your idea. Trying to sell your idea is not what you should try to achieve at this stage of the development process. What you want to achieve is to gain knowledge of what problems your target user group has and understand how these affect them. Take the following questions as examples:

"Do you think it's a good idea?"

This is an awful question. When you ask a user about something like this you put them in a situation that is highly prone to bias. Their answer will be affected by a multitude of social effects so their answer will depend on your mutual relation and not on your idea's worth.

"Would you pay X for a product which did Y?"

This is also a bad question. Asking a question like this is like asking someone how much they want to go to the gym and exercise. They say they want to do it because they've learned it's healthy but since exercising is hard, people don't exercise as much as they ideally want. The same thing goes for paying X for your product doing Y. Don't ask them about their ideals if you're looking for validation.

"What are the implications of that?"

This is a great question! Asking a question like this at an interview allows your interviewee to elaborate on what your target problem actually means to them. Understanding this can help you make a business case as they might give your a hunch of how much their problem costs them, or how much time or pain the problem brings.


Asking about specifics in the past instead of generics or opinions about the future

When you're asking about specifics you put your interviewee in a position not dependent on ideals. This is great because the answers to specific questions give you nonbiased data. Here's 2 examples of how that might be done:

"Talk me through the last time that happened"

Splendid! now your interviewee will describe for you, how they remember the situation, and you will get insights into the details of it.

"What else have you tried"

This is also great! It makes you understand how big a pain the problem is. If they have already bought 10 products trying to alleviate the pain, then they would probably be willing to try your solution as well. And for them to tell you what they already tried also gives you data on how much you might charge for your solution. If the other products were bought in the price range of X-Z then you can probably sell yours in the same price range.


Talking less and listening more

As a rule of thumb, the more you're talking, the worse you're doing. The goal of the conversation is to learn. The words coming out of your mouth are the knowledge you already possess. You want to ask questions that make your interviewee talk. This is when you learn!



This is a picture of me as I'm in an interviewing, trying to learn what a potential user thinks of Night Care


False positives are the death

False negatives are bad! But false positives are the death! False negatives are when feel that you've received data that proves your idea as bad when in reality it wasn't. False positives are when you believe an idea is great, but in reality, it's not. This is the death because it might make you believe that your idea has great potential. This happened to Rob Fitzpatrick's first startup and made him lose the money invested in his company that didn't sell as he anticipated. Sometimes we invite bad data when we ask bad questions, but if we ask good questions, that pass The Mom Test, we will be fine. The following three signs are some we should be aware of at the interview to not make us fall into the trap of getting bad false positives or negatives. These are:

  1. Getting compliments

  2. Fluff

  3. Idea suggestions

Getting compliments

People are as a rule polite and may give you compliments like: "That's cool. Love it" and "Sound terrific. Keep me in the loop". However, make sure to be skeptical when compliments arise. Compliments are not data! Compliments are super ambiguous. You don't know if they gave you the comment because they liked the idea, liked the situation, or like you. And even if they might actually like the idea, their liking the idea doesn't prove that they would buy it. Compliments prove nothing!


Fluff

Fluff is when your interviewees are giving you bold claims like "I always" or "never" or "usually" or "would definitely" do. All this fluff is generic and it's them speaking from their ideals, not the reality. The most deadly fluff is when people say "I would definitely buy that," Because you are the developer you are invested in the project and thus biased. You want to believe they would like to buy it. However, as this is fluff, this can't be trusted. Don't fall into the fluff trap.


Idea suggestions

If your interviewee starts to come up with suggestions on what your product might be, it's a good sign! This means that they are invested in solving their problem. However, don't assume their suggestions are good as a default. Their suggestions may be good, but maybe they just got thrilled in the heat of the moment and thought it would be cool if the product did x as well. This is the reason why is said that startups don't starve, they drown. As a developer, you need to figure out what features of your product are the absolute essentials. Don't fall into the trap that your product needs all the suggested features. Note their suggestions down and evaluate them afterward to your other product features. Remember the problem is theirs, the idea is yours.


The goal: Getting commitment

As I read this book and learned that I shouldn't ask interviewees if they would buy my product, I was devastated. I had made this mistake as I was unaware of it in previous projects. However, when I understood the benefits of getting commitment instead, I quickly understood why this was superior! Showcasing commitment is of much more worth than empty words. One can show commitment in multiple ways, but Rob Fitzpatrick suggests the following three types:

  1. Allow them to give you money

  2. Allow them to give you time

  3. Allow them to risk social status

Allow them to give you money

If you're trying to find out if your product idea will sell, what you ideally want, is to simply try and sell the product. This is the end goal! However, this is more easy said than done. Trying to sell the product requires as a minimum an MVP (Minimal viable product - meaning the quickest build-able product which solves the problem). Alternatively one might make a pretotype of the kind called "a fake door". However, although both of these are good ways to test the user commitment these methods can be quite time-consuming. Maybe it would be beneficial to get validation more quickly. With quick validation, you can get a sense of whether it would be worth building an MVP or a "fake door". This is where the next two methods have their benefits.


Allow them to give you time

Another way to test users' commitment is to allow them to give their time. You could for example ask them to be part of some time-consuming trials or do a kind of time-consuming experience test. Try for example at the end of your initial interview to ask them to participate in a two-three hour focus group interview. If they actually show up for a two-three hour focus group interview or similar or more lengthy trial, you can be sure that they really want to have their problem fixed.


Allow them to risk social status

A third option could be for them to risk social status. One way to do this is by asking them if they would be willing to recommend their friends to be part of interviews or trials. Or alternatively, ask them to share a survey or some information about the project on social media. If they recommend a friend or share material on their social media accounts, you have some evidence that the cause and your project is probably of some worth.


This is a model I've made for how one might go about the interviews. At the initial stage you want to try and learn as much as possible about your users' lives. At the second stage, you have refined your idea and now you want to get some quick commitment to test if you should invest further time in refining your idea. At the third stage, your idea is so refined that you want to see a big validating commitment. This could for example be someone buying.


Always ask scary questions

As one tries to develop a new solution, one needs to be aware that they might self be biased by wanting to succeed. It is important as a developer to not be struck by confirmation bias and only look for data supporting the development of the idea. You should treat your idea like a hypothesis that might also be falsified. If you do this, then you have to make sure to always plan at least one question which, if answered in a certain way, will make it clear that your idea is bad.

This can also be done by asking for commitment and not getting it. If your interviewees are not willing to commit to anything for your cause then you need to accept that the idea probably doesn't hold potential. Remember, if your idea is not the right thing, then it's good to get this knowledge as soon as possible so you waste as little time as possible on the project. Learn to love bad news.


Discuss in the team before the conversation: What would we like to learn?

Just as you need to plan for asking scary questions, it is important to plan what you want to learn from the conversations. At my study program, we have been taught to do semi-structured interviews. Here we prepare ourselves for interviews by writing an interview guide with questions that can be used as support doing the interview. This is also Rob Fitzpatrick's take on interviewing. However, he further adds that the team should agree on at least three questions that should be asked during the interview. This is to set expectations for what the most important learnings should be.

If your team can't agree on three questions and if you don't know what is relevant knowledge, then it might be because you're are still not ready for the interviews. You still need to do some more research maybe, as we've been taught at my study program in the form of observations or desk research.


Discuss in the team after the conversation: What did we actually learn?

As mentioned at the beginning of my book review, an interview is hard to do right and easy to screw up. Don't blame yourself too much if you go into pitching mode during the conversations or mess up in some other way. What is important is, that you are critical when evaluating the interview afterward. Talk about the interview with your team and when you do, give value to commitment and see through the empty compliments and fluff. Evaluate what you've learned about your users' lives and use that as a means to plan your next moves in development, whether that means more user research or further development. Make sure to also evaluate your interview performance. chances are that you will do more user interviews at a later point and could refine your interviewing skills, or perhaps need to readjust your interview guide in its scary question or for which learnings you are interested in achieving. Interviewing is a skill that is easy to learn but extremely difficult to master, and even a professional can always get better.


This is the end of my second book review. If you've read it and you liked it perhaps you would also be interested in my first book review on the book Zero to One. It would also mean the world to me to hear what you liked about this book review or perhaps suggestions for other books I should read. 👍💬 I am making a new book review every month. So if you would like to get more reviews of the books I've found inspiring, then subscribe to my newsletter at the footer of my website 📨👇 Have a nice day! 🧠👨‍🏭

0 comments

Recent Posts

See All