My first job as a Product Owner was at a company and industry that were new to me. I enthusiastically embarked upon learning the business, the (very large and complex) products, and getting to know the team and customers. After a few months, things seemed to be going pretty smoothly and my boss asked me to take responsibility as Product Owner on a second team. Challenge accepted! I took it as a sign that I was doing a good job and ready for more responsibility. Now I had two large (7 +/- 2 people) Scrum teams both dealing with unrelated parts of a complex product and implementing unrelated, complex customer needs. Was I learning as deeply about the product and the customers as when I only had one team? Maybe not, but I still felt that I was growing and delivering value.

The mistake that I made was in accepting a third large team, also with a complex problem to solve, unrelated to the work the first two teams were doing. While it was fun to operate at such a fast pace, I started missing daily standups and retrospectives. Sometimes I had to focus on one customer for a few days at the expense of my other teams. In short, I stopped being a good Product Owner. Worse, I relied more on others around me for quick answers to questions about how the (existing, complex) product that we were enhancing worked rather than discovering that for myself thus stunting my learning process. The teams felt as though they were not getting what they needed from their Product Owner.

Eventually I went back to being PO for just two teams. What did I learn about a Product Owner’s maximum capacity?  It’s not as simple as saying that it is a maximum of two or three teams. It may only be one team. It might be three teams. It depends on:

1. The Product Owner’s level of domain expertise and level of existing product knowledge.
2. The complexity of the customer’s needs or goals. Complex problems take time and collaboration to figure out.
3. Whether the different teams are working in the same domain (or in the case of a very large problem domain, are they working on the same aspect/area of the same domain).
4. Team sizes. Bigger teams usually mean more is completed in each sprint which means more work for the PO before and during sprints.
5. The Product Owner’s level of expertise at being a Product Owner. If the ceremonies and nuances of working with a team and the customer are still somewhat unfamiliar to the PO, it will take them more time do fulfill basic PO responsibilities.

Reflections:

• There is no simple rule for determining how many teams a Product Owner can serve at the same time. Look at all of the factors above when deciding how much is too much.