A working reference for talking to customers without lying to yourself. The book is short and the cheat sheet at the back is already tight, so this post is not a summary. It is the version I want to be able to paste into a chat with another founder, or into an AI prompt, and have someone walk away knowing which questions to ask and which to throw out.
You can use this post as a reference. Bookmark it. Paste the link to a friend before they go talk to users. Paste the whole thing into an AI before prepping for a call and ask the AI to grade your draft questions against it. The cheat sheet at the bottom is the version I would actually re-read in the thirty minutes before walking into a meeting.
The book is 130 pages. Rob is a programmer turned founder who learned customer conversations the hard way at his first startup, where the team mistook polite enthusiasm for product-market fit and lost about ten million dollars before realizing nobody was going to buy. The book came out of that experience.
The thesis is in the title. People say you should not ask your mom whether your business is a good idea, because she loves you and will lie. That is true but misses the point. You should not ask anyone whether your business is a good idea. It is a bad question and everyone will lie at least a little. Your job is to find the truth anyway.
A note on the dialogues: the conversation examples below are paraphrased from Rob’s book to illustrate the patterns. They are not transcripts. For the original dialogues in Rob’s exact wording, read the book. It is two hours of your life and worth every minute.
The three rules
- Talk about their life, not your idea
- Ask about specifics in the past, not generics or opinions about the future
- Talk less and listen more
Each rule prevents a specific failure mode. Rule one prevents the listener from knowing what answer you want. Rule two prevents them from making things up about a future they have not thought about. Rule three prevents you from filling silence with a pitch when the most useful information is whatever they were about to say next.
If you remember nothing else, the most reliable way to fix any conversation is to apply rule one harder.
Bad conversation vs good conversation: the cookbook
Rob opens the book with two versions of the same conversation. The son wants to build a digital cookbook for the iPad. He talks to his mom. Both versions paraphrased.
The bad version
Son: Mom, I have a business idea, can I run it by you?
Mom: Of course, dear.
Son: You like your iPad, right?
Mom: Yes.
Son: Would you ever buy a cookbook app for it?
Mom: Hmm.
Son: It’s only $40, cheaper than those hardcovers on your shelf.
Mom: Well…
Son: And you can share recipes with friends, plus videos of your favorite chef.
Mom: Oh, that sounds wonderful, dear. Will it have pictures of the recipes?
Son: Yes! Thanks Mom, love you!
The son walks away thinking he has validation. Mom is mostly worried he will not be able to afford rent.
What went wrong: the son told mom about his idea up front, asked a hypothetical future-tense question, ignored the lukewarm signals, and accepted the closing compliment as a positive data point. Every rule of the Mom Test was violated.
The good version
Son: How are you liking the new iPad?
Mom: Love it, I use it every day.
Son: What’s the last thing you did on it?
Mom: Looking at hotels for our trip.
Son: Did you use an app for that?
Mom: No, just Google. I didn’t know there was an app.
Son: Where do you find out about the apps you do use?
Mom: The Sunday paper has an app section.
Son: I noticed some new cookbooks on your shelf, where did those come from?
Mom: Christmas gifts. Haven’t opened them. As if I need another lasagna recipe at my age.
Son: What’s the last cookbook you actually bought for yourself?
Mom: A vegan one, a few months ago. Your father is trying to eat healthier.
What went right: the son never mentioned the cookbook idea. He asked about her actual life. He noticed an interesting detail and dug in. He anchored a generic answer with a specific past example, which surfaced an exception that completely changes the customer hypothesis.
In twenty minutes he learns three things. Older people who already know how to cook do not want generic recipe books. Cookbooks are mostly bought as gifts. The actual customer is probably a younger cook, or someone exploring a specific niche like vegan cooking. None of that came from his idea. All of it came from her actual life.
The trick is in what got skipped. Mom could not lie because they never talked about the thing she would have lied about.
Bad questions and good questions
For each one: the bad version, the better version, and why.
”Do you think it’s a good idea?”
Awful. Only the market can tell you that. Everyone else is guessing.
Better: Ask them to show you how they currently solve the problem. Which tools they use. What they tried before. What they hate about the current setup. Where they lose money or time.
Rule of thumb: opinions are worthless.
”Would you buy a product that did X?”
Bad. People are wildly optimistic about a future that has not arrived. The answer is almost always yes, which makes it useless.
Better: “How are you solving X right now?” “When was the last time it came up?” “Walk me through what happened.” If they have not even Googled around for a solution, they will not buy yours either.
Rule of thumb: anything in the future tense is an over-optimistic lie.
”How much would you pay for X?”
Bad in the same way, but more dangerous because the number sounds rigorous.
Better: “How much does this problem cost you now?” “How much do you pay to deal with it?” “What’s the budget?” If you want a real number, find the price of the duct-tape workaround they already use.
”What would your dream product do?”
Sort of okay, but only as a setup. The features they list are not the answer. The motivations underneath are.
Better: Whatever they say, dig. “What would that let you do?” “How are you coping without it?” The feature request is the symptom. The motivation is the data.
”Why do you bother?”
Good. Moves the conversation from surface complaint to underlying goal.
Rob tells a story about a team building tools for finance people who kept asking for better messaging tools. Someone finally asked why, and the answer was about being sure everyone was working off the latest spreadsheet. The product they actually needed was Dropbox, not Slack.
”What are the implications of that?”
Good. Separates problems people will pay to solve from problems they will complain about and live with.
Rule of thumb: some problems do not actually matter, no matter how loudly people complain.
”Talk me through the last time that happened.”
The most useful single question in the book. It forces the conversation from “what I would do” into “what I actually did,” which is much harder to make up on the spot. One question, five answers: workflow, tools, who else is involved, where it broke down, what they tried.
”What else have you tried?”
Good. Tells you about alternatives, switching costs, and the seriousness of the problem all at once. If they have tried five things, the problem is real. If they have tried nothing, the problem might not be.
”How are you dealing with it now?”
Good. Tells you the workflow, the price anchor, and the alternatives. If they pay $100 a month for a workaround, you know the ballpark. If they pay an agency $120,000 a year for the same thing, the ballpark is very different.
”Where does the money come from?”
Must-ask in B2B. You are usually not talking to the budget owner.
”Who else should I talk to?”
Always end with this. If they like you and the problem is real, your pipeline multiplies through introductions.
”Is there anything else I should have asked?”
They know the industry, you do not. This question gives them permission to politely correct your line of questioning.
What the bad questions have in common
Every bad question is about your idea, the future, or an opinion. Every good question is about their life, the past, or a fact. That is the whole move. If you can hear yourself ask a question and it is about your idea, the future, or an opinion, throw it out.
The three things that wreck conversations
Even when you ask the right questions, conversations go off track. Three reasons why, and one move for each.
1. Compliments
Most meetings end with a compliment. The lie is rarely intentional, people just want to be supportive or get you out of their office. Even genuine compliments are worthless data, because compliments are not facts.
Bad version
You: …and that’s the idea. It’s like X for Y.
Them: That’s so cool, I love it.
You: Thanks! We think it could save companies 35% on costs.
Them: Sounds great, keep me in the loop.
You: Will do!
(Six months later, zero customers.)
The closing compliment plus the “keep me in the loop” stall is the textbook signal that you are never going to hear from this person again.
Good version
You: …and that’s the idea. It’s like X for Y.
Them: That’s really cool, I love it.
You: Sorry, I just slipped into pitch mode there. Listen, you guys clearly know this space, can I ask how you’re handling this stuff at the moment?
Them: Sure. We’ve got a couple people who manage the process to keep us in sync, and then it’s mostly Excel and email.
You: Two full-time people on this? Can you walk me through how it actually fits together?
Them: (Real workflow data follows.)
The good version takes the compliment, deflects without making it awkward, and pivots into a workflow question. The two people on the manual process is the actual signal. The compliment told you nothing. The headcount told you the problem is worth real money to them.
Watch for these phrases coming out of your own mouth back at the office. They are tells:
- “That meeting went really well”
- “We’re getting a lot of positive feedback”
- “Everybody loves the idea”
If you cannot say specifically why someone liked the idea, what problem it would solve, or how it would fit into their life, you have a compliment, not data.
Rule of thumb: compliments are the fool’s gold of customer learning.
2. Fluff
Fluff is generic, hypothetical, or future-tense talk:
- “I usually,” “I always,” “I never”
- “I would,” “I will”
- “I might,” “I could”
The deadliest piece of fluff in the world is a customer saying they would definitely buy your thing. It sounds concrete. It is air. Rob’s first startup took it at face value and lost ten million dollars.
The fix is to anchor fluff to something specific in the past.
Bad version (loyalty card scenario)
Stranger in line: Why does anyone make us carry around all these stupid loyalty cards?
Founder: Funny you mention that, I’m building a phone app that replaces them. Would you use something like that?
Stranger: Definitely, that’s about time someone built that.
The founder walks away thinking they got validation. They got nothing. The stranger has zero stake in the answer and is being polite.
Good version
Stranger in line: Why does anyone make us carry around all these stupid loyalty cards?
Founder: I know, my wallet is two feet thick. Have you tried any of those phone apps for it?
Stranger: Those exist?
Founder: Yeah, the cafe on campus has one.
Stranger: Oh. I’m always kind of in a rush.
Founder: Why don’t you download it now?
Stranger: I’ll do it next time.
Translation: I am a complainer, not a customer. The problem I just complained about is not actually one I am willing to spend thirty seconds on.
Another anchor pattern, for an inbox tool:
Them: I’m an Inbox Zero zealot, totally changed my life.
You: Nice, I’m a failure at it. What’s your inbox at right now?
Them: About ten, just from this morning.
You: Okay, you’re not lying. When was the last time it totally fell apart?
Them: Three weeks ago, traveling, hotel wifi was broken. Took me ten days to recover.
You: Walk me through how you handled it.
The first answer is generic. The third answer is real data you can build a product on.
3. Ideas
When someone gets excited and starts giving you feature requests, do not write them down and move on. Dig into the motivation underneath.
Bad version
Customer: You should add Excel sync. I think that’s the killer feature.
You: Got it, Excel sync. (Writes it on todo list.)
You just took on three months of engineering work without knowing whether it actually matters.
Good version A (feature request that turns out to not matter)
Customer: You should add Excel sync. I think that’s the killer feature.
You: What would syncing to Excel let you do?
Customer: We’ve got a bunch of legacy reports. Would be nice to have everything in one place.
You: How often do you actually go back to those reports?
Customer: Maybe once a quarter.
Not a killer feature. A nice-to-have for a quarterly task. Saved yourself three months.
Good version B (same feature request, opposite signal)
Customer: You should add Excel sync. I think that’s the killer feature.
You: What would that let you do?
Customer: We tried four other tools and the broken sync killed all of them. It takes us a week every month to pull reports together.
Now Excel sync is your most important differentiator and these guys are your dream early customers.
The exact same feature request, completely different responses, and you only know which is which because you asked the follow-up.
Rob’s MTV story is the best illustration. An enterprise client at his first company asked for analytics. He built a beautiful dashboard. They never used it. They kept calling every Friday asking him to email them a CSV. Then they wanted the report as a PDF. Then they wanted the PDF to have their logo on it. He finally got annoyed and asked why they wanted a branded PDF when they were not using the dashboard. The answer: nobody read the reports anyway, the client just wanted something fancy to email to their own clients every Friday. They had not wanted analytics. They had wanted a way to make their own clients happy.
When you hear a feature request, ask:
- “Why do you want that?”
- “What would that let you do?”
- “How are you coping without it?”
When you hear strong emotion, dig:
- “Tell me more”
- “What makes it so awful?”
- “Why haven’t you fixed this already?”
Rule of thumb: ideas and feature requests should be understood, not obeyed.
The premature zoom
You assume someone has the problem you are solving and start asking detailed questions about it before checking whether they care at all.
Bad version (fitness app)
You: How often do you go to the gym?
Them: Not really ever.
You: What’s your biggest problem with going to the gym?
Them: I guess the time it takes to get there.
You: Got it. We’re building a workout-from-home app.
Them: Cool, send it over when it launches.
The “biggest problem” answer is not a fact about their life. It is a hypothetical they generated to be polite. You will write it down, build a workout-from-home app, and watch them never use it.
Good version
You: How often do you go to the gym?
Them: Not really ever.
You: Why not?
Them: Just not something I worry about. I run around after the kids all day, gives me all the cardio I need.
You: Got it. Thanks for the time.
The good version aborts in thirty seconds. That is a successful conversation. You came to find out if there is a problem worth solving for this person, you found out there is not, and you moved on.
The right opening is broader. Something like “what are your big goals or pains right now?” If fitness comes up unprompted, zoom in. If not, you are talking to the wrong person.
The relevant question is not “what is your biggest problem with X” but “is X actually a problem for you at all.”
The “does this problem matter” check
Sometimes you are not sure if the problem is a real pain or just a low-grade annoyance. Useful follow-up questions to figure out:
- “How seriously do you take this?”
- “Do you make money from it?”
- “How much time do you spend on it each week?”
- “What are you already doing to improve this?”
- “What are the three big things you’re trying to fix or improve right now?”
If the answer is they barely think about it, are not paying for any solution, and it is not in their top three priorities, the problem might exist but is not one they will pay to solve.
Look at the elephant
Even after you find a real problem, make sure you are not ignoring the bigger one in the room.
Rob’s example: imagine you suspect that teachers from the poorest schools are overloaded and would save time with your tools. You go talk to them and confirm they are overloaded. You spend weeks figuring out the perfect feature set. The elephant you missed is that the poorest schools may not have the budget to pay you. You can build the perfect product for a real problem and still go bankrupt because of one failure point you ignored.
A good business usually depends on multiple conditions being true at once. Customer pain is one. Customer ability to pay is another. Reachability is a third. If you are only checking one, you are working blind on the other two.
Product risk vs market risk
Some businesses fail because the customer did not want it. Some fail because the founder could not build it.
Rob’s example: a guy is building a marketplace for public speakers and gets this from a speaker:
Speaker: If you can get me more or better-paid gigs, I’ll happily drop my agent and pay you 20%.
This sounds like validation. It is not. The speaker is saying “if your product works, I will pay you.” That has been true since the dawn of time. The customer was never the risk. The product was. Can you actually amass enough event organizers to send this guy gigs? You cannot answer that by talking to speakers.
Same pattern in any marketplace, any ad network, any affiliate business. If you can get traffic, advertisers will pay you. If you can get listings, buyers will come. The customers are not lying. They just are not the source of the risk you actually need to be worried about.
- Product risk: Can I build it? Can I grow it? Will they keep using it?
- Market risk: Do they want it? Will they pay? Are there enough of them?
Customer conversations validate market risk. Product risk you have to validate by building.
What a good meeting looks like
Most meetings end with no clear outcome. You leave with a compliment, a “let me know how it goes,” or a vague offer of help. None of that is a result.
A meeting succeeded if it produced one or more of:
- Facts about how the customer actually lives and works
- Commitment in the form of giving up something they value
- Advancement to the next step of your funnel
A meeting failed if it produced:
- A pipeline of zombie leads who keep meeting and never buy
- An ending compliment with no next step
- The phrase “let me know when it launches”
- The feeling that it “went well”
- An unexpected answer that did not change your idea
Real meetings either succeed or fail. They do not just go well.
Bad meeting endings
- “That’s so cool, I love it.” Pure compliment, zero data.
- “Looks great, let me know when it launches.” Compliment plus stall.
- “I would definitely buy that.” Future-tense lie. Most dangerous one in the list.
- “There are a couple people I can intro you to when you’re ready.” Fluffy promise. Find out who and what “ready” means.
Good meeting endings
- “What are the next steps?” The classic. They are pulling you forward.
- “When can we start the trial?” Probably good, depending on what trying actually costs them.
- “Can I buy the prototype?” Best ending you can hope for. Almost never happens.
- “When can you come back to talk to the rest of the team?” In B2B, this is gold. They are spending political capital on you.
The currencies of commitment
If the goal is commitment, you need to know what counts.
Time. A scheduled next meeting with a clear agenda. Sitting down to give feedback on wireframes. Running a trial.
Reputation. An intro to their boss, their team, or peers. A public testimonial. Letting you write a case study.
Money. A letter of intent. A pre-order. A deposit. Most people will say they will pay. Almost none of them actually take out their wallet.
A meeting where someone says “looks great, let me know when it launches” gave you nothing in any of these. A meeting where someone agrees to introduce you to their CTO gave you reputation. A meeting where someone signs up for a paid trial gave you all three.
Rule of thumb: the more they are giving up, the more you can trust their kind words.
Earlyvangelists: spotting your first real customer
Your first customers are not normal. They are crazy in a useful way. They want what you are making so badly that they are willing to be the person who tries it first, despite all the obvious reasons not to.
Steve Blank’s term for them is earlyvangelists, early evangelists. In B2B they are people who:
- Have the problem
- Know they have the problem
- Have the budget to solve it
- Have already cobbled together their own makeshift solution
That last bullet is the giveaway. Someone who has duct-taped a workaround together with spreadsheets and reminders is in the market for a real solution. Someone who has not is probably not.
In consumer products, the earlyvangelist is the person who gets emotional about your product. There is a huge difference between “yeah, that’s a problem” and “this is the worst part of my life and I will pay you right now to fix it.” Watch for the second one. Keep them close. They are the rare fan who turns into your first sale.
Choosing your customers: the segmentation problem
You cannot have a useful conversation if you are talking to the wrong people. The most common reason is your customer segment is too broad.
Rob’s example: a founder thinks her segment is “students” and starts getting feedback. One person needs formal citations. Another wants practice questions. A third needs it on iPad. A fourth needs eighty pupils to share one computer. A fifth needs offline mode for a shaky internet connection. The “students” turn out to be a PhD student, a prep school kid, a homeschooling parent, a rural village in India, and a student in Africa. All technically students. All wildly different products.
If you have run more than ten conversations and the feedback is still all over the map, your segment is too broad. You are running ten different conversations with ten different types of customer, not ten conversations with one customer type.
Customer slicing
The fix is to keep slicing the segment until you have a “who-where pair.” That means you can describe your customer specifically enough to know where to find them.
Start with your broad segment and ask:
- Within this group, who would want it most?
- Would everyone in the group buy or only some?
- Why would they want it? What is the goal or problem?
- Does everyone share that motivation, or only some?
- What other types of people share the same motivation?
Now you have demographic groups and motivation groups. Slice the generic ones again. Then ask:
- What are these people already doing to solve the problem?
- Where can we find them?
- Where can we find people doing the workaround behavior?
If a group is unfindable, slice it smaller until you know where to find them. A customer segment is not useful if you cannot get in touch with them.
Then choose the slice that is:
- Profitable
- Easy to reach
- Personally rewarding to build for
Rob’s worked example: instead of “students” for a public speaking app, you might end up with “people scared of public speaking who are actively trying to get better.” You can find them at Toastmasters meetups. One evening of casual conversations there is worth a month of going to random students.
Rule of thumb: a good customer segment is a who-where pair. If you do not know where to find them, keep slicing.
Three ways to talk to the wrong people
- Your segment is too broad and you are talking to everyone
- You have multiple segments and missed one
- You are selling to a business with a complicated buying process and missed a stakeholder
For B2B, watch the third one carefully. If you are building for kids, you have to “sell” to both kids and parents. If you are building for schools, you might need teachers, students, administrators, the PTA, and taxpayers all at once. Map every stakeholder before you start.
Finding conversations
The first conversations are the hardest. Once you have a few, the rest come from introductions.
Cold calls
Most cold outreach gets ignored. That is fine. The point of cold outreach is not a high response rate. It is to start the snowball rolling. Two conversations from a hundred attempts is a successful day. Once those two go well, they intro you to more people, and you stop having to do cold outreach.
Seizing serendipity
If you have your industry in your head, you start hearing it everywhere. Rob mentions overhearing someone at a party say “my talk in Tokyo next week” and walking over to start a conversation about public speaking, which led to a useful customer interview and a commitment to use his prototype. The other person left thinking they had just met a nice, curious guy. Both true.
Find a good excuse
If you cannot just walk up and ask, find a reason. Rob describes flagging down a waitress and asking to talk to a cafe owner about the story behind their beans, which the owner was happy to discuss. From there, the conversation about the actual product became natural.
If you have a PhD student on your team, you have the ultimate excuse. “I’m doing my PhD research on X, could I ask you a couple questions?” works almost every time.
Rule of thumb: if it is a topic you both care about, find an excuse to talk about it. Your idea never has to come up.
Immerse yourself
Go to where your customers already are. Conferences, meetups, communities, forums. Give free talks, do favors for organizers, become someone the community recognizes. The conversations happen naturally once you are part of the scene.
Bringing them to you
Better than going to your customers is having them come to you.
Organize meetups. Want to talk to HR professionals? Run an HR happy hour. The person who sent the invites is automatically credible. Rob says this is the most unfair trick he knows for fast learning, and almost nobody does it.
Speaking and teaching. If you have any expertise in the space, find ways to share it. Conferences, workshops, blog posts, free office hours. You meet potential customers who already take you seriously.
Industry blogging. Even if your blog has no audience, it gives you credibility. When you cold email someone from a blog email address and they Google you, the existence of the blog itself often gets you the meeting.
Get clever. Rob mentions a guy who organized a “knowledge exchange” call between department heads at three top universities, and let other universities dial in to listen. By being the host, he absorbed the credibility of the universities and got direct phone access to dozens of decision makers.
Warm intros
Always preferable. The world is small and everyone knows someone. Rob describes literally standing on a chair in a coworking space and yelling that he needed to talk to someone at McKinsey. Three beers later he had three intros. Most people overestimate how hard a warm intro is.
Sources of warm intros:
- Industry advisors who give intros in exchange for small equity
- Universities (professors are a goldmine)
- Investors (rolodex plus credibility)
- Cashing in old “let me know how I can help” promises
The advisory flip
Mindset trick worth knowing. Going into a conversation looking for customers creates a needy vibe. You are essentially asking for permission. Going in looking for advisors flips the dynamic. You are now evaluating them. The questions you ask are basically the same. The energy is completely different. Willpower is finite, and changing the framing is easier than powering through the awkwardness.
How to ask for and frame the meeting
Sometimes you need a real meeting (not a casual chat). Rob’s mnemonic for the email is “Very Few Wizards Properly Ask,” which gives you Vision, Framing, Weakness, Pedestal, Ask.
- Vision. Half-sentence on the problem you are solving and the future you want to build.
- Framing. Where you are at and what you are looking for. If you do not have anything to sell, say so.
- Weakness. A specific gap in your understanding.
- Pedestal. Why this person specifically can fill that gap.
- Ask. A direct request for time.
The shape works because it sets clear expectations. They know you are not selling, they know what you need, they know why you are asking them. Most cold outreach fails because at least one of those is missing.
Once the meeting starts, repeat the framing in person and immediately drop into your first question. You set the agenda. You keep it on track. You propose next steps.
The meeting anti-pattern
Do not turn every conversation into a meeting.
You do not need a meeting to ask someone about their workflow. You need ten minutes at the right moment. If you are at a conference next to your target customer, do not ask them for coffee next week. Ask your most important question right now: “I’m curious, how did you end up doing X?”
Five minutes is enough to find out if a problem exists. Ten or fifteen is enough to find out how someone deals with it. An hour is what you need only when mapping a whole industry.
Rule of thumb: if it feels like they are doing you a favor by talking to you, the meeting is too formal.
Phone vs in-person
Phone and video calls are worse than in-person, despite the apparent time savings. People treat calls as scripted interviews because the medium forces it. You lose body language. You lose the ability to keep things casual. You miss the relationships that turn into warm intros for the next round of conversations.
Start in-person. If you absolutely cannot, fine, but do not use phone as a way to avoid the awkwardness of meeting people.
How many meetings
The UX community’s rule: keep talking to people until you stop hearing new things.
If your segment is tight and your industry is simple, that can be three to five conversations. If you have run more than ten and the feedback is still inconsistent, your segment is too broad. Slice it smaller and try again.
This is not about having a thousand meetings. The point is to learn fast and get back to building. You should be able to answer most early customer questions and move on within a week.
Running the process
Even if you ask perfect questions, you will get bad results without a process around the conversations.
The most common failure is the “learning bottleneck.” One person on the team goes to all the meetings, comes back, and tells everyone else what to do. Their head becomes the only repository of customer truth. The team has no way to challenge their interpretation. Rob did this at his first company hard enough that his CTO quit, saying they would never succeed if he kept changing what they were doing.
Avoiding bottlenecks has three parts: prepping, taking notes, and reviewing.
Prepping
Before any batch of conversations, sit down with your team and decide:
- Who is the focused, findable segment we are talking to?
- What are our three biggest learning goals?
- What commitment or next step are we pushing for at the end?
If you only have time for one prep question, make it: what do we want to learn from these guys? Without that, you are wasting both your time and theirs.
Two prep questions that surface hidden risks:
- If this company fails, what is most likely to have killed it?
- What would have to be true for this to be a huge success?
Quick gut answers are enough. You are not writing a strategy doc. You are just making sure you are facing the scary questions instead of dodging them.
Spend up to an hour writing best guesses about what the person you are about to talk to cares about. Do basic LinkedIn and website research before any B2B meeting. Five minutes of homework saves you from looking like an idiot.
If a question can be answered by desk research, do that first. Save the conversation for things the internet cannot tell you.
Who should show up
Two people is the sweet spot. One leads, one takes notes. The note-taker can also catch the lead asking bad questions or missing signals worth digging into.
Three or more is too much. It overwhelms the person you are interviewing.
One alone is fine once you are good at it, but harder, because there is nobody to catch your mistakes.
Tech founders should attend at least some conversations directly. If only the business person hears the customer, the tech person ends up taking the business person’s word as gospel, which makes the bottleneck worse. You cannot fully outsource customer learning. Hired guns soften bad news, and bad news is exactly what you need to hear undiluted.
Note-taking
Write down direct quotes whenever someone says something interesting. Wrap them in quotation marks so you know they are verbatim. You will use them later in marketing copy, fundraising decks, and arguments with skeptical teammates. When the exact words do not matter, just write down the idea.
Rob uses a symbol system for fast in-context tagging. You will probably not adopt his exactly. The point is to have some shorthand so you can scan your notes later and find the signal. His twelve symbols, in case you want to start there:
Emotions:
- :) Excited
- :( Angry
- :| Embarrassed
Their life:
- ☇ Pain or problem (lightning bolt)
- ⨅ Goal or job-to-be-done (soccer goal)
- ☐ Obstacle
- ⤴ Workaround
- ^ Background or context (mountain)
Specifics:
- ☑ Feature request or purchasing criteria
- ＄ Money, budget, or purchasing process
- ♀ Specific person or company mentioned
- ☆ Follow-up task
The pain symbol matters more when paired with an emotion. “Lightning bolt + angry face” is a different signal than “lightning bolt + neutral.” Combine them.
Where to write
Notes have to be sortable, mixable, retrievable, and separate from the rest of your stuff. Your regular notebook is usually a bad choice because the notes get buried in the noise.
Rob recommends:
- Index cards or post-its. One quote or one idea per card, with a symbol. After the meeting, write the date and name on each card. When you review, lay them out on the table and sort by symbol. If you decide to abandon the problem you were solving, you can pull out all the lightning-bolt cards and find a new one that has already been confirmed.
- Spreadsheets (Google Docs). Sortable, shareable, but writing on a laptop during a meeting is rude. Adds a transcription step after.
- A dedicated notebook. Fine if you remember to bring it.
Audio recordings sound useful but are usually not. You end up with hours of content and no way to find the specific thirty seconds you wanted. People will say yes to recording if you ask, but it kills the casual vibe.
If you cannot take notes during the chat, immediately retreat afterward and write down what was said while it is fresh. This is how Rob handles most pub and conference conversations.
Rule of thumb: notes are useless if you do not look at them.
Reviewing
After every batch of conversations, sit with your team and go through the notes. Not the whole transcript. The key quotes and the main takeaways.
Update your beliefs about the segment. Update your three big questions. Talk about which of your questions worked and which did not, so you get better at the meta-skill of running these conversations. This stuff is craft, not science. You only get better by reflecting on it.
Reviewing sounds like a non-step. It is tempting to skip. Do not skip it. The review is what stops the bottleneck and gets the learning into everyone’s head, not just yours.
How to use this with AI
If you are using an AI to prep for user interviews, paste this post (or the original book) into the context and try prompts like:
- “Given my product idea, draft 10 questions for a potential user. Every question must follow the rules in this post. No questions about my idea, no questions about the future, no opinion questions.”
- “Here are the 10 questions I plan to ask. For each, tell me if it passes or fails the Mom Test, and rewrite the failing ones.”
- “Here is a transcript from a call I just had. Identify every place I asked a bad question, accepted a compliment instead of deflecting, accepted fluff instead of anchoring, or wrote down a feature request instead of digging.”
The AI will not catch everything, but it catches most obvious failures. Use it as a fast critic of your draft questions before wasting a real person’s time.
The full process
Before a batch of conversations:
- If you have not yet, choose a focused, findable segment
- With your team, decide your three big learning goals
- If relevant, decide on the next steps and commitments you will push for
- Figure out who to talk to
- Write best guesses about what each person cares about
- Do desk research on anything the internet can answer
During the conversation:
- Frame the conversation
- Keep it casual
- Ask good questions which pass the Mom Test
- Deflect compliments, anchor fluff, dig beneath signals
- Take good notes
- If relevant, push for commitment and next steps
After a batch of conversations:
- Review notes and key quotes with your team
- Transfer notes into permanent storage
- Update your beliefs and plans
- Decide on the next three big questions
This is fast. Do not spend a week prepping. Spend an hour, then go talk to people. Do not spend months on full-time customer conversations. Spend a week or two, then ship something. Anything more is stalling.
Cheat sheet for the next thirty minutes before a user call
Goal: facts, commitment, or advancement. Not a compliment.
Three rules:
- Talk about their life, not your idea
- Ask about specifics in the past, not opinions about the future
- Talk less, listen more
Throw out questions that are: about your idea, about the future, opinion questions, “would you” questions, “do you ever” questions.
Keep questions that are: about the last time they did X, what they currently use, what they have tried, what it costs them now, why they bother, the implications of the problem, who else to talk to.
When they compliment you, deflect: “Thanks, but tell me, how are you handling this at the moment?”
When they fluff, anchor: “When was the last time that happened?”
When they ask for a feature, dig: “Why do you want that? What would it let you do?”
End with: a specific commitment in time, reputation, or money. A clear next step. An intro if relevant.
Signs the call failed:
- You talked more than they did
- They complimented you
- You don’t know what happens next
- You don’t have notes
- You weren’t scared of any question you asked
- You got a surprising answer and it didn’t change your thinking
- You aren’t sure what you were trying to learn
My take
The Mom Test is the rare business book that does not need to be longer than it is. The cheat sheet without the worked dialogues is missing the point, but the dialogues are the book, and reading them is what installs the underlying instinct: stop trying to get validation, start trying to find out what is actually true.
The hard part is not “ask about specifics in the past.” The rules are easy to recite. The hard part is sitting in a meeting where someone says they love your idea and not writing it down as a positive signal. The hard part is hearing “I would definitely buy that” and asking whether they have ever paid for something like it before, instead of doing a victory lap.
You can read this whole post and the whole book and still mess up your next three customer calls. That is fine. The point is that you start noticing the failures while they are happening, instead of weeks later when nobody buys. Once you can hear yourself ask a bad question and feel the wince, you have basically already learned the book.
If you only take three things from this post:
- Mention your idea as late as possible, much later than you think.
- Anything in the future tense is a lie. Anchor it to the past or throw it out.
- A meeting either gives you a fact, a commitment, or an advancement, or it failed. There is no middle category.
That is the whole book.