When I take over a product team, whether it’s at an IoT company or anywhere else, my first move is to listen and learn before I change anything. One of the first meetings I sat in on at that IoT company was with one of my product managers, in what I expected to be a routine requirements-gathering session with a customer.
It didn’t stay routine for long.
The customer was explaining what they needed. The PM was explaining why they were wrong. Not disagreeing; arguing. And the frustrating part was that he wasn’t inexperienced; quite the opposite. He was a seasoned engineer who’d seen versions of this problem dozens of times. He’d also convinced himself he already understood this one, so instead of listening, he was waiting for his turn to speak, evaluating the request against an answer he’d already settled on.
He wasn’t missing technical skill. He was missing empathy for what the customer was actually dealing with, and that gap was doing more damage in the room than any wrong answer could have.
The Expertise Trap
We treat domain expertise as a straight upgrade; more years, more pattern recognition, better decisions. It usually is. But it carries a quiet failure mode, a drift through three stages:
“I’ve seen this before.” → “I know what this is.” → “I know what they need.”
That last jump is where expertise crowds out empathy. The more problems you’ve solved, the easier it becomes to evaluate a customer’s request against your own model of the problem instead of trying to see it through their eyes. Junior PMs default to empathy more naturally, not because they’re more caring, but because they haven’t built up enough pattern-matching yet to skip the step of imagining someone else’s situation. That’s worth protecting on purpose as you gain experience, not losing to it.
Empathy Is a Product Skill, Not a Soft One
Empathy gets treated as the gentle counterpart to “real” product skills like prioritization, architecture, and roadmap strategy. That’s a mistake. Empathy is how you gather better data.
If I understand what a customer is actually dealing with day to day, not just the feature they’re asking for, I have better information to make a product decision with. A request that looks unreasonable in isolation often makes complete sense once you understand the operational reality behind it: the workaround they’ve built, the manual process they’re stuck running every morning, the person they have to answer to when something breaks. You don’t get access to that context by evaluating a request. You get it by putting yourself in their position long enough to ask about it.
The customer owns the problem. We own the product. Our job isn’t to blindly build whatever they ask for; it’s to understand the problem well enough, from their side of it, to decide whether, how, and when to solve it. Try trading:
- “Why do you need that?” → “Walk me through what you’re trying to accomplish.”
- “That won’t work.” → “What’s driving that requirement?”
- “We already have a feature for this.” → “How are you handling this today?”
None of these commit you to building anything. They just put you in the customer’s seat before you evaluate the request from your own.
What Losing That Empathy Actually Costs
When “I already know the answer” becomes a team’s default posture, the cost compounds in three places:
- Slower root-cause work. Teams solve the problem they assumed instead of the one the customer is actually living with, and rework eats whatever time the shortcut saved.
- Customer trust erosion. Customers stop explaining context once they learn it gets talked over instead of understood. They start working around the product team instead of with them.
- Lost signal from junior staff. The people most likely to ask the empathetic question, the one that would’ve surfaced the real issue, learn to stay quiet once they see it dismissed by someone more senior.
Practicing Empathy on Purpose
None of this means distrusting your own experience. It means treating it as a hypothesis to test against someone else’s reality, not a conclusion to defend.
- Ask before you diagnose. “Walk me through what you’re trying to accomplish” puts you in their situation faster than jumping to a fix, even when you’re fairly sure you already know it.
- Notice when you stop asking questions. That’s rarely a sign you’ve mastered the problem. It’s usually a sign you’ve stopped imagining what it’s like on the other side of it.
- Weight the room toward the newest person in it. They haven’t learned yet which questions are supposedly beneath asking, and they haven’t lost the habit of picturing themselves in the customer’s shoes. That’s a feature, not a gap to correct.
Empathy Beats Certainty
Having an opinion is easy. Earned experience makes it easier still, which is exactly why it’s dangerous; it lets you stop imagining the customer’s side of the story and start assuming you already know it. Seeing the problem the way they see it is the harder, less comfortable job, and it’s the one that actually separates good product leaders from merely experienced ones.
The next time a customer’s request sounds off-base, or a junior teammate asks a question you’re sure you already know the answer to, pause before you answer. Put yourself in their position first. The moment you’re certain you already know how someone else sees a problem is usually the moment you’ve stopped trying to; and in product, that’s when things start going wrong.