Monday, February 2, 2015

Shared Vision over dedicated Product Owners

The first value of the Post-Scrum Manifesto states "Shared Vision over dedicated Product Owners".
To understand what this means, we must briefly glance at why we even have Product Owners in Scrum.

The role of the Product Owner

The primary role of the PO is to communicate the product vision with all stakeholders and maximize product value. When there is a misunderstanding or dispute, the PO facilitates the dialog. Moreover, the PO owns the Product Backlog. They decide what will be part of the product - and what won't. They set the priority and are accountable for making the right calls. Customer facing, the PO is responsible for what the team delivers. Team facing, the PO is responsible for what the customer wants.

What happens when you don't have a Product Owner

Let's just assume we have a textbook Scrum team, but the PO is missing. The first thing that will practically always happen is that stakeholders start bombarding the team with feature requests, everyone considering their own requirements top priority. The team now has the job of juggling all those requests while delivering working software. 
If the team is lacking a person who is capable of calling shots on either-or options, they run a great danger of implementing inferior solutions, dissatisfying the customer. 
On a more positive note, the responsibilities of the PO will typically be picked up somewhere, either through the customer side or the team. Unfortunately, there is no guarantee this will happen before the product failed.

Why having a dedicated Product Owner is bad

Having a dedicated PO communicate stakeholders on the product vision and making tough calls on value choices is good, but it's still a bottleneck. Since being agile is all about never ever maneuvering yourself into a corner, it simply doesn't make sense to enforce a bottleneck.
The need for a dedicated PO actually indicates symptoms for a number of problems:

Different levels of understanding

It's good if someone can explain the product vision to others, it's better if everyone shares it and product vision communication should never be a unidirectional process. 

Single Point of failure 

When someone needs to call shots, it means that this person is can singlehandedly cause an otherwise successful product to go awry. A good PO will never be a dictator, but since the PO will always filter information through their personal viewpoint, unsound decisions may be made. The more decisions PO doesn't need to make because the team has the knowledge and ability to make them, the lower the risk of having a SPOF actually failing.

Also, developers may become paralyzed or make wrong decisions if the PO is unavailable for clarification.

Stakeholders management over consensus

When someone needs to call shots, it means that different stakeholders set different priorities. This may always happen, but is a situation where one person has the final say really better than being able to come to consensus? 

Translate: Business-Developer, Developer-Business

The PO facilitates the dialog between team and customer, especially in situations where business expectations are technically unsound. In theory, this sounds good. In practice, we have an agile value "Customer collaboration over contract negotiation". Nowhere does it say customer collaboration is limited to the PO. If every developer collaborates with customers on a daily basis, the mutual understanding will be there without having a facilitator in the middle.

Assumption of incompetence or apathy

We get taught in Scrum classes that PO's understand the business value and know which increment is best to advance the product's value. Superficially, and in an immature organization, that is true: Oftentimes, developers have no understanding of business value. But that shouldn't be considered a given law of the universe. In Programmer Anarchy, there is a radical shift: Developers not only understand what is the best value for the customer, they are so closely interlinked with customers that they drive: They deliver working software and let the customer decide whether they're getting their money's worth. Sounds odd? Making developers business savvy, instilling them with a keen sense of where the money lies is sure better than simply assuming they're either idiots who know squat or who frankly don't care how their living is earned.
Just consider yourself as a developer: Which would you prefer? Having someone tell you that you have no sense of business - or having someone bring you to the point where you can do everything they can?
It is good if the team has a product navigator - it is better if everyone can read the compass to the pot of gold.


It is not wrong to have a PO. But don't focus on establishing and strengthening the role of the PO- Raise up the entire team to fulfill the responsibilities of the PO, and the dedicated PO will be superfluous.


  1. Michael, I agree with all your postulates in post-scrum manifesto except for the one regarding Product Owner. Good Product Owner creates product vision, strategy etc. This role is more akin to the Architect designing a building than to simple go-between. You cannot design or lead by committee - not if you want to create exceptional products.

    1. Hi "Unknown".
      I do agree that Good Product Owners do these thing.
      The idea of the Post-Scrum Manifesto is not to remove product vision and strategy. The idea is that:
      Great teams do this together. There is no one person who has "more vision" or "clearer strategy" than others.

      What I am talking about is not "design by committee" where everyone gets a shot and dilutes the vision, it is "like-mindedness", where everyone *shares* the same vision.

      The question "Who calls the shots?" is meaningless when no calls need to be made. A Single Product Owner in that environment solves a non-existant problem.

      The premise of exceptionality being created through a single brain leadership is founded in an Amber Organizational mindset:

      Teal Organizations do not even have this issue:

      The Post-Scrum Manifesto was created after I had the pleasure of working with such a team. I started out as Product Owner and when there was nothing I could do any more, I simply joined the team. This really depends on how the PO sees their role: Is the PO job to steer the product or to remove the need for extrinsic steering?

      An enlightened Product Owner, to me, is a Product Coach - someone who coaches others to consider the Product Vision in the same way that a Scrum Master would coach the team to consider Scrum. The responsibility of the coach is to grow their team to the point where they no longer need external intervention.

      As Product Owner, would you dare to define "success" as "When the team is making the right decisions without asking me"?