Don't Split Product Strategy from Execution

Mention the Product Owner role to someone from a startup or scale-up background, and you'll likely get a blank stare. They'll probably google it later to figure out what you meant.

On the contrary, people who've spent their entire career in large enterprises treat it as second nature. “You can't have a product team without a Product Owner!”, I heard several times. They might have more doubts about the Product Manager role, though, assuming they've ever worked with one.

So, is this just another article debating the differences between the two roles and whether you need one or both? Not quite. For me, the Product Manager vs Product Owner debate is asking the wrong question.

Yes, there's plenty of literature on the definition for each role and the right terminology to use. But here's the thing: in any organization that draws a hard line between these roles and wastes time debating where to draw it, the distinction itself is a symptom of organizational dysfunction, not a solution.

The real question isn't "what's the difference between these roles?" It's "why do so many enterprises struggle to build truly product-driven organizations?"

How we got here

Let's start with the facts. Product Owner is a role defined by Scrum, a specific methodology with a specific scope. In the Scrum framework, the Product Owner manages the backlog, prioritizes work, plans sprints, and communicates delivery status to stakeholders. Within its intended scope (execution within a squad) this is a perfectly valid role.

The Product Owner role proliferated alongside the adoption of scaled agile frameworks like SAFe, particularly in large enterprises trying to bring structure to dozens or hundreds of product teams. It became a way to ensure every squad had someone accountable for "what gets built next."

The role serves a purpose for companies that embrace Scrum, but it has significant limitations. With such a strong emphasis on operational excellence and delivery, Product Owners tend to focus on outputs rather than outcomes. They become skilled at managing sprints, refining user stories, and keeping stakeholders informed, but they rarely step back to ask whether the work delivers real value to customers or moves key business metrics. That strategic component is often neglected or taken for granted.

When things go south: the anti-patterns

Many enterprises tried to address the Product Owner role's limitations by introducing a top-down approach to "inject" that strategic component into teams. Since this is a gray area in Scrum methodologies, I've seen at least two major anti-patterns, each dysfunctional in its own way.

Anti-pattern #1: The Role Proliferation

Some enterprises create a two-tier system: Product Managers who set strategy, and Product Owners who execute it. On paper, this sounds like a clean division of labor. In practice, it's often a disaster.

The strategist loses touch with reality. When you're not involved in day-to-day prioritization and delivery, you lose the essential feedback loop that tells you whether your strategy actually works. You miss the technical constraints, the user journey friction, the implementation edge cases that should inform strategic decisions. For more complex products, you might even lose touch with the product itself. You are too distant from its users to develop empathy with them.

The executor loses agency. When you're handed a strategy from above and told to "just execute it," you become an order-taker. You can't make intelligent trade-offs because you don't fully understand the commercial reasoning behind the work. You're managing a backlog, not owning outcomes.

Anti-pattern #2: The Project Management Masquerade

Other companies go a different route: they only have Product Owners, and these Product Owners report to technical leadership, such as engineering directors, rather than product leaders.

This usually happens in IT teams within organizations undergoing a "transformation" program of some kind. Usually, in this kind of teams, there is no product discovery practice, and work originates from strategic initiatives handed down from above. In reality, these are glorified project management organizations where the Product Owner's job is simply to keep projects on track.

The Product Owner is never in charge of setting direction. They don't measure value, they measure compliance to a plan laid out by managers or, in the worst cases, by "the business."

And here's the telltale sign of this dysfunction: when someone in your IT organization refers to another part of the company as "the business," you have a problem. Because the Product Owner is supposed to be the business. They should understand the business's interests, contribute to them, and be evaluated on business outcomes, not (just) on timely delivery.

In this model, the Product Owner becomes a translator between stakeholders and engineers, a schedule tracker, a meeting organizer. They're valuable, but they're not product managers. And the organization doesn't have anyone truly owning the "why."

The model that actually works

Both anti-patterns stem from the same flawed assumption: splitting product strategy from execution and delegating strategy to a Product Manager, the management team, or another part of the organization.

Strategy and execution are not separate jobs. They are two sides of the same coin. The person making strategic bets needs to be close enough to implementation to course-correct. The person prioritizing daily work needs enough strategic context to make smart trade-offs without having to escalate every decision.

The split is artificial and creates more problems than it solves. It's far more natural for every product team to have one person who owns the "why" while staying accountable for what gets built. That role is usually called Product Manager, but the name doesn't matter—what matters is clarity about their skill set and responsibilities. Here's what they should bring to the table:

Strong commercial instinct. They're obsessed with customers and users, but also with business outcomes. They constantly ask: Is this work helping us capture new customers? Retain existing ones? Cut our operational costs?

Ownership of the "why." They own the problem space. What problem are we solving next? Why is this the most important thing? How will this impact the customer journey? And how will that translate to business outcomes? They can engineer a 'Yes' when a critical opportunity surfaces mid-sprint, finding creative ways to pivot without creating chaos.

Direct connection to execution. They work closely with engineers, understand technical constraints, and get their hands dirty by looking at data and analytics themselves. Not to micromanage, but because you can't make good strategic decisions without this ground truth.

All of the above is non-negotiable. Whether you're building data products, AI products, or consumer applications, this function must exist.

But it’s just as important to set boundaries and define what this person should not be burdened with:

• Writing detailed user stories (let tech leads translate PRDs into engineering work instead).

• Managing team logistics and sprint ceremonies.

• Tracking vanity metrics like velocity and story points.

• Managing people, hiring, writing performance reviews, etc.

These responsibilities dilute focus from what matters: understanding customer problems and driving business impact.

Outcomes, not backlogs

Stop debating whether to call people Product Managers or Product Owners. Start asking whether they own outcomes or just backlogs.

If someone on your team is responsible for a product but spends most of their time managing sprint logistics and tracking velocity, you have a process coordinator. Regardless of title.

If someone is setting product strategy but hasn't talked to a customer or used their own product in weeks, you have a strategist in an ivory tower. Regardless of title.

If someone takes orders from "the business" and measures success by on-time delivery and budget rather than impact, you have a project manager. Regardless of title.

What every product team needs is someone who owns the complete loop: from problem identification to solution delivery to impact measurement. Someone who thinks commercially, understands user journeys, and has the courage to say yes to the right opportunities even when it disrupts the plan.

Call them Product Manager. Call them Product Owner. Call them Chief Problem Solver.

Just don't split the job in half and expect either piece to succeed.