Seeing the system dynamic: 1 vs. n product owners

I thought that this choice was essentially the same as the choice of 1 vs. n Product Backlog. When I examine more, I find it worthwhile to write it as a separate topic. As the two most popular scaling frameworks - SAFe and LeSS, they made different choices on this. ART in SAFe and LeSS (up to 8 teams) in LeSS are comparable in size. In ART, there are product manager and team POs; while in LeSS, there is only one PO working with all teams. In this article, we shall explore the dynamic around having 1 vs. n POs.

In the description of ART in SAFe, it states the reason of having team POs.

"At scale, a single person cannot handle both product and market strategy while also being dedicated to an Agile Team. Therefore, the 'PM/PO' team steers the train together."

Let's explore the dynamics of why doing so and what consequences it causes.

Prioritization over Clarification

The below CLD illustrates the dynamic about introducing multiple POs to share the workload of requirement clarification.

Introducing multiple POs as a solution to reduce the workload of requirement clarification by one PO is reflected by B1-loop, which can read like this:

• Higher workload of clarifying requirements by one PO
• More POs
• Lower workload of clarifying requirements by one PO

Behind the solution, there is a common misunderstanding about PO solely responsible for requirement clarification. In one-team Scrum, it is more a matter of choice, as described in Scrum guide.

"The Product Owner may do the above work, or have the Development Team do it."

The above work includes requirement clarification.

While in multiple-team Scrum, it is more a necessity if we would like to enable one PO to work with multiple teams, as described in LeSS.

"A LeSS Product Owner focuses on thinking hard about prioritization but collaborates with the teams on clarification. Further, he encourages and helps the teams enter into a direct conversation with true users and customers for clarification. He acts as a connector, not an intermediary."

This alternative solution is reflected by B2-loop, which can read like this:

• Higher workload of clarifying requirements by one PO
• More participation on requirement clarification by team
• Stronger ability of working with customers by team / Richer business domain knowledge by team
• Lower workload of clarifying requirements by one PO

The R-loop explains why it is so common to stick with multiple POs. It can read like this:

• Higher workload of clarifying requirements by one PO
• More POs
• More dependence on POs
• Less participation on requirement clarification by team
• Weaker ability of working with customers / Poorer business domain knowledge by team
• Higher workload of clarifying requirements by one PO
• More POs

If you have read the previous blogs in this series, you must have recognized the system archetype of "shifting the burden" here.

Status Quo of Contract Game

The below CLD illustrates the dynamic about introducing multiple POs from R&D to accommodate the change resistance on business side.

Traditional way of working between business and R&D is through contract game. Business and R&D negotiate a contract for the release, then, business leaves R&D to deliver the contract. There was no sprint-based collaboration between them before adopting Agile. It means more change needed on business side when you want to have more POs. The resistance ensues and more POs in R&D are created as a result. This solves the resistance problem meanwhile fulfills the need to have POs. The status quo is maintained.

The B1-loop is the quick solution, which can read like this:

• the more change needed on business side (more POs needed)
• the more resistance it creates
• the more POs in R&D introduced
• the less change needed on business side

The B2-loop is the fundamental solution, which can read like this:

• the more change needed on business side (more POs needed)
• the more resistance it creates
• the more coaching for business
• the more collaboration introduced between team and business (either as POs or as stakeholders, but the key is to collaborate sprint by sprint)
• the more value it creates and the more flexibility it creates
• the less change needed on business side

The R-loop explains why it is so easy to revert back to status quo. It can read like this:

• the more change needed on business side (more POs needed)
• the more resistance it creates
• the more POs in R&D introduced
• the less collaboration between team and business (as PO-team collaboration becomes internal for R&D)
• the less value it creates and the less flexibility it creates
• the more change needed on business side

Again, you see the system archetype of "shifting the burden".

Conclusion

I have seen two common setups when having multiple POs for one product.

In many Internet companies, those team POs are product managers at the low level. They are working mainly on tactical level, not much on strategic level. When they feed teams with detailed specification and UI sketches, the level of team engagement in product discovery is low. This not only misses the opportunity for team to contribute, but also creates barrier to reach shared understanding for delivery.

In more traditional industries, it is common to introduce team POs inside R&D. When they are focused on requirement clarification, they essentially regress to traditional BAs. There are many arguments against BA role, and my favorite is the keynote from Martin Fowler and Dan North in QCon London 2007. In short, "bridges are better than ferrymen".

Be aware of the consequences when you choose to have multiple POs.