I think the single vs. multiple product owners question is one of hotly debated topics when dealing with scaling agile.

It is always great when the organization can agree on a single product owner.

However, the more departments, divisions, or geographic areas the impact of the project touches, the more difficult it becomes for one single person to effectively perform the role of product owner. It becomes more difficult for one person to build the commitment and ownership needed for the final solution to succeed across the enterprise.

I liked the fact that even with a single product owner you use a product council. When done properly, the product council can be a great tool for promoting the needed commitment and ownership.

Another approach that worked for me is to have a product ownership team (or product council) but have it be made up of members of the core project team.

The key is to establish a framework for timely decision making and escalation by keeping all decisions within the core project team. In addition, a steering committee should be established to make final decisions but only when there is an impasse at the product ownership team. Each organization is different so some trials and errors are to be expected.

With this setup, the project may get slowed down a little due to the added overhead. But, when there is conflict in interest and priorities, people that have real (not proxy) representation in project decision making will have more ownership of the final outcome of the project. In such environment, even when people don’t get their way, they are most likely to accept and own decisions if they feel they have a direct a role in how they have been made.

Your thought leadership in this area, based on real and practical experience in the trenches, is a valuable asset to all project managers taking on the challenging of bringing agile to their enterprise. I look forward to your future insights.

Thank you.

Thank you for taking the time to read this post and share your thoughts.

I agree that enterprise system integration projects are inherently full of conflict and political power battles due to competing priorities and interests from different departments, divisions, and regions.

I really see the inability to prioritize and collaborate on a shared product backlog not as an issue with having multiple product owners. The real problem I found is that multiple product owners either don’t have a framework to cooperate and align with each other or are allowed to avoid their responsibility.

Prioritizing a shared product backlog requires making tough business decisions on behalf of the entire organization. This comes with inherent conflict and tension.

In the absence of a framework for decision making, people assigned to this role will find creative and elaborate ways to avoid discomfort this conflict and tension.

Some ideas I would like to explore in upcoming posts will cover decision making rules of engagement, ways to break impasse when product owners can’t agree on a decision, time-bound decision-making, and escalation process.

I look forward to continuing the conversation and get your insights in future blog posts and comments on this topic.

In my recent work I’ve noticed that multiple product owners end up in political power battles and are eventually unable to prioritize and otherwise collaborate on a shared product backlog. This is because typically different product owners have different end users in mind. In this scenario, the pressure is put on Scrum Master and even the team – and that is not nice.

Consequently, I strongly support some sort of “reasonable dictatorship” in large projects too. Recently I’ve worked in an environment, where one product owner has several “aides” that give their recommendations for the product owner. This arrangement seems to work nicely.

I, for one, look forward in reading your posts in this topic.