The Best Product Managers: Why Empathy Wins

Product management has one of the widest front doors in tech. You can come from sales, engineering, marketing, consulting, founding a company, or, increasingly, from "I took a certification course and updated my LinkedIn".

Everyone has a seat at the PM table. And on the surface, that's a good thing. The role benefits from diverse perspectives.

But there's a pattern I keep seeing: the loudest voices in product (the framework evangelists, the roadmap politicians, the self-appointed "mini-CEOs") are often the worst at the one thing that actually matters.

Understanding the user.

And I don't mean in theory, or through a quarterly NPS score. I mean understanding them the way you understand someone whose problem you've spent months sitting inside of, absorbing every frustration, every workaround, every moment where the product failed them.

That kind of understanding doesn't come from a strategy deck. It comes from proximity. And the people with the most proximity are almost never the ones getting promoted into product roles.

"The people closest to real users tend to make the best PMs, and they're rarely the loudest on roadmap calls"

Two Roles Nobody Takes Seriously Enough

If I had to build a product team from scratch and could only hire PMs from two backgrounds, I'd pick tech support and UX design every single time, over ex-consultants, MBA grads, and engineers who "want to move closer to the business".

This comes from a decade of shipping Products across Fintech, Healthtech, eCommerce and SaaS. The PMs who consistently deliver the best outcomes share one trait: they've spent real time in the direct line of user fire.

Tech support staff are the most undervalued pipeline into product management. If you've worked support, you've spent your days translating technical errors into human language, spotting patterns in complaints before anyone else in the org, juggling bug reports alongside emotionally charged customers, and advocating for fixes that engineering keeps deprioritizing because the ticket count "isn't high enough".

Support teams are ground zero for user feedback. And I mean the raw version, the midnight chat where a user is threatening to cancel because a workflow broke for the third time this month. That kind of exposure builds empathy the hard way, by sitting in the pain until you can feel it in your own work, and no persona or journey map gets you there.

These skills transfer directly to product. Support reps already work across engineering, QA, design, and customer success. They already prioritize by user impact, and they already know what "broken" means to a real person, beyond what a Jira ticket says. They just need access to the strategy layer.

UX designers are the other pipeline nobody takes seriously enough. Great UX folks do a lot more than move pixels. They run Discovery sessions. They synthesize ambiguous feedback into actionable insights. They map user journeys. They advocate for accessibility. And critically, they work in the exact space PMs live in: the gap between "idea" and "implementation".

PMs coming from UX already have the user at the center of every decision. For them that's muscle memory, not a mindset shift. They know how to say no gracefully. They've made trade-offs under constraints. They understand design debt the way developers understand tech debt. And they've had to defend decisions to stakeholders who wanted something shinier but less useful.

At Biz of Dev, this is exactly how we think about Product Discovery. The Four Phases (Business Understanding, Market Understanding, User Understanding and Execution Plan) build user proximity into the structure, so it can't become an afterthought. The best people to lead that process are the ones who've already spent years absorbing user reality, not the ones who need a workshop to remember users exist.

"Support reps decode engineering for angry users. Designers explain UX logic to salespeople pushing features nobody asked for. Generalism is their day job"

The "Mini-CEO" Myth Is Killing Products

Somewhere along the way, the industry decided PMs should be "mini-CEOs". This framing is responsible for an enormous amount of bad product work.

A CEO sets vision, drives revenue, manages investors, and makes company-level strategic decisions. A PM defines what to build, why, and in what order, based on user needs, business constraints, and technical reality. These are related but fundamentally different jobs. Conflating them produces PMs who spend their time playing politics and crafting narratives instead of talking to users and shipping software.

The mini-CEO framing attracts a specific type of person into product: ambitious, articulate, framework-fluent, and often dangerously disconnected from the people who actually use the product. They know how to present a roadmap to a board. They don't know how to sit through a user research session without trying to lead the witness.

What actually matters in a PM comes down to three things, and CEO energy isn't one of them:

Can you understand the user? I mean the actual human with the actual problem, not the persona. Can you distinguish between what they're asking for and what they actually need? We wrote an entire piece on this distinction, identifying user requirements and problems, because getting it wrong is the single most common reason products fail to land.

Can you align teams? PMs don't have authority, so it has to happen through understanding. Can you explain to an engineer why this feature matters? Can you explain to a designer why this constraint exists? Can you explain to the Founder why their pet feature shouldn't ship this quarter?

Can you ship what matters? That means what actually moves the needle for the user and the business, which is rarely the easy thing or the thing that looks good in a demo. That requires prioritization discipline, something we break down in our Product Prioritization frameworks guide, because most teams get it wrong by defaulting to gut feel or internal politics.

