If we want an organization that can quickly adapt to external reality as it’s discovered (let’s call that agility), we need one Product Owner expressing vision and priorities in one list: the Product Backlog. According to the Scrum Guide, “Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product.”
We sometimes hear the concern that one Product Owner would be overburdened by this, becoming a bottleneck. Here are the problems I’ve usually seen causing Product Owner bottleneck:
The teams are depending on a “Product Owner” for detailed clarifications. According to http://agilemanifesto.org and http://agilemanifesto.org/principles we value customer collaboration over contract negotiation, and our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Therefore Agile teams talk to customers and users for those detailed clarifications. This is why we show users and stakeholders in our illustrations of Product Backlog Refinement.
The teams aren’t cross functional. A cross functional team doesn’t only code and test, it also contains business domain expertise, UX/UI skills, etc. When I was on a team with a full-time UI designer, we didn’t need our Product Owner for every little detail.
Geographic distribution, better described as dislocated teams.
Beware Fake “Product Owners”
A common agility-reducing error is to ignore Ken Schwaber’s advice and artifically designate a team-member as a fake “Product Owner.” But the Scrum Guide has a good reason to state “Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person.” The best architectures, requirements, and designs emerge from self-organizing teams. It is contradictory to tell a team that Bob the Business Analyst has special authority over the rest of the team members while simultaneously telling them to self organize. Bob belongs on our self organizing team without a process-imposed role.