PO or not PO?!

Three patterns around the most important role in Agile software development (15 minute read)

In many organisations, the Product Owner role exists everywhere except where it matters most: in the daily, difficult, clarifying work of turning uncertainty into useful software.

On paper, the setup often looks fine. There is a Product Owner. There is a development team. There are architects, requirement engineers, QA engineers, project managers, stakeholders, roadmaps, and delivery plans. Tickets move. Ceremonies happen. Status is reported. Yet delivery remains slow, brittle, politically charged, and strangely disconnected from real value.

As an Agile Coach, I rarely find that the main problem is a lack of process. More often, the real issue is a set of structural patterns that quietly hollow out product ownership while leaving its title intact.

Three of those patterns show up repeatedly. First, the Product Owner sits in a different organisation than the development team. Second, one development team is expected to serve several Product Owners at once. Third, Product Owners say, explicitly or implicitly, that they are not particularly interested in how the team works as long as they get the output.

None of these patterns is unusual. They are not typically caused by bad intent. They emerge from budgeting models, org charts, reporting lines, legacy structures, or overload. But understandable does not mean harmless. Each pattern weakens collaboration, slows decisions, blurs accountability, and makes good software harder to build.

This article is written for developers, Product Owners, project managers, requirement engineers, architects, and QA engineers alike. If you have ever sat in a refinement session wondering who can decide, why priorities keep colliding, or why everyone seems busy while clarity remains scarce, you have likely seen one or more of these patterns already.

Pattern One: The Organisational Expat - When the PO Lives in a Different World

What It Looks Like

The development team is housed in one organisational unit, perhaps an IT department, a shared services function, a platform team, or an outsourced delivery partner. The Product Owner sits in another unit entirely, a business division, a product management function, or a separate legal entity in a different country. They are connected to the team by a ticket system, a weekly meeting, and a shared document space. Everything else is distance.

This arrangement tends to emerge from the way large organisations are structured: business on one side, IT on the other, with a long tradition of defining the relationship as “the business tells IT what to build, IT builds it.” Agile was supposed to dissolve this wall. Instead, many organisations have simply relabelled the people standing on either side of it.

Why It Happens

Many companies adopted Agile as a delivery methodology for their IT department without genuinely rethinking the governance model above it. The business unit retains ownership of strategy, budget, and requirements. IT retains ownership of execution. The Product Owner role, theoretically bridging the two, ends up anchored on the business side by reporting lines and on the IT side by a calendar entry.

In other cases, separation is a consequence of scale. A large enterprise running dozens of development teams rarely has enough business-side people with the time, authority, and context to be fully embedded with each one. The PO becomes a part-time, remote participant, present enough to satisfy the ceremony schedule, absent enough to leave the team persistently underinformed.

Outsourcing and nearshoring arrangements compound this further. When the development team is geographically and contractually separate from the organisation it serves, the PO becomes less a collaborator and more a client, a shift that cuts against the collaborative intent of agile product development at its root.

The Damage It Causes

For developers, the most immediate effect is ambiguity in the middle of implementation. A seemingly small question emerges. The answer matters. Nobody present can decide. Work stalls, gets guessed at, or generates follow-up loops that should not have been necessary.

For requirement engineers and business analysts, the consequence is often that they become the human middleware of the system, translating, rephrasing, chasing context, and reconciling interpretations between the business and the team. That work is sometimes genuinely valuable. More often it is a symptom of a setup in which direct product collaboration has been replaced by relay communication, with all the latency and interpretation risk that entails.

For architects, the damage is subtler but serious. Good architecture depends not just on current requirements but on the likely direction of the product. If strategic intent remains distant and hard to access, architecture becomes reactive rather than deliberate, answering stated requests rather than shaping for evolving business needs. The architect ends up designing for requirements as written rather than for the intent behind them, a difference that compounds steadily over time.

For QA engineers, the pain lands in acceptance and test design. When value intent is weakly expressed and decisions arrive late, testing gets pulled toward narrow functional verification rather than meaningful validation of whether the increment solves the right problem.

For project managers, this setup can create a false sense of order. Reporting lines are clear. Responsibilities look neat on paper. Execution still feels noisier and slower than expected, because the system has preserved local clarity at the cost of shared ownership.

The cumulative effect is significant. Decision latency rises. Rework rises. Trust erodes. The team stops behaving like a product team and starts behaving like a delivery service.

Ways Forward

The most direct intervention is also the most uncomfortable: an honest conversation about what genuine product ownership requires in terms of time, proximity, and authority. Agile Coaches need to bring that conversation to sponsors and organisational leaders, not only to teams.

