The Demise of the Product Owner

Are certain agile scaling frameworks endangering the role of the Product Owner? Or is it rather an organizational challenge to overcome?

by Jeff Himmelright

“The reports of my death are greatly exaggerated.”

– Mark Twain in a cable sent from London to the press in the United States after his obituary had been mistakenly published.

The topic of scaling agile in organizations has become ubiquitous. Discussions and strategies can be found on countless online forums, books, and webinars. Yet scaling agile product teams remains the holy grail of organizational transformation. Insofar as scaling is concerned, one frequent topic (or accusation rather) is that certain frameworks inherently kill team roles, especially the Product Owner (PO) role. However, long before the prominent rise of scaling framework organizations, the demise (or at the very least, the watering-down) of the PO role was already a topic of concern. Please refer to this June 2011 Forrester? report: Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today, where it discusses the fact that so many Product Owners are merely Business Analysts who do not actually "own" the product and lack authority to make product-related decisions.

As with many practices in agile, scaling is more an art than a science. No organization can or should attempt to specifically copy another organization’s scaling format wholesale. The fact that Spotify? has shown success in scaling does not mean they have found the magic cookie-cutter template that can be distributed to other organizations out-of-the-box (or that we should begin issuing Spotify? Scaling Certifications). What it does demonstrate, however, is an organization that experimented with various structural formats until they succeeded. In essence, Spotify? became a learning organization. That, in my opinion, is the holy grail of organizational transformation – i.e., becoming a learning organization. But it is achievable!

The method or framework used for scaling – or even the question as to whether an organization should scale in the first place – is an organizational-specific question. To be sure, I do not wish to be labelled an apologist or defender of scaling agile frameworks; SAFe? certainly has gone excessive with their prescriptive methodologies and it is apparent in the overlaps with their core competencies that have recently increased from five to seven (pretty soon it may be nine). Nevertheless, in my opinion, the downfall of the PO role is not a prescription or limitation that is inherently baked into any agile scaling framework; rather, it is an organizational shortcoming that can and should be avoided.

For anyone who is in an organization that is implementing an agile scaling framework, if it becomes clear that the PO does not have the authority within the larger team of teams to influence priority toward value or to interact directly with the customers, but rather defers all to the Product Manager or specific outspoken stakeholders, then you need to address the PO role in the structure of the organization; but I would not advise switching randomly to a new framework, as if that will be the cure, just like I would not advise switching to a new tool to fix a misaligned and ill-refined backlog.  

How do we avoid this untimely and unfortunate PO demise? Each organization should track why they do something and how it adds value. At the end of the day, user adoption is the key! A good PO knows this and engages heavily in this direction. Whether an organization provides a product or a service, if the user isn’t using it, then the organization provides no value in that regard. Perhaps an organization has the time and capital to try new endeavors to see what sticks. If so, then it becomes a hypothesis-driven value stream.

The PO who maximizes value through team engagement and demonstrates this value is very much alive!

The PO role; therefore, exists to ensure that value is being delivered and that the value aligns with the vision of why the organization exists in the first place. I don’t need (or want) my PO to be a Jira? Jockey. And I have seen that happen far too often in organizations, regardless as to whether they are running in SAFe?, OKRs, or any other number of hybrid Agile implementations. On the other side of the coin, I also don’t want my PO to merely manage stakeholders and throw requirements over the wall at a team, which will then need a Business Analyst liaison to make sense of it all, which will further distance the development team from the value receivers.

If my PO can communicate directly to his/her team as to why they are working on something and consistently show end-user satisfaction and feedback, my PO has successfully engaged the team. When the team feels involved because they share a vision and feel a sense of purpose in their tasks, again, success! The PO who maximizes value through team engagement and demonstrates this value is very much alive! Thus can the Agile Coach guide the PO toward maintaining value delivery as their focus and with increasing transparency toward the team members and stakeholders, which means a scaling framework cannot inherently kill that role. Treat a scaling framework just as it is – a framework!

User adoption is the key!

Be the ball!

I hope you found this article informative and perhaps entertaining.

Best of luck in all your projects and in becoming agile!

#betheball #useradoption #valuedriven #startwithwhy #agile