Support reps and UX designers build these muscles every single day. The ex-consultant who just finished a PM bootcamp? They're starting from scratch on all three.

"What actually matters: can you understand the user, align teams, and ship what matters?"

Customer Fluency Is the Unfair Advantage

There's a concept I keep coming back to: customer fluency. I don't mean customer awareness, or empathy as a buzzword on a slide. I mean fluency: the ability to think in the user's language, anticipate their reactions, and feel the friction points in a product before anyone files a ticket.

Customer fluency is what separates PMs who build features from PMs who solve problems.

A PM with customer fluency doesn't need a survey to know that the onboarding flow is confusing. They've watched 50 users struggle with it. They don't need a data analyst to tell them that churn spikes after the first invoice. They've read the cancellation reasons.

This fluency is almost impossible to teach in a classroom or a bootcamp. It's accumulated through thousands of interactions with real users in real contexts. It's the difference between knowing that "users find the dashboard overwhelming" and understanding that the specific user who just signed up, a property manager with 12 units and no technical background, can't find the one report they need because it's buried under three layers of navigation designed for enterprise clients.

When we run Product Discovery at Biz of Dev, the first thing we look for is this kind of fluency. Does anyone on the team actually know how users experience the product? I mean how they actually do, which is rarely how they're supposed to. If the answer is no, Discovery has to build that understanding from zero. If someone on the team already has it (usually a support lead or a designer who's been running their own guerrilla user research), the entire engagement moves faster.

"Customer fluency is thinking in your users' language. You can't teach it in a workshop. You earn it through proximity"

The Objections Are Weak

Every time I make this argument, two objections come up. Both are easily handled.

"But support reps and designers don't know Agile, Jira, or roadmapping."

Neither did most PMs on day one. Tools can be learned in a week. Frameworks can be picked up in a month. What can't be taught quickly is taste: knowing what to build and why it matters. Support and UX teach that better than any certification program ever will.

I've watched ex-support PMs learn to run sprint planning in two weeks. I've never watched an ex-consultant learn genuine user empathy in two years.

"But they've never owned revenue or metrics."

Give them access to the data and a sandbox. Watch how fast they connect the dots between user pain and churn, between support ticket volume and feature adoption, between NPS scores and the three bugs they've been escalating for months.

They already track patterns. They already know which problems cause the most pain. They just haven't had the title or the access to surface those patterns at a strategic level. That's an organizational failure, not a capability gap.

What This Means for Founders Building Teams

If you're a Founder hiring your first PM, or looking for product leadership for your startup, stop filtering for pedigree. Stop looking for the ex-Google PM or the MBA with a product certificate. Start looking for the person who's spent the last three years sitting closest to your users.

That might be your head of support who knows every common complaint by heart. That might be the UX designer who's been running user interviews on their own time because nobody else was doing it. That might be someone who's never had "Product" in their title but has been doing the work for years, quietly, without the framework vocabulary.

The best product thinking doesn't come from a top-down strategy exercise. It comes from the bottom-up accumulation of user insight that only proximity can provide. And the people with that proximity are usually the most underpaid and underrecognized people in the org.

Give them the shot. The frameworks will follow. The empathy won't need to.

Does Anyone Actually Understand the User?

Every product we touch at Biz of Dev starts with a question: does anyone on this team actually understand the user? And I mean in the real, granular, "I know what breaks and why" sense, not through a market research report from six months ago.

When the answer is yes, when there's someone on the team with genuine customer fluency, Discovery moves much faster. Decisions are sharper. The roadmap makes sense on the first pass. And the features we build actually land, because real pain informed them.

When the answer is no, we build that understanding ourselves. Through the Four Phases, User Understanding becomes the foundation everything else rests on. We interview real users. We map real workflows. We sit in the pain until we can articulate it better than the user can.

All of it comes from a simple belief: the closer you are to the user, the better the product. The people who've lived that proximity (in support trenches, in design critiques, in midnight chats with frustrated customers) are the ones we want leading product decisions.

PMs aren't born. They're built. And the best ones are built on empathy, not ego.

"Tools and frameworks can be learned in weeks. Empathy for users takes years, so hire the people who already have it"

Empathy Is a Competitive Advantage, Not a Soft Skill

AI can now generate roadmaps, write PRDs and estimate sprint velocity. The one thing that stays stubbornly human is the ability to understand another human's experience. That is customer fluency. Support reps and UX designers bring it to the table, and most product orgs are structurally blind to it.

If you're building a product team, stop optimizing for credentials. Start optimizing for proximity. The person who's spent three years absorbing user pain will outperform the person who just read a book about it, every single time.

The best PMs aren't the ones who talk the loudest in roadmap meetings. They're the ones who listened the longest before they ever walked into the room.

With or without my help - I wish you the best.