Defining the Product Owner Is Not Enough. Define the Decisions.

Picture a feature sitting at 90 percent for eleven days. The code is written. The tests pass. Nobody can say who may accept the changed scope as fit for release.

The team asks the Product Owner. The Product Owner says the domain lead must accept the changed scope, because the original outcome was reframed after a stakeholder call. The domain lead assumed Product had already accepted it. The Delivery Manager schedules a clarification meeting for Thursday. On Thursday, the person who could actually resolve the conflict between two stakeholder groups is on leave. The item waits another week.

Ask anyone involved who owns this and you get a confident answer. Ask three people and you get three confident answers.

The usual response is a workshop to clarify the Product Owner role. The resulting document may establish a useful shared core: owns the backlog, maximizes value, represents the customer, is available to the team. It can still leave a local question unanswered: who resolves a conflict between two stakeholder groups after the original outcome has shifted?

The role description is only the starting point

Bass et al. (2018) studied Product Owners across ten organizations, combining interviews and observation with 55 practitioners in large multinationals and one SME. They identified twelve distinct Product Owner activities. Eight of those activities appeared across all studied teams, projects, and companies. The title covered a bundle of work, not one activity.

Kadenic et al. (2023) reached a compatible conclusion from a different angle. Their review, checked against a practitioner focus group, describes the role as tailored to organizational and team context. It also identifies the individual's ability to build networks and communicate across boundaries as relevant to performance. The study does not test whether the title itself changes authority or delivery.

So when your role document says "owns the backlog," it may describe only part of what the person actually does. It can remain silent on the authority needed to resolve Thursday's conflict.

Coordination does not want to be frozen

The obvious response is to write a more thorough document. Map every interaction, assign every handoff, build the RACI matrix properly this time.

Berntzen et al. (2019) looked at Product Owner coordination inside a large-scale development program, reading it through relational coordination theory. Two findings matter here. Coordination varied by each Product Owner's local setting, so no single pattern fit the whole program. And unscheduled coordination — the corridor conversation, the unplanned call, the message that skips the forum — supported high-quality communication rather than undermining it.

This is a qualitative case study, so treat it as a description of one program's mechanics rather than a rule that holds everywhere. It also suggests a hypothesis to check locally: formalizing every interaction may replace fast informal contact with scheduled approval steps. The selected studies do not establish that this happens routinely or that it slows delivery.

The distinction worth testing locally is whether coordination has room to adapt while consequential decisions remain explicit. A role document may describe activities and meetings without resolving every authority boundary.

Boundaries move, and that is supposed to happen

Spiegler et al. (2021) studied 75 practitioners across eleven Bosch divisions. Their grounded-theory study identified nine leadership roles transferred from Scrum Masters to teams as those teams matured. The transfer was not automatic. Leadership gaps and a supportive team climate appeared to enable it, while role conflicts could diminish it. The authors also describe trust and freedom as part of the transfer.

The study is about Scrum Masters, not Product Owners, so applying it to product decisions is an inference rather than a finding. It offers a useful possibility to test: some authority can migrate as capability grows. A definition written to be permanent may freeze an arrangement that suited an earlier stage of the team.

Put the evidence together and the clean org chart is incomplete. Bass et al. found a common activity core, while Kadenic et al. and Berntzen et al. documented contextual variation. Different products, governance regimes, and team maturities may need different allocations of authority. Whether a local gap or overlap contributes to waiting is a hypothesis to test in the work, not a result established by these studies.

What the evidence does not say

None of these studies measured what clearer decision boundaries do to cycle time, predictability, rework, or business value. They document what Product Owners do, how coordination operated in one large-scale program, and how authority moved as teams matured in the Scrum Master study. They contain no effect estimate for the practice below. Three of the four are qualitative or review work, which can inform hypotheses about mechanisms but does not support a claim that a change produces a result.

The studies can inform a local test, but they cannot predict its result.

Trace the decisions on one stuck item

A practical way to inspect Product Owner decision rights is to trace five consequential product-delivery decisions locally: priority changes, scope adjustments, acceptance, stakeholder-conflict resolution, and responses to post-release evidence. Their owners may be the Product Owner or other actors. This five-decision set is a proposed diagnostic, not Bass et al.'s taxonomy. The trace is unvalidated; the selected studies neither assign these decisions categorically to the Product Owner nor show that tracing them improves delivery outcomes.

Pick the item that waited longest last month. Not a representative sample. One item, reconstructed honestly.

Walk its actual path and answer five questions. Who could have changed its priority? Who could have changed its scope, or traded one outcome for another? Who could have accepted the result as fit for release? Who could have resolved the conflict between stakeholders pulling in different directions? Who read the post-release evidence and decided what happened next?

For each one, write down four things: the named person, the inputs they needed to decide, the deadline or trigger that should have forced the decision, and where it goes if they cannot resolve it.

Then mark three failure types. Gaps, where no name fits. Overlaps, where two people believed they held the same authority. And decisions that were formally assigned but could not be exercised, because the named person lacked the information, the availability, or the standing to make the call stick. A role description can record the assignment without showing whether it is usable.

Change exactly one boundary before the next item. Move the acceptance decision to someone with the context. Set a trigger on the scope decision so it cannot drift past a certain point. Name a fallback for the stakeholder conflict.

Then compare. Did the item wait as long at that step? Did an escalation happen that previously would have been a silent delay? You are watching waiting time and escalation behavior at one boundary, not running a controlled trial. Early comparisons may be ambiguous. Local noise is large, and one item is one item.

Keep the map short and expect to revise it. It describes who decides what this quarter, at this maturity level, for this product. When the team grows into a decision, hand it over deliberately and update the map. A decision map that never changes has stopped describing your organization and started constraining it.

The next time someone proposes a workshop to clarify the Product Owner role, keep the common definition and ask which decision on last month's slowest item still lacked a usable owner. The role document and the decision trace answer different questions.

References

Bass, J. M., Beecham, S., Razzak, M. A., Canna, C. N., & Noll, J. (2018, May 27). An empirical study of the product owner role in scrum. In Proceedings of the 40th International Conference on Software Engineering: Companion Proceedings (pp. 123–124). ACM. https://doi.org/10.1145/3183440.3195066

Berntzen, M., Moe, N. B., & Stray, V. (2019). The Product Owner in Large-Scale Agile: An Empirical Study Through the Lens of Relational Coordination Theory. Lecture Notes in Business Information Processing, 121–136. https://doi.org/10.1007/978-3-030-19034-7_8

Kadenic, M. D., de Jesus Pacheco, D. A., Koumaditis, K., Tjørnehøj, G., & Tambo, T. (2023). Investigating the role of Product Owner in Scrum teams: Differentiation between organisational and individual impacts and opportunities. Journal of Systems and Software, 206, 111841. https://doi.org/10.1016/j.jss.2023.111841

Spiegler, S. V., Heinecke, C., & Wagner, S. (2021, March 22). An empirical study on changing leadership in agile teams. Empirical Software Engineering, 26(3). https://doi.org/10.1007/s10664-021-09949-5