Where full co-location is impractical, the team and PO need to invest deliberately in practices that substitute for physical proximity. That means explicit asynchronous communication norms, clearly documented decision-making authorities, and feedback loops that are protected even under delivery pressure. A PO who cannot attend a refinement session must have a deputy with genuine delegated authority, not a note-taker, but someone who can actually make decisions in the moment.

For outsourced or nearshore contexts, the contractual model itself is often part of the problem. Fixed-scope contracts actively incentivise distance. Time-and-materials or outcome-based contracts, combined with embedded collaboration norms, can begin to shift the dynamic.

Product managers and requirement engineers in these situations have a real opportunity to act as connectors, but only if they resist the pull toward becoming gatekeepers. The goal is more direct communication between PO and team, not a more elaborate intermediary layer. There is a meaningful difference between supporting clarity and substituting for missing product ownership, and it is worth being honest about which one is actually happening.

There is also a more uncomfortable but useful option: name the role honestly. If the person filling the PO role cannot act as an embedded, empowered product decision-maker and mainly represents incoming demand from another structure, then a different role label may be more accurate. That clarity alone can prevent a great deal of confusion.

Pattern Two: The PO Hydra - Many Heads, No Direction

What It Looks Like

A development team sits in a refinement session. On the other side of the call are four product owners, or people who call themselves product owners, each representing a different domain, business unit, or product area. Each has priorities. Each believes their priorities are the most important. None has a clear view of what the others are asking for. The team watches the conversation unfold and begins to realise, not for the first time, that they will leave this session with more open questions than they arrived with.

This pattern is particularly common in organisations running platform teams, shared service teams, internal tooling teams, or any team whose outputs serve multiple stakeholders simultaneously.

Why It Happens

The multi-PO pattern emerges from an understandable impulse: when multiple parts of a business depend on a single development team, each part wants representation in the prioritisation process. The politically safe answer is to give everyone a seat at the table. The practically destructive consequence is giving everyone equal authority at that table without a mechanism for resolving conflict.

This arrangement also frequently reflects a failure to think clearly about what a team is actually for. When teams are staffed around technical capabilities rather than product outcomes - “the platform team,” “the integration team,” “the data team” - it is almost inevitable that multiple stakeholders will compete for their attention. The team’s backlog becomes a negotiation surface rather than a strategic instrument.

Sometimes the multi-PO situation is a legacy of mergers, reorganisations, or rapid growth. Product areas that were once separate have been combined into a single delivery stream, but the ownership structure has not been rationalised to match. The team ends up with multiple principals and no single point of accountability.

The Damage It Causes

A development team with multiple POs cannot optimise for a coherent product outcome. The backlog becomes a patchwork of competing priorities, each item representing a different stakeholder’s definition of value. The team spends a disproportionate amount of time in refinement and planning, not because the work is complex, but because the prioritisation is contested.

For developers, this often means constant context switching without product continuity. The investment required to understand a domain, the business context, the user’s needs, the intent behind the work, is constantly disrupted by the pivot to the next competing priority. The team may still complete tickets, but its work stops adding up to a clear product direction. High output in multiple disconnected directions is not product progress.

For architects, the effect is fragmentation. Multiple demand streams carry different assumptions, patterns, and time horizons. Without coherent product direction, architecture becomes a negotiated compromise between local pressures rather than a technical strategy in service of a clear product goal.

For QA engineers, the burden often appears as shifting acceptance logic and recurring clarification loops. “Done” starts to mean different things depending on which Product Owner, stakeholder, or domain the item belongs to. That increases coordination overhead and weakens shared quality standards.

For project managers and requirement engineers, this pattern tends to generate the temptation that more coordination is the answer, more alignment sessions, more intake rules, more stakeholder mapping. Some of that may help at the edges. But no amount of coordination fully solves the basic problem of several competing priority owners pointing at the same team. If project managers and senior stakeholders allow the team to remain the arbitration layer between competing business interests, they are not preserving agility. They are outsourcing a governance failure to the people writing the code.

For POs themselves, this setup is also genuinely wearing. Being one voice among many, without a clear mandate to resolve conflicts, produces political fatigue. Even well-intentioned people get drawn into defending local interests when there is no mechanism for a single ordered backlog.

Ways Forward

The first and most important question is simple: is this truly one team serving one product, or is it a shared capacity pool serving multiple products, domains, or value streams? If it is the latter, the organisation should stop treating the situation as though coherent product ownership already exists. Naming the reality is a necessary first step.

From there, one of two things usually needs to happen. The structurally cleaner answer is to realign teams around value streams, domains, or products so that each team has a clearer mission and one accountable product voice. That is not always easy, but it is often more feasible than organisations assume, and it eliminates the root cause rather than managing its symptoms.

