Empathy gets dismissed as a soft skill. Something for the people side of the job, irrelevant to the actual decisions about what to build.
That framing is wrong twice over. First, soft and unimportant aren't synonyms. Second, in product, empathy isn't a personality trait — it's a working mechanism. It's how you turn user evidence into decisions instead of into a deck nobody acts on.
The teams that build the right thing aren't the ones with the cleverest strategy. They're the ones who understood the user well enough that the strategy was obvious.
What empathy actually does in product
The function isn't "be nice to users". It's the ability to hold the user's reality in your head clearly enough that you can predict how they'll react to what you're about to ship.
That's a working tool. When you have it, you ask better discovery questions, because you know what's likely to be ambiguous. You write better tickets, because you can see where the user is going to get stuck. You prioritise differently, because you can feel which fixes will compound and which are cosmetic.
When you don't have it, you over-rely on data. The metrics tell you what happened. They don't tell you why. Empathy is the layer that translates "drop-off at step three" into a hypothesis worth testing.
Without it, you keep running experiments against the wrong hypothesis. With it, you know which experiment is worth running before you build anything.
Why teams underweight it
Three reasons empathy gets pushed aside:
It's hard to measure. You can't put empathy on a dashboard. So in cultures that only respect what's measurable, it gets coded as decorative. The work happens, but it doesn't get credited or protected.
It looks like a personality trait. Some PMs are naturally curious about users. Some aren't. The framing makes it sound like fixed wiring — you either have it or you don't. That's wrong. Empathy in this sense is a practiced muscle, not a temperament. People who build the habit of regular user contact get better at it. People who don't, don't.
It's slower in the short run. Watching a user struggle through your onboarding for the third time is uncomfortable. Skipping that and going to opinions is faster. The cost shows up later, when you've shipped the third revision of the wrong fix and still haven't moved the metric.
What practiced empathy looks like
It's not a state. It's a small set of habits that compound.
Watching, not just listening. Most user research happens through scheduled calls. Useful, but not enough. Watching a user actually use the product — clicking, getting stuck, swearing under their breath — gives you something an interview never will. The cognitive load they're carrying through your interface is invisible until you see it.
Holding the contradiction. Users say one thing in interviews and do another in the product. That's not deception — it's how humans work. The empathic move is to take both seriously. The interview tells you what they value. The behaviour tells you what they tolerate. The truth is between them.
Letting their priorities shape yours. The hardest part. When the team is excited about feature X and the users keep asking for feature Y, empathy is what makes you genuinely consider that the users might be right and the team might be wrong. Not always — sometimes users ask for solutions when their actual problem is something else. But the willingness to be persuaded is the part that matters.
Where it shows up
A few places empathy shows up as a competitive advantage:
Onboarding. The teams with the highest activation rates aren't the ones with the most A/B tests. They're the ones who understood the new user's confusion well enough to design around it the first time.
Support. The teams that respond to support tickets with "have you tried turning it off and on" lose customers. The ones that respond with "I see what you were trying to do — here's what's happening" keep them. Empathy is the difference.
Pricing. The teams that price well understand which parts of the product feel valuable and which feel like table stakes. That's user empathy at the commercial layer.
The shift
Empathy in product isn't a soft skill. It's a working tool that the best PMs deploy constantly and the rest leave on the shelf.
Build the habit. Watch users use the product. Take the contradiction between what they say and what they do as a feature, not a bug. Let what you learn change what you build.
The right thing usually isn't far from the obvious thing — once you've actually understood the user.
If you're making discovery a habit, not a phase, empathy is the muscle that makes the habit useful. And if you're building for the user, not the roadmap, empathy is what tells you when to override the plan.