The Product Owner is a very important role in Scrum. He has the key responsibility to create, manage and prioritize the product development backlog. Can this responsibility always be to a unique person or is there situations where you could have a team of product owners? Kenneth Rubin discusses this topic in his “Essential Scrum” book.
Every Scrum team must have a single person who is identified as the product owner and is the only person empowered and accountable for fulfilling the product owner responsibilities for that Scrum team.
Should we allow a team of people to perform the product owner role? If by team we mean a group of people with shared decision making and accountability, definitely not. To properly apply Scrum, we need one individual to be the product owner, making decisions and acting as the single voice of the stakeholder communities to the Scrum team.
That being said, some organizations might form what they call a “product owner team” because they recognize that, in their circumstances, the product owner cannot do the job without a select group of people to provide input and guidance. In other companies, the workload of being a product owner might be greater than any one full-time person can reasonably perform. In those cases, the product owner delegates some product owner responsibilities to other people. Forming a product owner team in either of these circumstances is acceptable as long as there is one person on the team who is the ultimate decision maker and as long as having a product owner team does not degrade into design by committee, with every decision needing approval from eight other people.
Be careful when creating product owner teams. Product owners who are not properly skilled to be the empowered central point of product leadership don’t need a committee-they need a different role. Similarly, product owners who are too busy to fulfill their responsibilities might not need a team. Perhaps the real problem is that the organization has chosen to start too many development efforts at one time, or there are just too few product owners to cover the necessary products.
Alternatively, perhaps the product we are building is just too large and should be broken into a series of smaller pieces with more frequent releases. With small pieces a single person might more easily fill the product owner role. Also, if we have structured our teams poorly, or poorly conceived the product backlog structures , a single product owner might find it difficult to do his job. Be sure that your product owner teams are truly necessary and not just masking an underlying problem; otherwise, the situation will become more complicated and jeopardize your overall outcome.
Source: Essential Scrum: A Practical Guide to the Most Popular Agile Process, Kenneth Rubin, Addison-Wesley
Even if the concept of the lonely Product Owner that could discuss all topics and take all the decisions is appealing and could provide a better source of input for Scrum teams, this is however not always possible in the real world. As Ken Rubin writes it, you should distinguish the need from multiple product owners from the situations where one product owner could be enough, but he has not the time or the skills to fulfill his role.
There are cases where you try to build a product that will suit the needs of different user groups in the same organizations, of multiple companies or possible customers that might have different regulations. You could aim for instance to create a payroll software that will meet the requirements of multiple countries, each with its own employment laws. In this case, some of the expertise is spread across many people and having only one product owner will just make the conversations with the team very cumbersome as he could have to refer to the country expert for every question raised by the developers.
You have also to integrate the fact that it is always difficult to work alone and consider all aspects of a topic. As a software developer might want to show some part of problematic code to a colleague, a product owner could like to be supported and challenged by other business people with similar responsibilities that play the role of sounding boards in his activity.
Another reason for having multiple product owners from different parts of the organization is also to increase the rate of acceptance of the new software. New software means often changing something in the organization and this is often difficult for part of the organization. It will be “easier” for them to refuse the new software if they can say that they were not involved in the requirements gathering process.
Further reading on Product Owner Teams
* Why a Product Owner Team?
* Product Owner Team – How to build a big product in a collaborative way
* The Product Owner team
* Scaling the Product Owner
* How To Hire Product Owners