🎯 Who Owns the User’s Pain?

Every product team talks about user experience. Fewer teams can point to who is actually responsible for understanding the user.

And that gap matters.

Because when no one clearly owns user pain, teams don’t stop building. They just build the wrong things, faster, with great confidence.

This post is about why user understanding is foundational to good software, how empathy erodes over time, what role Product Managers truly play, and why a little healthy tension between Product and Engineering is not only normal—it’s necessary.

🧩 User Experience Is Not a Feature

User experience isn’t UI polish. It isn’t animations. It isn’t a usability checklist you run before release.

User experience is the sum of every interaction someone has with your product:

• The clarity of the mental model
• The friction in common workflows
• The error states and escape hatches
• The time it takes to recover from mistakes
• The emotional residue after using the product

When UX is treated as a layer instead of a foundation, teams optimize for shipping rather than solving.

🔍 Understanding the User Is a Discipline

“Knowing the user” is not a vibe. It’s not intuition. And it’s definitely not guessing based on internal preferences.

Real understanding comes from:

• Direct conversations
• Observing behavior, not just listening to requests
• Identifying recurring friction
• Separating symptoms from root causes

A user saying “this is confusing” is not asking for a tooltip. They’re telling you their mental model doesn’t match yours.

🫂 A Personal Note on User Empathy

I’ve spent years sitting next to users while they used products I was actively developing.

I’ve listened to people narrate their thoughts as they followed user-testing scripts—confusion, delight, frustration, relief. I’ve watched recordings of users verbalizing what they were trying to do versus what the product allowed them to do. I’ve walked college campuses with a tablet, stopping random students for impromptu usability tests. I’ve been on teams that invited users in for nights of free pizza and drinks just to watch reactions, test new ideas, and learn how we could do better.

I’ve also been on teams where eating your own dogfood wasn’t a slogan—it was doctrine.

What all of this taught me is simple and uncomfortable: user empathy doesn’t happen by accident.

You don’t stumble into understanding users. You earn it continuously, through repetition, exposure, and humility.

That’s why I struggle to understand how teams build solutions without first deeply understanding their audience—without genuinely putting themselves in the user’s place, accounting for their context, constraints, and mental state.

And yet, in my time working in infrastructure and engineering platform organizations, I’ve seen the same pattern repeat.

User experience becomes an afterthought.

It’s treated like good documentation or adequate regression testing—a nice-to-have. Something revisited only after a product or feature is fully implemented and released in a trial phase. Then the realization kicks in:

We missed something.
We misunderstood the flow.
We ignored user context.
We assumed the mental model.

Platform teams, in particular, are vulnerable here. When your users are "other engineers," it’s dangerously easy to assume shared context—and ship abstractions that technically work but emotionally repel. 🌶️

Often, avoidance is rationalized as pragmatism. It’s hard. It’s tedious. Or it competes with what teams really want to do—build cool things.

But watching users actually find value in something you built? That’s where the real joy lives.

I still remember watching people play a mobile game I built—laughing in enjoyment, yelling in frustration, hammering their tiny screens with wild determination. That feedback loop was immediate, visceral, and deeply motivating.

That’s the feeling teams lose when user experience becomes optional.

🧠 Why Engineers Drift from User Empathy

Most engineers start with strong user empathy. They lose it slowly.

Not because they don’t care—but because systems push them away from users:

• Abstracted requirements
• Ticket-driven work
• Proxy communication through tools
• Optimization around delivery, not outcomes

Over time, users become:

• “Consumers of an API”
• “A persona”
• “An edge case”

Instead of people trying to get something done.

🛠️ How Engineers Maintain User Empathy

Great engineers actively fight empathy decay. They:

• Dogfood the product
• Read support tickets and incident reports
• Ask why a requirement exists
• Question success metrics
• Push back when problems are framed as solutions

Empathy isn’t softness. It’s precision.

Understanding user pain leads to better architecture, clearer abstractions, and fewer wasted cycles.

🧭 The Product Manager’s Real Job

The Product Manager is not the feature decider.

Their real responsibility is:

• Collecting raw user pain from many sources
• Synthesizing it into coherent problem statements
• Prioritizing based on impact and reach
• Protecting the why as work moves downstream

They are the steward of user context.

When this role is weak, teams compensate by guessing. When it’s strong, teams move with confidence.

⚔️ Why Product and Engineering Should Tension Each Other

A healthy team has friction between Product and Engineering.

Not conflict. Tension.

Product asks:

• “Is this the most important problem?”
• “Who does this help?”
• “How will we know it worked?”

Engineering asks:

• “Is this the right solution?”
• “What are we trading off?”
• “Is the complexity justified?”

When these questions collide, clarity emerges.

When one side dominates, blind spots grow.

Both sides need to pull to keep the line taut to support and balance the product.

🧑‍🏫 The Engineering Manager’s Role in the Middle

Engineering Managers sit at a critical junction:

• Protecting engineers from thrash
• Ensuring technical sustainability
• Translating product intent into executable work

They help teams avoid building the wrong thing efficiently.

Their influence isn’t about choosing features—it’s about ensuring the team understands the problem deeply enough to make good decisions independently.

🚨 When User Pain Becomes Features

One of the clearest warning signs on a team:

Pain points are described as features.

“Users want a dashboard.”
“Users need a button.”
“Users asked for automation.”

Those aren’t pain points. They’re guesses at solutions.

Teams that slow down to articulate the actual problem almost always build something simpler—and more effective.

🤝 Shared Responsibility, Clear Ownership

User pain should be collected by everyone:

• Engineers
• Designers
• Support
• Sales

But it must be synthesized and prioritized by someone.

Without ownership, pain becomes anecdotes.
Without empathy, it becomes noise.

The best teams treat user understanding as a first-class engineering input—not an afterthought.

🔁 Closing Thought

Great software doesn’t come from moving fast alone.

It comes from moving intentionally—with a clear understanding of who you’re building for, what hurts, and why it matters.

The highest compliment a product can earn isn’t architectural elegance or technical novelty.

It’s watching someone use what you built and feel something—relief, confidence, momentum, even frustration that makes sense.

That’s why I still chase the same feeling I had watching players mash their way through a tiny mobile game—laughing, swearing, fully absorbed. 🎮🔥

When teams stay close to users, that feedback loop stays alive.

When they don’t, all that’s left is motion masquerading as progress.