Another Day, Another Role
How “Business Product Owner” keeps the old business–tech divide alive
In many organizations, the title Business Product Owner does not emerge from Agile or product theory. It emerges from an operating model that never fundamentally changed.
Despite modern language, many companies still run on a structural split between business functions and technology. Business functions are treated as the source of value and priorities. Technology is treated as an execution capability. Product practices are layered on top, but the underlying division remains intact.
Business Product Owner is how that division persists under a new name.
In this model, the Business PO is positioned as the representative of “the business” and the owner of the value proposition. Technology teams are positioned as delivery. Product roles, if present, are often left mediating between the two. This preserves a familiar power structure while adopting the vocabulary of product-led work.
The issue is not semantics. It is decision design.
Decades of organizational research show that performance suffers when decision rights are split across roles that do not share accountability. The most critical product decisions, what to build, what not to build, how to sequence work, and how to respond to learning, sit at the intersection of customer impact, business outcomes, and technical constraints. When those dimensions are owned separately, tradeoffs do not disappear. They become slower, more political, and harder to resolve.
This is a well-documented pattern in enterprise operating models. MIT Sloan research on decision effectiveness consistently shows that speed and quality decline when responsibility and authority are misaligned. McKinsey’s work on agile transformations repeatedly highlights that teams stall not because of tooling or ceremonies, but because decision ownership remains centralized or fragmented across functions.
The Business Product Owner role is a structural response to that fragmentation.
You can see this clearly in how work flows. The backlog stops functioning as a learning and prioritization tool and becomes a negotiation surface. Business inputs arrive as requests. Delivery constraints are raised as blockers. Product decisions become reconciled compromises rather than deliberate bets. Teams implement requirements without full context. Feedback loops lengthen because learning must travel through intermediaries before it influences direction.
This is not accidental. It is the predictable outcome of a system where no single role is trusted to own value end to end.
From a leadership perspective, this setup feels safer. Value ownership remains close to business leadership. Technology remains accountable for execution. Risk is distributed. No one individual carries full responsibility for outcomes. In the short term, this reduces tension. In the long term, it erodes clarity.
Research on matrixed organizations shows this tradeoff clearly. While matrices are often introduced to increase collaboration, they frequently reduce accountability and slow decision-making when ownership is not explicitly resolved. The Business PO role functions as a local stabilizer in a matrix that was never designed for product ownership.
From a team perspective, the cost compounds over time. Teams optimize for acceptance criteria instead of outcomes. Discovery is treated as upstream work owned by someone else. Engineers and designers disengage from value discussions because those decisions are perceived as external. Learning slows because teams are shielded from the consequences of their choices.
Empirical studies on high-performing product teams consistently point to the opposite pattern. Teams that perform well over time operate with clear product ownership, short feedback loops, and decision authority close to where information is richest.
Business context is not delegated. It is shared directly. Tradeoffs are made in the open by accountable product leaders, not negotiated through role boundaries.
Organizations that successfully move to product operating models tend to do a few things differently:
They collapse business and technology ownership into a single product role with real authority.
They involve business leadership directly in discovery and outcome evaluation rather than delegating value definition to intermediaries.
They design governance around decision boundaries instead of approval checkpoints.
They treat the backlog as an evolving expression of intent, not as a contract.
When these conditions exist, there is no need for a Business Product Owner. The role solves a problem that no longer exists.
When these conditions do not exist, roles multiply.
Business Product Owner is not evidence of product maturity.
It is evidence of an unresolved operating model.
It exists to manage the discomfort created when organizations want the benefits of product-led work without changing how power, accountability, and decisions are structured.
The harder work is not refining the role description. It is answering the questions the role is compensating for:
Who is allowed to own value end to end?
Where do tradeoffs get decided?
What decisions can teams make without escalation?
Who is accountable when priorities conflict?
Until those questions are answered structurally, Business Product Owner will continue to exist not because it improves outcomes, but because it makes an unresolved system tolerable.