The Mom Test for founders: questions that get honest answers

Technical founders are usually good at building. That strength becomes expensive when it lets you turn an untested assumption into a polished product before you have learned whether the problem matters.

The risk is not theoretical. In March 2026, CB Insights reviewed 431 VC-backed companies that had shut down since 2023. It could identify failure reasons for 385 of them, and poor product-market fit appeared in 43% of those cases. The companies often named more than one cause, so this is not proof that a few interviews would have saved every startup. It is a reminder that building well does not compensate for learning about the wrong problem.

That is the gap Rob Fitzpatrick’s The Mom Test was written to close. The book’s provocative premise is that customer conversations are full of polite, optimistic, low-cost answers. People usually are not trying to deceive you. They are trying to be helpful, avoid awkwardness, and respond to the enthusiasm in front of them.

The practical question is therefore not, “How do I get people to approve my idea?” It is, “How do I ask questions that remain useful even when people want to be kind?”

This guide turns that idea into a working interview method: three rules, question rewrites, a five-question script, and a way to separate pleasant feedback from evidence.

Why ordinary founder questions produce bad data

A founder says, “We are building an AI assistant that prepares the weekly report. Would you use that?”

The participant can see the desired answer. Saying yes is easy. It keeps the conversation warm, rewards the founder’s excitement, and costs nothing. The founder leaves with a quote. The participant leaves without making a decision.

Paul Adams describes this failure mode in Intercom’s guide to asking customers what you want to hear. Questions about future use invite people to predict behaviour and infer what the interviewer hopes to hear. Questions about a recent real event give you context, constraints, and actions instead.

Leading wording makes the problem worse. Nielsen Norman Group’s guidance on leading questions shows how easily a question can suggest the answer or reveal the researcher’s assumptions. “Was setup easy?” names the preferred judgement. “What happened when you first tried to set it up?” leaves room for an answer you did not anticipate.

The problem is not that participants are unreliable people. The problem is that the interview asks them for evidence they do not have: a confident prediction about an imaginary future.

The three Mom Test rules

Y Combinator’s official transcript of Eric Migicovsky’s talk on how to talk to users explains the method through three recurring founder mistakes: talking about the idea, talking in hypotheticals, and talking too much. The practical rules are the inverse.

1. Talk about their life, not your idea

Your idea changes the social conditions of the interview. Once you explain the product, the participant starts evaluating your solution instead of describing their world.

Keep the conversation on what already exists:

• what they were trying to achieve;
• what happened the last time;
• which people, tools, and workarounds were involved;
• what the problem costs in time, money, risk, or attention;
• what they have already tried to change.

If the problem matters, it should appear in their life without a detailed pitch from you. If it does not appear, that absence is useful. It may mean the problem is rare, weak, owned by someone else, or already solved well enough.

This does not mean you must conceal who you are. It means you separate learning from selling. Explain the context briefly, ask about their experience, and save the demo for another conversation.

2. Ask about a specific past event, not a generic future

People answer future questions with an idealised version of themselves. They expect to exercise more, stay organised, adopt the new workflow, and remember the feature. Product plans built on those intentions tend to inherit the optimism.

Teresa Torres’ story-based interview guidance recommends grounding the conversation in a specific instance of past behaviour. “How do you usually prepare the report?” invites a neat summary. “Tell me about the last report you prepared” gives you a day, a deadline, a spreadsheet, an interruption, and the shortcut they forgot to mention in the summary.

Recent stories are not perfect records. Memory still compresses and reconstructs events. They are simply stronger than a prediction that has never met a real constraint.

3. Talk less and listen more

Founders are practised at pitching. Interviews require the opposite muscle.

Ask one clear question. Let the participant finish. Leave enough silence for the second sentence. Follow their language instead of replacing it with your product terminology. When they mention a workaround, do not explain how your roadmap will remove it. Ask them to show or reconstruct the workaround.

Indi Young’s work on listening deeply pushes this further: listen for the person’s inner thinking, emotional reactions, and decision rules, not only the actions that fit your guide. The useful insight is often in a side comment that a rushed interviewer would skip.

Mom Test examples: ask this, not that

The method becomes easier when you can see the rewrite pattern.

Every rewrite does one of three things: removes your solution, moves from future to past, or opens a closed judgement into a story.

Nielsen Norman Group’s guide to open-ended questions offers useful stems: “Walk me through...”, “Tell me about a time...”, and “What happened when...?” Closed questions still have a place for clarification. Use them after the story, not instead of it.

A five-question script for your next interview

Migicovsky’s Y Combinator talk gives founders a compact sequence that works for early problem interviews. Use it as a spine, not a rigid questionnaire.

1. What is the hardest part about doing this?

This opens the problem space without naming your solution. If the participant chooses a different difficulty from the one you expected, follow it. Discovery is supposed to change your map.

2. Tell me about the last time you encountered that problem

Stay with the event. Ask where they were, what triggered it, who was involved, what they tried, and what happened next. A vague answer needs a more specific prompt, not a new topic.

3. Why was that hard?

Ask this gently and make the target clear. You are not asking the participant to defend themselves. You are trying to understand the consequence: delay, duplicated work, risk, embarrassment, lost revenue, or something else.

If “why” makes the conversation feel accusatory, use “What made that difficult?” or “What was at stake?”

4. What, if anything, have you done to solve it?

Existing action is stronger evidence than enthusiasm. Look for tools bought, spreadsheets built, colleagues asked, consultants hired, or processes changed. Doing nothing is also evidence. The problem may not be urgent enough to displace other work.

