Who’s Steering This Thing? The Eternal Tug-of-War Between Product and Engineering

“The most common product management mistake is not deciding what not to build.”— Gibson Biddle

Do We Really Need Product Managers? A Deep Dive Into One of Tech’s Most Controversial Roles

In the early days of Silicon Valley, the role of the product manager didn’t formally exist. Engineers built things. Sales sold them. If something didn’t work, marketing put a shine on it and moved the inventory anyway. The job of connecting business needs to technical execution was often undefined—sometimes falling to a charismatic founder, sometimes a meddling executive, and often, no one at all.

Over time, as software ate the world and products became more complex, a new discipline began to emerge—one that could speak the language of both business and engineering, guide a vision through ambiguity, and say “no” more often than “yes.” Thus, the modern product manager (PM) was born. But ask any founder, engineer, or executive today what a product manager does, and you’re likely to get a dozen conflicting answers—and maybe a few groans.

So… do we really need product managers?

The (Still Evolving) Definition of a Product Manager

Ben Horowitz once famously said that the product manager is the “CEO of the product.” While provocative, the phrase has aged poorly. Unlike CEOs, PMs typically don’t have direct authority over engineering, design, marketing, or sales. Instead, they operate through influence—leading cross-functional teams without formal power. It’s a role that blends strategy, customer empathy, data fluency, and ruthless prioritization.

Martin Eriksson offered a more grounded Venn diagram: the PM sits at the intersection of business, technology, and user experience. But even that is misleadingly tidy. In reality, product management encompasses a spectrum of sub-disciplines that vary dramatically based on company stage, product type, and team structure.

The Disciplines Within Product Management

Product management isn’t one job—it’s a constellation of related roles, each emphasizing different muscles:

• Technical PMs focus on APIs, architecture, and internal tooling.
• Growth PMs specialize in acquisition, activation, and retention.
• Platform PMs own infrastructure or capabilities used across teams.
• Strategic or Portfolio PMs oversee multi-product strategies and resource allocation.
• Customer-Facing PMs are embedded with GTM teams and focus on needs expressed in the field.
• Data-Driven PMs prioritize based on financial impact and usage patterns.

Understanding these flavors is key to hiring the right PM—because the wrong hire isn’t just ineffective, it can erode trust across the org.

Why “Engineering Should Own the Product” Is So Divisive

The debate over who should “own” product direction reflects deeper tensions.

Engineering-led organizations often say, “We’re closest to the tech—we know what’s possible.” Founders may insist, “It’s my vision.” Sales pushes for “what the customer asked for.” And when there’s no PM, the roadmap becomes a turf war.

But there’s a model that works surprisingly well in many high-performing organizations: the Chief Technology and Product Officer (CTPO).

What a CTPO Does—And When It Works

The CTPO model unifies product and engineering under a single leader—someone with both the technical depth to guide development and the product sensibility to craft a compelling roadmap. This approach provides tighter alignment between delivery and strategy, especially in companies where execution velocity is a competitive advantage.

What Good Looks Like:

• Spotify operated with this structure for a long time, with product and engineering led jointly under a single org during early scaling.
• Shopify and Stripe have had engineering-centric product leadership in their formative years, driving coherence across infrastructure and product experience.
• Early-stage startups often succeed with a CTPO when the founding team includes a product-minded CTO or when product DNA is strong in engineering.

The CTPO:

• Owns both product strategy and engineering execution.
• Ensures technical feasibility is part of early product decisions.
• Drives investment planning and roadmap alignment.
• Is responsible for delivering measurable outcomes—user adoption, retention, and revenue.

When a CTPO Model Fails

While elegant in theory, the CTPO model can fall apart in practice when:

• The leader lacks true product instinct or user empathy.
• Engineering dominates product discussions, leading to internal rather than customer-facing priorities.
• There’s too much surface area for one executive to effectively manage both functions at scale.

In these cases, a functional split between a CPO and a CTO, with mutual trust and a shared vision, tends to work better.

Hiring Product Managers at Different Stages

Hiring your first PM is a milestone—and a risk. The mistake most founders make is hiring for process and polish when they really need discovery and hustle.

Match the PM’s skillset to your company’s current needs—not just their résumé or company pedigree.

What Good (and Bad) Product Management Looks Like

Good PMs create leverage. They say no more than yes. They advocate for the user while staying grounded in business goals. They bring clarity, reduce waste, and make the lives of engineering and design easier.

Bad PMs are busy but not effective. They create tickets, not outcomes. They shift priorities reactively, have weak decision frameworks, and erode engineering trust by chasing shiny objects.

Wrapping up…

If your roadmap is a reaction to sales calls, if engineers are doing UX interviews between sprint planning, or if no one can articulate why you’re building what you’re building—then yes, you need a PM.

But don’t just add headcount. Be intentional.

Whether you empower a strong CTPO to own both disciplines or hire individual PMs to fill critical gaps, product management should always serve one purpose: to connect customer needs to business strategy through the lens of thoughtful, value-driven execution.