I thought I wasn't leading customers. Then I listened to The Mom Test.

I’ve always tried not to lead people when asking about a product or a problem. I know that if I put the answer into the question, I can’t put much trust in what comes back.

But after listening to Rob Fitzpatrick’s The Mom Test, I recognised that I was still doing some of the things I thought I was avoiding.

That was the useful, slightly uncomfortable part. Agreeing with the principle of asking unbiased questions doesn’t mean you consistently ask them.

For me, the book has become a reason to look more closely at how I approach product conversations: what I ask, when I introduce an idea, and how quickly I decide an answer supports it.

Why this matters in product management

As a product manager, you often enter a conversation with context the other person doesn’t have. There may already be a feature being discussed, a stakeholder pushing for a change, or a roadmap decision approaching.

That context can quietly shape the interview.

You might avoid asking, “Don’t you think this is a good idea?” while still asking, “Would having everything in one dashboard make this easier?”

It sounds reasonable. But you’ve already chosen the solution, suggested the benefit, and made agreement easy.

If someone says yes, what have you learned? They might have a serious problem. They might like the general idea of less work. They might be trying to be helpful.

Those answers have very different implications for a roadmap.

My takeaway from The Mom Test is to spend more of the conversation on the person’s actual experience: specific situations, what they did, and what happened next. The book’s core guidance is to focus on their life rather than your idea, ask about past specifics rather than imagined futures, and listen more than you talk.

The questions I want to be more careful with

The examples below are illustrative product conversations, not quotes from my own interviews or from the book.

“Would you use this feature?”

This asks someone to predict their behaviour without having to make a real choice. Saying yes costs nothing, and the imagined feature has none of the inconvenience of adoption.

A more useful starting point is:

“What did you do the last time you needed to solve this?”

Then follow the answer. What did they use? Who helped? Where did they stop? An existing workaround gives you something concrete to investigate.

“Would an automated report save you time?”

This supplies the solution and the benefit before establishing whether reporting is a meaningful problem.

Instead, try:

“Talk me through how you prepared your most recent report.”

If they describe delays, ask where those happened. Perhaps generating the report was easy, but getting someone to approve the numbers was difficult. Automating the wrong step could leave the real problem untouched.

“How frustrating is the current process?”

Even a question about the current experience can lead. This one assumes frustration.

Start with:

“How did the process go last time?”

Then, if they mention difficulty, explore it in their words. “You said that part was awkward. What happened?” is more grounded than assigning an emotion for them.

“What features would you like?”

Feature requests are useful starting points, but they don’t explain the situation behind them. They can also push someone into designing your product before you understand their goal.

If someone asks for an export button, ask:

“What were you trying to do the last time you needed an export?”

They might be sharing information with a colleague, reconciling data, or working around an access restriction. The same request can hide very different needs.

“Would you pay for this?”

Hypothetical willingness to pay is easy to overinterpret, especially when the person you’re speaking to doesn’t control the budget.

Ask what they currently spend money or time on, what alternatives they’ve tried, and how a similar purchase was approved. Later, when there is a clear offer, an actual buying decision tells you more than enthusiasm during an interview.

The skills behind getting useful answers

Changing the question list helps, but I don’t think a better script is enough. You also need to manage your own behaviour during the conversation.

Listen without preparing your pitch. If someone describes a problem your idea might solve, resist immediately explaining the feature. Stay with their experience long enough to understand the details. Introducing the solution too early can redirect the rest of the conversation towards evaluating it.

Get comfortable with a pause. It’s tempting to fill silence by suggesting an answer: “Was it because the system was too slow?” Give the person room to think. If they need help, ask them to walk through what happened rather than offering your explanation.

Notice vague language and follow up. “We do that all the time” leaves a lot unanswered. “When did it last happen?” and “What happened after that?” help establish frequency and consequences. Ask one question at a time; a stack of questions usually gets a partial answer.

Be curious without making people defensive. Someone’s workaround may look inefficient from the outside but make sense given their permissions, workload, or organisation. “What led you to handle it that way?” gives them room to explain. The conversation should feel safe enough for them to admit that they abandoned a task or don’t care about the problem you expected to find.

Separate evidence from interpretation. If someone says they copied figures into a spreadsheet, record that. Don’t silently upgrade it to “needs an analytics dashboard.” That second statement is a product hypothesis. Keeping the two separate makes it easier to challenge your own conclusions later.

Let an answer weaken your idea. This is probably the hardest part. A conversation can be useful even when it makes a proposed feature less convincing. If the issue is rare, already handled well, or less important than something else, that should affect the decision.

How I want this to change my product work

I want to judge a conversation by what I understand afterwards, rather than how positive it sounded.

Before an interview, that means being clear about the uncertainty I’m trying to reduce. Is this problem happening? Who experiences it? What does it prevent them from doing? What evidence would make me reconsider its priority?

During the conversation, I want to start with a recent example and follow the sequence of events. If I catch myself leading, I can acknowledge it and reopen the question: “I’ve suggested a solution there. Can we go back to how you handled it last time?” That won’t erase the influence, but it’s better than continuing as if the answer were independent.

Afterwards, I want to keep what the person said separate from what I think we should build. I also want to record what remains unknown and look for contradictory examples across other conversations.

One detailed interview still doesn’t establish how common a problem is. Interviews need to sit alongside other evidence, such as usage data, support requests, and appropriately designed tests. Recalled behaviour can be incomplete too; where appropriate and with permission, seeing the actual workflow can help.

There is still a place for showing a prototype and asking for reactions. I want to make that a deliberate part of testing a solution, after understanding the problem, rather than letting a discovery conversation drift into a pitch.

I’m not coming away from The Mom Test thinking I’ve mastered this. I’m coming away noticing where good intentions weren’t enough.

For my next product conversation, I want to prepare fewer questions about what someone might use and spend more time understanding something they have already done.

---

Inspired by The Mom Test by Rob Fitzpatrick. The product-management examples and reflections here are my application of its ideas, rather than direct quotations from the book.