Beyond Scrum: Is it Time to Remove the Product Owner Role?

Written by Jörgen Karlsson, May 31, 2024
#Agile #Agile Roles #Product Owner

The Product Owner is one of the most misunderstood roles in Scrum or other agile methodologies. Is the solution to remove the role entirely? That is one of the options I argue for in this thought-provoking article. So read on!

Thesis: The Need for Reevaluation or Removal of the Product Owner Role

Given the expanding number of setups that transcend the single-team, single-product paradigm, this article argues for a critical reevaluation of the Product Owner role. We will explore the implications of either renaming the role to emphasize broader responsibilities, such as 'Value Maximizer', or advocating for a more radical approach—removing the role in favor of a self-organizing team structure. These propositions aim not just to provoke thought but to prompt actionable change in how Agile teams align their structure to their strategic goals.

Warning, this article aims to challenge assumtions and stimulate discussion, which can be dangerous to a fixed mindset.

Scrum – a Single Team Approach

Scrum is inherently designed for a single-team, single-product configuration. Although not explicitly stated in recent versions of the Scrum Guide, its roots in software development are evident. In Scrum: The Product Owner (PO) role is defined as the owner of the product and the product backlog, accountable for maximizing the product's value by creating and clearly communicating Product Backlog Items (PBI:s). However, the reality is that most teams do not work with a single product; many are responsible for several products, often working across multiple teams. This complexity challenges the clean-cut framework proposed by the Scrum guide.

Product Owner written on a paper
Photo: © fotogestoeber / Adobe Stock

Struggling to understand the product.

Many teams grapple with defining their product. The Scrum Guide's vague definition provides little guidance, complicating efforts to clarify product boundaries and stakeholders. For instance, large monolithic software applications may have subsystems erroneously labeled as separate "products" to fit the framework, creating dependencies between teams, and hard to understand for customers.

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.
The 2020 Scrum Guide

The Dilemma of a Selfish Product

Adhering strictly to the Scrum Guide, having a Product Owner for each product and team solidifies team objectives around that specific product, potentially fostering a 'selfish' approach.

The Product Owners' responsibility is to define and prioritize new features to that single product. The Product Owner will continue defining new features even when integrating or prioritizing solutions in other products could offer greater benefits to users and the organization. This siloed focus risk hindering overall organizational agility and value delivery.

Product Owners is half outside the team

Even if I, and other coaches, advocate very strongly that Product Owners are first-class members of the agile team, it is often not the case. Depending on personality, the PO might "visit the team's daily stand-up meetings." Or "participate in the team's planning." These are quotes from rather good Product Owners but indicate an alienation from the team. Instead, they are working with other Product Owners, filling up the backlog for the team, and caring more about creating good features and having the team deliver them in time than solving customers' problems. Even if they perform Backlog Refinements, they are often a meeting where the team refines user stories, epics, or features already defined by the Product Owner.

Teams become Feature-factories

With an alienated Product Owner, teams may quickly become Feature Factories. Product management and product owners load backlogs with features they believe customers require. The team's responsibilities are reduced to swiftly implementing features with already-defined solutions and shipping them to the customer. The product owner measures success by the frequency and volume of new feature shipments, forced by a belief in the organization that is adding a new feature always adds value to the product. The organization fails to test feature ideas before building them and assess their success by measuring user value after delivering the feature. The organization does not take advantage of the team's complete competence in its domain of expertise. As a result, the work for the team members becomes less fun and less creative. I have seen these Feature Factories several times.

So, how can we avoid the drawbacks of having a Product Owner?

The solution – Rename or Self-organize

One approach to resolving the issues associated with the traditional Product Owner role is to rename it to "Value Maximizer." This change is not merely cosmetic; it signifies a shift in focus from managing a product to maximizing value for customers and the organization. By adopting this title, the emphasis transitions to a broader perspective that includes integrating and prioritizing solutions across products, thereby fostering a more holistic view of value creation. This shift encourages Product Owners to collaborate more effectively with other teams, reducing silos and enhancing overall organizational agility.

Embracing Self-Organization

A more radical yet potentially transformative solution is eliminating the Product Owner role altogether. This proposition might seem provocative, but it aligns with the principles of self-managing teams, as seen in Teal organizations. By distributing the responsibilities typically held by the Product Owner across the team, we can leverage the full competence and creativity of the team members. This approach involves:

  • Building Backlogs Collectively: Teams collaboratively create and manage a backlog, which we might rename to a "List of Opportunities." This list includes tasks and ideas contributed by all team members, ensuring diverse input and a comprehensive view of what is valuable.
  • Incorporating Business and Customer Insights: Teams can integrate business and customer perspectives either by including members with this expertise or through targeted training. This ensures that the team focuses on delivering value while remaining self-organized.
  • Fostering Autonomy and Accountability: By removing the Product Owner, teams take full ownership of defining and prioritizing work, which can lead to increased engagement, responsibility, and satisfaction among team members.

There can definitely be challenges and obstacles with this teal-inspired approach, but that might be a subject for a future article.

Conclusion

Solving the problem with an alienated Product Owner, half outside the team, and the team becoming a “Feature Factory” can be done by renaming the role to "Value Maximizer" and focusing on the value the team is providing and aligning the team on one single team backlog, rather than trying to focus the team on one single product. Consequently, some artifacts might need to be renamed, like the Product Backlog to simply the Team Backlog or maybe the List of Opportunities.

Alternatively, take a step towards a Teal Organization by embracing self-organization and self-management, removing the role altogether. Instead, let the team organize around the problems in the problem space, creating amicable solutions in the solution space and delivering high value.

These suggestions aim not only to provoke reflection but also to catalyze meaningful changes in how Agile teams are structured and operate. What are your thoughts on these approaches to evolving the Product Owner role? Do you see potential benefits or pitfalls in these strategies? Please share your insights in the comments and follow me for more discussions on reshaping Agile practices.

References and further reading

Last updated Nov 20, 2024