If structural realignment is not yet possible, the team needs one clear prioritisation mechanism above the individual Pos, a product council, portfolio forum, or chief product function. The name matters less than the discipline. Conflicting priorities must be resolved before work reaches the team, not inside it. A council that exports its unresolved conflicts into the team’s refinement session has not solved the problem; it has merely relocated it.

Where shared-capacity arrangements are genuinely unavoidable, explicit prioritisation frameworks help. OKR-based sequencing, weighted scoring models, or portfolio-style investment thinking applied to the backlog can move a political negotiation toward a more transparent, value-based decision process. Developers and architects who understand these frameworks can also participate more meaningfully in prioritisation conversations, rather than waiting passively for stakeholders to reach consensus.

Pattern Three: The Absentee Landlord - “Just Build It, I Don’t Need to Know How”

What It Looks Like

A Product Owner sits in a refinement session, politely but firmly deflecting any question that touches on delivery reality. “That’s really not my concern, I just need it to work.” When a developer raises technical debt in the context of an upcoming feature, the PO redirects to the business requirement. When an architect asks about medium-term capacity needs that will affect an infrastructure decision, the PO explains that infrastructure is an IT concern. When QA raises testability in relation to a proposed implementation approach, the PO signals that testing is the team’s responsibility, not theirs.

This PO is not lazy or malicious. They are often quite capable in their own domain. But they have drawn a sharp professional boundary between “product” and “development”, and they expect it to be respected.

Why It Happens

Many Product Owners come from business analysis, product marketing, or project management roles where “the business” and “IT” occupied different professional worlds by convention. The expectation that a PO should be genuinely curious about delivery conditions, quality economics, and flow constraints simply does not match the professional identity they have built or the working model they have always known.

In some cases, the disengagement is a learned response. POs who have previously been blamed for delivery failures, or who have seen their engagement with technical conversations used against them, develop protective detachment. If they do not engage with the how, they cannot be held responsible for it.

Organisational culture plays a role too. In companies with a strong “stay in your lane” norm, Product Owners who do try to engage with delivery concerns are sometimes pushed back by development teams, who read it as micromanagement. The PO learns to stay back. The team learns to work in isolation.

A misreading of Agile principles can reinforce this. The principle that teams are self-organising, and that POs should not direct technical work, can be interpreted, wrongly but understandably, as a mandate to disengage from anything touching implementation. “I trust the team” becomes a phrase that sounds empowering but functions as a withdrawal from shared accountability.

The Damage It Causes

This pattern is particularly hard to detect early because delivery continues. The team ships. Velocity is maintained. Sprint Reviews happen. And yet a critical feedback loop has been severed.

Consider a typical situation. The team raises a concern that a feature can be delivered quickly in a fragile way, or more sustainably with a modest amount of foundational work first. A disengaged Product Owner hears only delay. A collaborative one hears a trade-off between short-term scope and medium-term capability. That difference, in how the same conversation lands, has compounding consequences for the product’s viability over time.

A PO who is consistently disengaged from delivery reality loses sight of the real economics of what they are building. They underread technical risk. They undervalue quality work, enablers, and maintainability. They treat delivery as a black box that converts backlog items into output, without any stake in the conditions that make reliable delivery possible.

For developers, this produces a recognisable experience: the sense of building on a foundation that is quietly degrading. Technical debt goes unacknowledged. Refactoring is deprioritised because it carries no visible user value. Infrastructure improvements are deferred as overhead. The team works harder to produce features on a weakening base, and the gap between what they can sustainably deliver and what the PO expects widens steadily.

For architects, the result is often a shadow decision structure. Technical decisions still get made, they have to be, but without sufficient product engagement around their consequences. Architecture becomes something that “IT decided,” until its cost or limitations suddenly become everyone’s problem.

For QA engineers, the pattern shows up as quality being treated as downstream verification rather than part of product design. Test strategy, non-functional quality, and acceptance depth are squeezed because the Product Owner sees only feature output, not the systemic conditions that make reliable value delivery possible.

For requirement engineers and project managers, this pattern creates a vacuum they often instinctively try to fill, carrying questions, translating concerns, patching the interface between product intent and delivery reality. That is sometimes necessary. But it also allows the underlying disengagement to continue unchallenged, and over time it becomes a structural substitute for something that should be a direct relationship.

The deeper damage is to shared accountability. When the PO’s relationship to the product is defined entirely by output, success gets framed as “did the team deliver what was asked?” rather than “did we create the right value in a sustainable way?” That framing rewards ticket completion over product learning, and it gradually detaches the entire team from the outcomes they are nominally working toward.

