Strategies for product owner across multiple teams (with different products)

A product owner should be dedicated to one team. Or no more than two teams working on the same product with the same product backlog. But what about a product owner who we spread across two teams with different backlogs working on different products? We’re asking them to be two people and it’s not sustainable! This product owner told me he was in 17 hours of meetings between the two teams per week (and I added it up and it was true)! For the product owner who should be splitting his/her time between self thought, stakeholder and customer input, and team time, it’s not possible for those things to be equal or sustainable not to mention the loss of productivity when context switching/multitasking. Though unfortunately this is the non-ideal reality sometimes.

I wanted to say we need to hire another product owner (which I actually did say), but for the realistic interim we needed to make it work for our products and our teams. So, what then are our options?

1. Appoint another product owner or partial product owner on one of the teams

While this is a decent idea in theory and could potentially work for some teams it will not work for these teams. The teams are too immature with Agile principles and Scrum to be able to balance self-organization with product direction coming from two different people. Plus, we want one product voice of reason and the part-time owner would not be taken seriously. What’s worse, is if the part-time owner on the team was a developer (likely) their balance of work between features and tech debt and defects likely would tip the scale toward the latter. They also would not have the product expertise to advise on the new feature requirements. All good considerations and it may be an option for some teams that don’t have these constraints.

2. Determine what meetings are absolutely vital for attendance by the Product Owner – prioritize and do trade-offs

Does the product owner need to be in the daily scrum every day? No, actually they aren’t actually required to be there at all. Let’s cut that responsibility down. Does the product owner need to be in Sprint Planning for the entire time – hmm. Well they need to be there at the beginning to discuss the top priority items, but if we have been grooming our backlog regularly these should not be brand new to anyone on the team. When the team has committed and will be tasking out the work, the product owner can be less present and answer questions as needed. Maybe a tech lead can help here, too.

3. Lean on the ScrumMaster(s) and the team

The product owner should not have to facilitate every sprint planning, review, and backlog grooming. The team and ScrumMaster can step up to do this. If someone else is driving the tool, the PO can be more effective and efficient in collaborating, explaining, and moving stories along.

Another good thing to consider is: if the PO does more upfront planning (say an hour) before one of these meetings, can some of the time spent in them be cut off? OR if the PO or SM encourages team members to look at what is upcoming and review prior to these meetings, can some of the context setting be scaled back?

4. Back to basics – fewer tools

How much time in meetings is wasted getting technology set up to cooperate? Can we be better at arriving a few minutes early to a meeting to set this up? Or better yet, if all team members are co-located, can we go back to using index cards to write out stories and break down work? I guarantee it will be faster than putting it all in a clunky tool in front of the team (not to mention the inevitable mistakes we make when nervous typing). Sounds simple, but if we can cut out an hour or two a week of hassles, that gives our time-strapped PO some time back. It would also be a great review to enter the stories/tasks into the tool separately to once again review if there is anything missing when we think about it a few hours later.

Are any of these the silver bullet? No. But they are some things that you can try in this less than ideal world we live in when trying to be Agile while using Scrum and combating corporate realities. What are some things you have seen?