Empathy is discovery, not projection
The word empathy does a lot of damage in product work, because it lets people imagine the user instead of meeting one. Sitting quietly and picturing someone’s frustration is not empathy. It’s fiction with a flattering name.
The version that works is unglamorous: ask people what happened, in order, last time.
Stories, not solutions
“What would you like this to do?” returns a feature request, filtered through what the person believes is buildable and what they think you want to hear. “Walk me through the last time you had to do this” returns a sequence of events, including the parts they’ve stopped noticing.
The interesting material is always in the parts they’ve stopped noticing. The tab they keep open. The colleague they ping to check a number. The step they do twice because once it silently failed and they never trusted it again.
Nobody reports these. They aren’t complaints anymore; they’re just the job.
Edge users carry the constraints
Spend disproportionate time with the people the product fits worst — the highest volume account, the one on a bad connection, the one whose compliance team reads everything. They surface constraints that everyone has and only they have hit hard enough to articulate.
Design for the median and the edge breaks. Design for the edge and the median is usually fine.
The useful remark almost never arrives as feedback. It sounds like “I keep that tab open so I can copy the ID across” — said in passing, as background, because it stopped being a problem years ago and became part of the job. Nobody files a ticket for it. It won’t appear in any survey. And it names a missing thing more precisely than anything in the backlog.
Where it breaks
Two ways, and both are common.
Edge users can capture the roadmap. The one demanding, articulate account is not more representative for being louder. Some constraints they surface are universal; some are theirs alone, and the difference is not visible from inside a single interview. If you can’t find a second customer with the same problem, you have a support relationship, not a product insight.
Empathy is not a decision procedure. Research tells you what people experience. It does not tell you what to build, and it never resolves a trade-off between two groups who both have real needs. Teams that lean hardest on user research often struggle most with prioritisation, because “the users said” feels like it should settle things and doesn’t. Someone still has to decide, and own it.
Also worth saying: people are unreliable narrators of their own behaviour. They under-report effort and over-report intention. The story is the raw material, not the finding — you still have to watch what they do.
Takeaway: observe problems before inventing solutions.