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 here's the pattern nobody talks about: the loudest voices in product - the framework evangelists, the roadmap politicians, the "mini-CEO" self-appointees - are often the worst at the one thing that actually matters.

Understanding the user.

Not understanding the user in theory. Not understanding the user through a quarterly NPS score. Understanding the user 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. Not the loudest on roadmap calls. Not the ones with the fanciest frameworks."

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. Over MBA grads. Over engineers who "want to move closer to the business."

This isn't a feel-good take about diversity of backgrounds. It's an observation from a decade of shipping products across industries - from fintech and healthtech to 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. Not the sanitized, survey-filtered version. The raw, uncut 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. Not from personas and journey maps, but from sitting in the pain until you can feel it in your own work.

These skills transfer directly to product. Support reps already work across engineering, QA, design, and customer success. They already prioritize based on user impact, not internal politics. They already know what "broken" means to a real person, not just 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 don't just 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. That's not a mindset shift for them - it's muscle memory. 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 our Discovery Sprint process. The four phases - Business Understanding, Market Understanding, User Understanding, Execution Plan - are designed to ensure that user proximity isn't an afterthought. It's baked into the structure. 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 isn't CEO energy. It's three things:

Can you understand the user? Not the persona. The actual human with the actual problem. 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? Not through authority, because PMs don't have any. 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? Not what's easy. Not what's interesting. Not what looks good in a demo. What actually moves the needle for the user and the business. That requires prioritization discipline - something we explore in depth 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.

"The myth of the 'natural product thinker' is overrated. What actually matters is: 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. Not customer awareness. Not customer empathy as a buzzword on a slide. 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? Not how they're supposed to experience it - how they actually do. 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 isn't knowing about users. It's thinking in their 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 - quietly, without the framework vocabulary - for years.

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.

The Biz of Dev Take

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

When the answer is yes - when there's someone on the team with genuine customer fluency - discovery moves twice as fast. Decisions are sharper. The roadmap makes sense on the first pass. And the features we build actually land, because they were informed by real pain, not imagined pain.

When the answer is no, we build that understanding ourselves. Through our four-phase discovery process, we go deep on user understanding - not as a checkbox, but as 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.

That's not a methodology we invented in a boardroom. It's a reflection of 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 can be learned. Frameworks can be picked up. Empathy for users? That takes years. Hire the people who already have it."

Empathy Is a Competitive Advantage, Not a Soft Skill

In a world where AI can generate roadmaps, write PRDs, and estimate sprint velocities, the one thing that remains stubbornly human is the ability to understand another human's experience. That's what customer fluency is. That's what support reps and UX designers bring to the product table. And that's what most product orgs are structurally blind to.

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.