Ways Forward

The first step is often simply clarifying what engaged product ownership looks like in practice. Many POs in this pattern have never been shown what it means to stay genuinely close to delivery reality without directing technical work. They are not withholding engagement, they do not understand it is expected, or what form it should take.

The most productive reframe here is from technical detail to product consequence. A PO does not need to understand how the code works. They do need to understand why a degrading test suite increases the cost of every future feature, why an underfunded infrastructure decision will constrain the product’s ability to scale, and why a testability problem today is a release risk tomorrow. That connection, from delivery conditions to product outcomes, is where PO engagement becomes both meaningful and tractable.

Development teams carry responsibility here too. Developers, architects, and QA engineers should actively invest in making delivery concerns legible in terms their POs care about. “Technical debt” and “refactoring” mean little to most business stakeholders. “Increasing fragility that will slow our response to market change” means considerably more. Translating delivery reality into product impact is not simplification. It is professional communication.

A well-constructed Definition of Done is a structural tool with real force in this context. A rigorous, jointly agreed DoD that includes quality, testability, performance, and documentation standards makes the team’s working conditions visible and explicit. A PO who signs off against a DoD cannot credibly claim ignorance of the standards their team is held to.

For project managers and line managers, the message is equally direct: do not reward only visible scope delivery. If the surrounding system values feature throughput while ignoring maintainability, quality, and product learning, then disengaged product behaviour becomes rational. The incentives shape the pattern as much as the individuals within it.

What These Three Patterns Have in Common

Although these patterns look different, they are all forms of the same underlying problem: separation.

The first separates the Product Owner organisationally from the team. The second separates prioritisation across several competing ownership lines. The third separates product responsibility from delivery reality.

In each case, shared ownership of value creation weakens. The team starts receiving demands instead of pursuing coherent outcomes. The PO role becomes diluted, fragmented, or detached from the conditions under which software is built.

When that happens, the surrounding roles compensate. Requirement engineers translate. Architects stabilise. QA engineers absorb ambiguity. Project managers coordinate around structural confusion. Developers guess, wait, or adapt. Everyone works, but too much of that work is spent bridging gaps that the operating model itself created. These setups generate motion more reliably than they generate learning or value.

The way forward begins with honesty. Many organisations use Agile language to describe systems that still operate through separated demand, pooled capacity, and weak product integration. That may not always be immediately avoidable, but it should at least be visible and named.

From there, the direction is consistent across all three patterns: move deliberately toward one team, one clear product direction, and one visible prioritisation logic. Not because frameworks require it, but because software development under uncertainty depends on fast feedback, direct clarification, and shared trade-offs. Developers need business context, not only tickets. Product Owners need access to delivery reality, not only status updates. Architects need technical direction tied to product intent. QA engineers need to be part of early understanding, not just late verification. Requirement engineers and project managers should support clarity, not become permanent substitutes for missing product ownership.

These are not problems that can be coached away at the team level if the operating model keeps generating distance, conflict, and ambiguity. Local improvements are always possible, and always worth making. But they remain fragile until the structural conditions that produce the patterns are addressed.

Closing Thoughts: The Role Is Not the Problem. The Gap Is.

None of these three patterns represents a failure of individual people. They represent the gap between what the Product Owner role is designed to do and the organisational conditions most companies create for it. Closing that gap requires honesty from everyone involved, Agile Coaches, development teams, POs, product managers, architects, and the leaders who set the conditions within which all of them work.

For developers: the quality of your Product Owner relationship is a legitimate engineering concern. A PO who is distant, divided, or disengaged is not a soft problem to be worked around, it is a direct constraint on your ability to build good software. You have both the right and the responsibility to name it.

For POs: staying close to delivery reality, understanding what slows the team down, where quality economics are deteriorating, what the team is learning while building, is not scope creep or micromanagement. It is the informational foundation on which responsible product decisions depend.

For product managers, requirement engineers, and architects: your position in the system gives you an early view of where these patterns are forming. The temptation to fill the gaps left by dysfunctional PO relationships, to become the de-facto decision maker, the interpreter, the buffer, is understandable, but it perpetuates the dysfunction rather than addressing it. Your leverage is better applied to improving the system than to compensating for its failures.

The Scrum Guide defines the Product Owner as accountable for maximising product value, not as an approval authority, a stakeholder representative, or a demand collector. That accountability requires presence, engagement, and a genuine stake in how the product is built, not just in what gets shipped.

The question is not whether you have a Product Owner on the org chart. The question is whether you have one in the room.