As developers, we're great at building things. But here's the uncomfortable truth: we often build the wrong things. Not because we lack technical skills, but because we're terrible at gathering honest feedback from potential customers.
I'm currently reading "The Mom Test" by Rob Fitzpatrick, and it's already changing how I think about customer conversations. This post covers the key lessons from the first chapters — I wanted to share them while they're fresh in my mind, both to help fellow developers and to solidify my own understanding.
Table of Contents
- Why We Collect Garbage Data
- The Three Traps That Fool Us
- Trap #1: The Compliment Trap
- Trap #2: The Fluff Trap
- Trap #3: The Idea Trap
- Keeping Your Ego Out of the Room
- When You Accidentally Become a Salesperson
- The Simplest Rule: Shut Up
- My Personal Cheat Sheet
- Wrapping Up
Why We Collect Garbage Data
Picture this: You've got a brilliant idea. You share it with friends, family, maybe some potential users. Everyone says "Wow, that's cool! I'd totally use that!" Feeling validated, you spend months building it. Launch day comes... crickets. No one buys.
Sound familiar? I've been there.
The problem isn't that people lied to you. The problem is that you asked the wrong questions and interpreted the answers incorrectly.
Fitzpatrick introduces a concept that hit me hard. The data we collect from conversations can mislead us in two dangerous ways.
First, we might abandon a perfectly viable idea because the feedback seemed negative — even though we just talked to the wrong people or asked poorly framed questions. That's a false negative.
Second, and more dangerously, we might convince ourselves our idea is golden because everyone seemed enthusiastic — when in reality, they were just being polite. That's a false positive, and it's the silent killer of startups.
The Three Traps That Fool Us
After reading the first chapters, I've identified three types of responses that feel valuable but are actually worthless:
- Compliments — When people say nice things about your idea
- Fluff — When people speak in generics, hypotheticals, or future promises
- Ideas — When people suggest features without you understanding why
Let me break down each one.
Trap #1: The Compliment Trap
Why Praise Is Poison
Nothing feels better than hearing "That's a great idea!" or "I love it!" after sharing your concept. Your brain releases dopamine. You feel validated.
But here's what I learned: compliments carry zero predictive value.
Think about it. When someone says "That's cool!", what are they actually telling you? Are they saying they'll pay for it? That they'll change their behavior to use it? That it solves a real problem they have?
No. They're just being nice.
Fitzpatrick points out that people hand out compliments for many reasons that have nothing to do with your product's viability:
- They want to support you emotionally
- They don't want to be the one to crush your dreams
- Your excitement is infectious and they're mirroring it
- They want to end the conversation gracefully
- They find the concept intellectually interesting (which doesn't mean they'd pay for it)
Here's a humbling thought from the book: even venture capitalists — people whose literal job is predicting which ideas will succeed — are wrong more often than they're right. If professional future-predictors can't reliably judge ideas, why would a random person's "I love it!" mean anything?
What Actually Matters
The book argues that the only feedback worth trusting comes from facts about past behavior and concrete commitments. Everything else is noise.
Instead of accepting a compliment and moving on, redirect the conversation:
Before:
Them: "That's a really cool idea!"
You: "Thanks! Glad you like it!"
After:
Them: "That's a really cool idea!"
You: "I appreciate that! Quick question though — how are you handling this problem today?"
See the difference? The second approach acknowledges the compliment but pivots to extracting actual information.
Red Flags That You're Drowning in Compliments
I've started watching for these warning signs in myself:
During conversations:
- I keep saying "Thanks!" or "Glad you like it!"
- I feel great but can't recall specific facts I learned
After conversations:
- I tell my team "That went really well!"
- I report that "Everyone loves the idea!"
- I can't answer basic questions like "What are they currently using?" or "How much time/money does this problem cost them?"
The book has a memorable line that I keep coming back to: compliments are like fool's gold — shiny and attractive, but ultimately worthless. Real gold is specific information about behavior, problems, and constraints.
Trap #2: The Fluff Trap
The Three Flavors of Empty Promises
Fluff is trickier than compliments because it sounds like real data. Someone gives you a specific-sounding answer, and you write it down thinking you've learned something. But you haven't.
I now categorize fluff into three types:
Generic Claims: Statements about what someone "usually" or "always" or "never" does.
When someone says "I always organize my inbox first thing in the morning," they're not describing reality — they're describing their idealized self. The person they wish they were. Fitzpatrick makes an insightful observation here: when people use generics, they're painting a portrait of who they aspire to be, not who they actually are.
Future Promises: Statements about what someone "would" or "will" do.
"I would definitely buy that!" feels like a commitment. It's not. It's a prediction about future behavior, and humans are terrible at predicting their own future behavior. We're consistently overoptimistic about what we'll do tomorrow.
Hypothetical Maybes: Statements using "might" or "could."
"I could see myself using that" means nothing. "Might" and "could" are escape hatches that let people sound supportive without committing to anything.
The Most Expensive Fluff in History
Fitzpatrick shares a painful story from his own experience that illustrates how costly fluff can be. At his first startup, the team kept hearing "I would definitely buy that!" from potential customers. They interpreted this as validation and pushed forward confidently.
The result? They lost around $10 million building something based on fluffy promises that never materialized into actual purchases.
That story stuck with me. Ten million dollars, gone, because the team couldn't distinguish between "I would buy that" (fluff) and "Here's my credit card" (commitment).
Anchoring: The Antidote to Fluff
The technique Fitzpatrick recommends is what he calls "anchoring." When someone gives you a fluffy answer, you anchor it to a specific moment in the past.
Here's how it works:
You: "Do you ever have trouble managing your tasks?"
Them: "Oh yeah, all the time."
You: "When's the last time that happened?"
Them: "Hmm, actually it was last Tuesday."
You: "Can you walk me through what happened?"
Now you're getting somewhere. Instead of a vague "all the time," you have a specific incident you can explore. You can ask what they tried, how they felt, what it cost them.
The book includes a great example about someone claiming to be an "Inbox Zero zealot." Instead of taking that at face value, the interviewer asked "What's your inbox look like right now?" and "When's the last time it totally fell apart?"
Suddenly the "I always have an empty inbox" claim transformed into "Actually, it blew up three weeks ago when I was traveling and took 10 days to recover." That's real data. That's a pain point you can potentially solve.
Questions That Generate Fluff (Avoid These)
I've started noticing which questions tend to produce useless answers:
- "Do you ever...?"
- "Would you ever...?"
- "What do you usually...?"
- "Could you see yourself...?"
- "How much would you pay for...?"
These aren't bad questions exactly — sometimes you need to start there. The mistake is treating the answers as meaningful. They're conversation starters, not conclusions.
Trap #3: The Idea Trap
Why Feature Requests Can Destroy Your Product
As developers, we love feature requests. Someone says "You should add Excel export!" and our brains immediately start designing the implementation. We feel productive. We're solving problems!
But Fitzpatrick warns that blindly implementing feature requests is the fast lane to a bloated, unfocused product.
The issue isn't that users' ideas are bad. It's that you don't understand why they want something. Without understanding the underlying motivation, you might:
- Build something complex when a simple solution would work
- Prioritize a nice-to-have over a must-have
- Lose focus on your core value proposition
- Create a Frankenstein product that tries to do everything
The MTV Disaster
The book contains a cautionary tale that perfectly illustrates this trap. At Fitzpatrick's startup, they were selling to MTV, which requested "analytics and reports" for their campaigns.
The team did what most of us would do: they took the request at face value and built a sophisticated analytics dashboard. It had tons of options, beautiful visualizations, the works. Technically impressive.
Then something strange happened. MTV kept calling every Friday asking the team to manually export and email them a report. The team added CSV export. MTV still called. They added PDF export. MTV still called. They added branded report templates. MTV still called.
Finally, someone asked the question they should have asked at the beginning: "Why do you need branded reports? What's wrong with the unbranded ones?"
The answer was deflating: MTV's clients expected a nice-looking report emailed to them weekly. That's it. Nobody actually read the reports or used the analytics. They just needed something professional-looking to forward along.
The team had spent months building a complex analytics platform when all MTV needed was a scheduled email with a pretty PDF attachment. An intern could have handled it manually.
All because nobody asked "Why do you want this?"
Digging Beneath the Request
Now when I hear a feature request, I try to understand the motivation before even considering implementation:
- "What would that feature allow you to do?"
- "How are you solving this problem today?"
- "What happens if we don't build this?"
- "Is this a dealbreaker, or could we launch without it?"
The book suggests that when someone asks for a specific feature, they've often already jumped to a solution. Your job is to uncover the problem they're trying to solve. There might be a simpler way to address it.
Emotions Are Signals Worth Exploring
One insight I found valuable: strong emotions are goldmines.
If someone seems frustrated, angry, embarrassed, or excited about something, dig into it. Ask:
- "Tell me more about that."
- "That seems to really bother you — what's the story there?"
- "Why hasn't this been solved already?"
- "What makes this such a big deal?"
People love talking about their frustrations. You're not being intrusive — you're giving them permission to vent. And in that venting, you'll find real problems worth solving.
The book's rule here: understand feature requests, but don't blindly obey them.
Keeping Your Ego Out of the Room
The Pathos Problem
Here's something uncomfortable I realized about myself: when I share an idea I care about, I'm unconsciously fishing for validation.
Fitzpatrick calls this "The Pathos Problem." When people sense that you're emotionally invested in something, they instinctively want to protect your feelings. Even if you explicitly ask for honest criticism, they'll pull their punches.
It's human nature. If someone says "I quit my job to build this — what do you think?", most people won't respond with brutal honesty. They'll find something nice to say, even if they think the idea is terrible.
The symptoms are subtle:
- "I'm thinking of starting a business... do you think it'll work?"
- "I had this idea I'm really excited about — do you like it?"
- "Be honest, I can take it!"
That last one is particularly insidious. Saying "I can take it" doesn't make people more honest — it just confirms that your ego is on the line, which makes them more likely to be gentle.
The Solution: Make It About Them
The antidote is keeping the focus on the other person's life, problems, and behavior — not on your idea.
Instead of asking "Would you use my product?", ask "How are you dealing with X problem today?"
Instead of pitching your solution, explore their world. What tools do they use? What frustrates them? What have they tried before?
When the conversation is about them rather than you, people have no reason to protect your feelings. They're just describing their reality.
An interesting note from the book: some entrepreneurs like Elon Musk or Gordon Ramsay are famous for demanding harsh feedback. But that works for them precisely because nobody worries about hurting their feelings. For the rest of us, it's better to structure conversations so ego never enters the equation.
When You Accidentally Become a Salesperson
The Pitch Trap
There's another mode that kills learning: getting "pitchy."
You know the feeling. You start explaining your idea, get excited, and suddenly you're five minutes into a monologue while the other person nods politely. You're no longer having a conversation — you're delivering a presentation.
The book points out an irony here. The "won't take no for an answer" attitude that helps founders push through obstacles becomes a liability when you're trying to learn. If you won't let someone express doubt or disinterest, you're just collecting forced compliments.
Signs you've gone pitchy:
- "No, no, I don't think you understand..."
- "Yes, but it also does THIS!"
- The other person has barely spoken for several minutes
- You're addressing objections they haven't even raised
Recovering Gracefully
What I appreciate about the book is its acknowledgment that slipping into pitch mode is natural. You're excited about your idea. That's good! Otherwise, you wouldn't be doing this.
The key is catching yourself and course-correcting:
"Sorry — I just realized I've been rambling about my idea. I get excited about this stuff. Can we go back to what you were saying about your workflow?"
If they genuinely want to hear more about your product, offer to explain at the end of the conversation. But protect the learning part first.
The memorable rule: if you're being annoying enough, anyone will eventually say your idea is great just to end the conversation. That's not validation — that's surrender.
The Simplest Rule: Shut Up
Learning Requires Listening
The final lesson from these chapters might be the most important:
You cannot learn while you're talking.
This is hard for me. When someone says something I have a great response to, my instinct is to jump in. If they misunderstand something about my idea, I want to correct them immediately.
But Fitzpatrick argues both impulses are mistakes.
When someone starts explaining their mental model — "So it's kind of like Uber for..." — they're giving you a glimpse into how they think. If you interrupt to "fix" their understanding, you lose that insight. You'll have time to explain later.
Plus, it's just annoying. Nobody likes being cut off, especially when they're trying to help you.
I've started applying a simple test: if I'm talking more than listening, the conversation is failing.
My Personal Cheat Sheet
After processing these chapters, I created a reference sheet for myself:
Questions That Extract Real Data
- "How are you dealing with this problem today?"
- "When's the last time this happened? Walk me through it."
- "What solutions have you tried? Why didn't they work?"
- "What does this problem cost you in time/money/frustration?"
- "Why do you want that feature? What would it let you do?"
Questions That Produce Garbage
- "Would you use something like this?"
- "Do you think this is a good idea?"
- "How much would you pay?"
- "Would you ever...?"
Signs I'm Getting Real Data
✅ I learned something surprising
✅ I can describe their current process in detail
✅ I know what they've tried before and why it failed
✅ I understand their constraints
✅ Even a "no" taught me something useful
Signs I'm Getting Garbage
🚨 I'm doing most of the talking
🚨 I'm hearing lots of compliments
🚨 I feel validated but can't cite specific facts
🚨 I don't know what they're currently using
🚨 They said "I would definitely buy that"
Wrapping Up
These lessons are challenging my instincts as a developer.
When someone describes a problem, I want to immediately architect a solution. When someone compliments my idea, I want to bask in it. When someone suggests a feature, I want to add it to the roadmap.
But the best code in the world is worthless if it solves the wrong problem. And the only way to find the right problem is to have conversations that extract truth rather than validation.
I'm still early in the book, but these principles are already changing how I approach customer conversations:
- Compliments are noise — Redirect to behavior and facts
- Fluff is dangerous — Anchor everything to specific past events
- Ideas need excavation — Understand the "why" before the "what"
- Ego invites lies — Keep the focus on their life, not your idea
- Talking is failing — Learning happens in the silence
I'll likely write more as I continue through the book. But for now, my main takeaway is this: your customers have the answers. Your job is to ask the right questions and then shut up long enough to hear them.
What about you? Have you fallen into any of these traps when talking to potential customers? I'd love to hear your experiences in the comments.
This post covers lessons from the early chapters of "The Mom Test" by Rob Fitzpatrick. I highly recommend reading the full book if you're serious about building products people actually want.
I've also written a longer, more detailed version of this post on my personal website. If you want to dive deeper into these concepts, feel free to check it out — it's completely free, no sign-up or sign-in required. My goal is simply to learn and share as much as I can.
Currently reading: Chapters 1-2 ✅ | More insights coming soon...
Top comments (0)