Let’s review what the official Scrum Guide has to say about the role of Product Owner:

The Scrum Team

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity. The Scrum Team has proven itself to be increasingly effective for all the earlier stated uses, and any complex work.

Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available.

The Product Owner

The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Optimizing the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one can force the Development Team to work from a different set of requirements.

Agile for All Definition:

Our definition of Great Product Ownership describes:

1. What great POs spend their time doing
2. How they do it
3. Why they do it

Great Product Ownership is: Learning and expressing what to build, for whom, and whyin collaboration with a cross-functional team and customers and stakeholdersin order to maximize the flow of value through that team”

What the Product Owner is NOT

Alistair Cockburn, one of the founding organizers of the Agile movement, describes the Product Owner as a “single set of vocal chords” for priority of a Product Backlog. The Product Owner is a leadership role – a champion for maximizing the flow of value to customers and the business. This indicates that several common patterns are not aligned with the role definition, and when those patterns are present, the capability of an organization to maximize the flow of value through a team is hindered. The antipatterns generally stem from two root causes: 

1. High time demands on the Product Owner
2. Vestigial structures leftover from more traditional, Complicated approaches to delivery.

We won’t list every common antipattern here, but we will explore three to help illustrate how the common root causes can impact the capability of the organization to maximize the flow of value.

The Proxy Product Owner

In this antipattern, there is someone with the customer understanding and business authority to make prioritization decisions that stick (the PO), and there is a separate person that works directly with the team (the Proxy). In this pattern, the Proxy Product Owner is often played by a Business or Systems Analyst or an Engineering Lead

How the Proxy Product Owner antipattern impedes the flow of value through a team

This pattern assumes that one person, the PO, can Learn what to build, for whom and why, and another person (the Proxy) can Express what to build to the cross-functional team. It is based on a view of the work as Complicated, meaning that it is predictable and simply needs expert analysis and clear description so that the Development Team can execute. Notice that this antipattern dismisses the “how” of great Product Ownership. The learning and expression work is not done in collaboration with the team, but separate from them.

Experimentation and Innovation Suffers

As we covered in the Cynefin activity, the Proxy approach might work well for Complicated, predictable problems. For Complex work, the importance of Probing the system, running experiments with a goal to learn, is the appropriate approach. Good experiments are best run with cross-functional, well facilitated teams, since having multiple perspectives significantly aids creativity and innovation. 

In his book “The Innovators”, author Walter Isaacson traces the history of computing back to the Babbage Engine, and points out that EVERY innovative step was done collaboratively. There was not a single invention that was created by a sole inventor. The Babbage Engine, for example, was the result of a collaboration between Charles Babbage and Ada Lovelace, two people with very different backgrounds and perspectives.

Team Engagement Suffers

For Complex work, the engagement of the Development Team is also critical to creating new and innovative solutions. Teams that are handed work to execute are rarely creative and engaged. When they collaboratively participate in the Learning, Expressing, and Building, engagement goes way up because they understand the purpose of the work and the tradeoffs of every build decision. With the Proxy pattern, the team feels as if they are order takers, not as collaborative, creative problem solvers.

The Product Owner Team

In this pattern, a team of managers collectively play the Product Owner role. A few common examples:

1. Management Team as Product Owner, for example
   • Product Manager, Engineering Manager, and Test Lead
   • Project Manager, Architect, and Designer
2. Entrepreneurial pattern, for example
   • Founder, Designer, Prototype Builder
   • Product, Design, Sales, Engineering

How the Product Owner Team impedes the flow of value

This pattern often usually stems from siloed organizations that don’t roll up to a single decision maker until the VP or C-Level. In such organizations, different silos compete for their goals to make it into the Product Backlog. For example the Product person advocates for new features, the Engineering person advocates for technical infrastructure, and the Test person advocates for bug fixes. Without a shared definition of value and theory of economic impact, the flow of value is severely impeded. Prioritization becomes a game of balancing political willpower, rather than aligning on a shared goal.

This political jockeying often flows down to the team level as well. If an engineer wants to implement a new technical capability, they will run it by the Engineering Manager for feedback and approval, and so on. This mirrors a family antipattern: if mom says no, I’ll just ask dad instead.

When this Pattern Might Work

There are instances of this pattern being successful. In those examples, the Product Owner Team still has a single person that is considered accountable for priority, and the culture of the organization has a strong alignment on purpose and definition of value, paired with high trust and psychological safety.

Consider if those characteristics are in place in your organization, and if not, you are probably better off avoiding this pattern until such a culture can be created. Until then, empower a single set of vocal cords to be the final decision maker, then hold them accountable for delivering long term value to customers and the business.