Product Owner

A Scrum-specific role responsible for maintaining a prioritized backlog and representing requirements to a development team. In empowered product teams, the product manager fulfills this function without a separate role — splitting ownership across PM and PO is an anti-pattern that fragments accountability and hollows out product management.

What is a Product Owner?

The product owner (PO) is a role defined by the Scrum framework. In Scrum’s original design, the PO acts as the single point of contact between a development team and the wider organization — maintaining the product backlog, accepting completed work, and clarifying requirements during a sprint. The role exists to give engineering a clear, accessible source of prioritization authority within a time-boxed delivery cycle.

It is important to understand what the PO role is not. A product owner in the Scrum sense has no formal mandate to conduct customer discovery, own business outcomes, set product strategy, or make market-facing decisions. Those responsibilities belong to a product manager. The PO role, as defined by Scrum, is a backlog coordination function — not a strategic leadership function.

Cagan’s Critique: Watered-Down Product Management

Marty Cagan at SVPG is direct on this: most organizations using the PO title are practicing “watered-down product management.” The Scrum framework gives POs authority over the backlog but not over customers, strategy, or outcomes. The result is a product function that optimizes for sprint execution rather than for solving problems that customers actually need solved.

This matters because backlog prioritization disconnected from continuous customer discovery produces features that are technically delivered and strategically irrelevant. The team ships on time. The shipped work doesn’t move the business. And because neither the PM (who owns strategy) nor the PO (who owns the backlog) owns the outcome, accountability for why evaporates.

The PM/PO Split: An Anti-Pattern

Many organizations split the PM and PO roles across two separate people — a PM who handles discovery, strategy, and stakeholder communication; a PO who manages the backlog and accepts stories in the sprint. This division feels logical but produces three predictable failure modes:

Fragmented ownership. When strategy (PM) and execution validation (PO) belong to different people, accountability for outcomes falls in the gap. The PM wasn’t in the sprint; the PO wasn’t in the strategy session. Neither fully owns the result.

Discovery vacuum. POs who manage backlogs without a customer discovery mandate fill roadmaps from stakeholder requests and internal intuition. Discovery gets deprioritized because it isn’t the PO’s job, and the PM is operating “above” the sprint cadence.

Accountability dilution. When things go wrong — a shipped feature isn’t adopted, a bet misses the market — it is genuinely unclear who should have caught this. The PM didn’t validate during build; the PO didn’t validate before committing to the roadmap. Both can point elsewhere.

Empowered Teams Don’t Need the Split

In Cagan’s empowered product team model, the product manager is the product owner in every meaningful sense. They are the single person accountable for understanding customers, defining what to build and why, maintaining prioritization, and owning the outcome. There is no separate PO because there is no work the PO role does that the PM isn’t also responsible for.

The PM is present in discovery and delivery simultaneously — not alternating between them. Discovery questions get answered the same week engineering needs them. Scope adjustments happen in real time. The feedback loop between learning and building collapses to days, not the weeks or months created by a PM-to-PO handoff.

When Does the PO Title Appear?

The product owner title is common in organizations that adopted Scrum as an execution framework before building a mature product management function. In these contexts, POs often perform the full PM function informally — doing customer research, setting direction, owning outcomes — even if the title implies only backlog ownership. The title is an artifact of the framework adoption, not a meaningful indicator of a role boundary.

In IT and internal tooling contexts, where no dedicated PM is embedded and Scrum is the operating framework, the PO role can function as a workable adaptation. But it is a constraint — an accommodation to resource limitations — not a model to replicate when building a product-led organization.

Why It Matters for Product People

If your organization has POs and PMs in separate roles, the question to ask is: who owns the outcome? If the answer is unclear — if the PM says “strategy” and the PO says “backlog” and neither says “the customer problem we’re solving” — you have an accountability structure designed to guarantee the gap. The fix is not better coordination between PM and PO. It is consolidating ownership into one empowered role accountable for both discovery and delivery.

The product owner function is one component of the product manager role in an empowered team model. It connects to user stories (the granular units the PM accepts and clarifies with engineering), the product backlog (the prioritized queue the PM owns), and sprint planning (where the PM translates strategy into the team’s execution plan for the week).