5. What do you dislike about the solutions you have tried?

This reveals the gap in the current market without asking the participant to design your product. Keep probing for specific incidents. “It is clunky” is a label. “Last Thursday I exported the data and rebuilt the chart because the totals did not match” is something you can investigate.

End by asking whether there is another person who sees the problem differently. In B2B research, the buyer, admin, and daily user often live in different versions of the same workflow.

Before the call, decide what you need to learn

The Mom Test is a question discipline, not a substitute for a research plan.

Write down one product decision before you recruit anyone. For example: “Should we spend the next sprint reducing the manual handoff between support and engineering?” That is better than “learn what users think about support” because it tells you which people and events can produce useful evidence.

Then define the behaviour that puts someone inside the study. Recruit people who handed off a support issue in the last month, not “customers who use support”. Include people whose handoff went well and people whose handoff failed. If you recruit only the loudest critics or closest champions, even neutral questions will produce a distorted picture.

Finally, write down what would change your mind. Perhaps the handoff rarely causes delay, the workaround is good enough, or the real bottleneck belongs to another team. Naming those possibilities makes it easier to recognise disconfirming evidence when it appears.

A useful one-page plan contains:

• the decision the research will inform;
• the recent behaviour participants must have;
• the assumption you are most likely to defend;
• three broad questions and likely probes;
• the evidence that would make you continue, change direction, or stop.

Do not send the participant a product pitch disguised as an agenda. Tell them the area you want to understand and why their experience is relevant. Keep the solution out of the invitation unless the study genuinely requires showing it.

Evidence is behaviour that costs something

Compliments are not useless as social signals. They are simply weak product evidence.

Stronger evidence has already cost the participant something:

• time spent on a workaround;
• money paid for an imperfect tool;
• reputation risk in asking a colleague for an introduction;
• a booked follow-up with the real decision-maker;
• agreement to test a pilot;
• a purchase or pre-order where that is appropriate.

Do not force commitment at the end of every research call. The ask must fit the stage and the relationship. But notice the difference between “keep me posted” and a concrete next step. One is pleasant. The other changes behaviour.

The same discipline applies to negative evidence. If someone says the problem is annoying but has never tried to solve it, cannot recall the last occurrence, and will not spend another fifteen minutes on it, do not rescue the idea with a better pitch. Record what happened.

After the call, separate evidence from interpretation

Founder bias does not end when the recording stops. It often becomes stronger during synthesis, when one vivid compliment can outweigh three quiet examples of indifference.

For each conversation, write three short blocks:

1. What happened: observable actions, direct statements, tools used, sequence, and consequences.
2. What it might mean: your interpretation, clearly labelled as interpretation.
3. What to check next: a question for another participant, an analytics check, or a behaviour to recruit around.

Keep the participant’s exact language where it carries meaning, but do not turn every memorable sentence into a theme. Compare incidents across people. A pattern is stronger when the same underlying behaviour appears in different words and weaker when several people merely repeat a phrase you introduced.

This is where interview evidence and product data should meet. If people describe a painful setup step, inspect completion and support data around that step. If analytics shows a drop that nobody mentions, recruit people who experienced the drop and ask them to reconstruct it. Neither source automatically outranks the other; the mismatch is a research question.

Structure the conversation broad to narrow

Good questions can still fail in the wrong order.

Steve Portigal’s Interviewing Users and NN/g’s interview guidance both support a funnel: begin with the participant’s context, then narrow towards the event and the details that matter.

A simple 30-minute structure looks like this:

1. Context, 5 minutes: role, workflow, people involved.
2. Recent event, 12 minutes: what happened before, during, and after.
3. Current alternatives, 7 minutes: tools, workarounds, spending, and trade-offs.
4. Consequences, 4 minutes: what the problem changes or costs.
5. Close, 2 minutes: missing perspectives and a proportionate next step.

Do not treat the timings as a script. If the participant reaches the useful story in minute three, follow it. A guide exists to protect the research question, not to prevent listening.

Ask the question that could prove you wrong

Validation-seeking questions make interviews feel successful. Falsifying questions make them useful.

Before the call, write down the assumption that matters most. Then write one question whose honest answer could weaken it:

• “When did this last happen?”
• “What happens if you do nothing?”
• “Where does this sit among the other problems on your list?”
• “Who owns the budget for fixing it?”
• “What have you stopped trying because it was not worth the effort?”

If every answer supports your idea, inspect the questions before celebrating the result. You may have recruited only fans, described the solution too early, or rewarded agreement with your tone.

The goal is not to become pessimistic. It is to make being wrong cheap.

Where Maren fits

Maren is useful when the problem is not knowing the rules, but running enough disciplined conversations to keep learning.

Maren is built around the same practical behaviours this guide recommends: neutral prompts, specific past events, patient follow-ups, no pitching, and synthesis across conversations. That does not mean every AI-moderated interview is automatically good, or that Maren replaces a skilled human researcher in open-ended, high-stakes discovery. The research question, participant selection, and guide still matter.

For a focused problem, churn, onboarding, or feature-feedback study, Maren can run structured conversations asynchronously and bring back the stories and themes with their evidence attached. The founder still decides what the evidence means and what to build.

Whether you conduct the interviews yourself or use Maren, the standard is the same: talk about the participant’s life, ask about what actually happened, and listen long enough to hear an inconvenient answer.