Having 2 Product Owners for same product

Why do you think the Scrum Guide states that "The Product Owner is one person, not a committee"? What problems are avoided by having exactly one Product Owner for exactly one Product Backlog?

Bear in mind that the Guide goes on to state that the PO may represent the interests of a committee. Also, remember the Guide further states that a PO may have the Development Team do some of his or her work, although he or she must remain accountable for it.

What's the sentence after the one you quoted? ;-)

Ian, I know there are benefits for having one PO for one backlog and also I agree that PO can delegate some of his work to team, but its "some of his work" not "most of his work". The scenario I mentioned is that even by delegating some work to team, still PO is overburden due to following activities that I already mentioned.

-Frequent communication with 5 third parties

- Continuous meetings with client

-Backlog management for 3 teams

-Participating in sprint planning, refinement and grooming meeting of all three teams.

So the question is why there cannot be another PO?

Even if there are 10 scrum teams and a single product backlog so still we will be having 1 PO?

Are you sure that the Scrum or Nexus Guide limits the assistance Development Teams can provide to their Product Owner?

Are you sure that the Dev Team can't have most of the fine-coarse refinement works done with the users/customers ?

Dear Ian and Dear Olivier, yes dev team can provide assistance to PO but still it becomes difficult for PO to manage things if he is having multiple teams. My simple question is that why not more than 1 POs for multiple teams working on same product? Why it is a hard rule?

If a single clear authority cannot ultimately account for a product's scope and value, would it be responsible for a team to try and develop that product at all?

Might it be better to look again at how the product is defined, including any underlying value proposition, and identify products which *can* be properly accounted for instead?

Everything mentioned above can be delegated to other members of the Scrum team, though the stakeholder communication really should only be done by the PO. In reality, the PO does not have to sit for the entire Sprint Planning meeting. The PO should present the backlog items, advise the Spring Goal and of the prioritization for certain items but then the PO can leave. Now, the PO should be available for questions regarding the backlog but what benefit is there by having the PO just sit in a room for 4+ hours when he/she is only needed for a fraction of that time? The PO I worked with was stretched very thin so in our sprint planning, he would present the backlog, explain the goal and priorities and then leave. Myself and the Dev Team would go through the sprint planning and then call the PO back in to present to him. Most times he agreed and gave his stamp of approval, other times he would give feedback and we would negotiate the changes proposed. Same goes for the refinement and grooming meetings, so long as the PO is available for communication there is no reason they should be forced to sit through another meeting. 

My 2 cents on why the hard rule for only 1 PO, since there is only 1 Product there should be only 1 PO. Not many companies have 2 Presidents and/or 2 CEO's. In the same manner that the President and CEO may not do all the work, they are accountable for the work. I think the PO should delegate a bit more and maybe learn some more time management techniques. "The PO may do the above work, or have the Dev Tem do it. However, the PO remains accountable" (Scrum Guide, page 5).

1 PO for 1 product is totally for the considerration of authority and responsibility. You need ONE to get held accountable when things go wrong with the product, do you? -  joking :)

Following strictly this principle, you can have some varations in the team structure to fit your organisation or your product.

E.g.

1 One Sr PO leading a number of POs. The senior one is responsible for the whole product, each PO responsibile for a sub system.

2 One PO assisted by a number of BAs from dev teams. You can have one BA on one dev team so the PO can delegate to a dedicated team member.

Dear Will Niu I agree to your points.

Dear Ian and Dear Curtis, you both say 1 PO for one product backlog, so what about following concept?

https://www.mountaingoatsoftware.com/blog/the-chief-product-owner-on-la…

Why not ask the author about the principle of having one Product Owner for one Product Backlog? You could discuss the importance of having a single, clear, and ultimately accountable voice for product value.

Do you disagree with the principle in the blog?

If you think about it, the blog still comes back to a single PO overall. In this case, the Chief Product Owner is solely accountable for the product backlog as a whole while the Product Line Owners and Product Owners are accountable for their portion of the Product Backlog. The CPO delegated tasks to others that would act in his/her place but it still comes back to 1 person being accountable. It is like the saying "6 or half a dozen", meaning it may be called different things but ultimately they are the same. 

If we assume that is the case - and that it does resolve to a single PO overall - might the renaming of this role to Chief Product Owner (and redefining PO responsibilities) hinder transparency?

Ian, 

Admittedly, I don't have a great deal of working experience as a Scrum Master so you'd be better to give insight on that. With that said, I think it may depending on the hierarchy and chain of command. For the developer that has a question, there are 3 different levels that could potentially be in the way of an answer (PO, Product Line Owner, and CPO per the blog). I could be way off base on this. What are your thoughts on this?

An important principle, when implementing Scrum, is not to rename or redefine any of the elements  of the framework as described in the Scrum Guide. If we change what the words mean, people can no longer be quite sure that they are talking about the same thing, or what the outcome of an implementation might be.

If we rename a Product Owner to “Chief Product Owner” for example, or redefine a Product Owner’s responsibilities, then the expected benefits of product ownership may not be realized in quite the way people might be lead to expect. Being consistent and accurate in the way we use Scrum terms of reference is therefore of great value.

Ian, 

I understand and fully agree. I think my comments may have gotten away from my ultimate point that the PO can always delegate responsibilities to other members of the Scrum Team per the Scrum Guide. Also that even with scaled example in the blog posted, whether it's a Chief Product Owner or a Product Owner, there is still 1 main person accountable. Personally, I'm not one for changing titles and responsibilities. If Scrum is the framework adopted within an organization, then the roles and responsibilities should be followed per the Scrum Guide. 

1 PO for 1 product is totally for the considerration of authority and responsibility. 

A friendly word of advice that has served me well - try to avoid "absolute" statements like always, never, totally, etc.   They are inherently extreme statements that often prove inaccurate,

That said, there are other reasons why it is beneficial to have one PO for one product.   One that jumps to mind is the reduction of waste (from a lean perspective) with that framework (less handoffs, less communication, cleaner approach).

Think of the benefits of a central data repository in comparison to maintaining and coordinating data across multiple sources.   A single PO per product provides similar benefits.

In Scrum, we have 1 Product + 1 PO + 1 SM + 1 Dev Team (3-9 people). period

Scrum is not dealing with multiple Dev Teams.

At large scale, it is not "pure" Scrum any more.

With agile frameworks like Nexus or LeSS (and even LeSS huge), it is really Scrum at scale (the 3 roles of Scrum are respected and suffer no changes) : so 1 Product => 1 PO. period

With other agile frameworks, including custom-made, it could be different.

For instance, with SAFe, 1 ART = 1 "Product Manager" but 1 PO per Dev Team, with some differences in the definition of the PO compare to "pure" Scrum.

You are free to choose the framework and its rules & principles that best suites your context.

Olivier, " In Scrum, we have 1 Product + 1 PO + 1 SM + 1 Dev Team (3-9 people). period

Scrum is not dealing with multiple Dev Teams."

If it is the case so I have got answer of my question finally:).

But I just want to know is it stated somewhere in scrum guide or by Schwaber and Sutherland  ? If yes so please give me some reference , it will help me in understanding.

What about the Scrum Guide ?

http://www.scrumguides.org/scrum-guide.html#team

Olivier.

So it can be concluded that 1 PO for each scrum team also 1 SM for each team?

Each Scrum Team must have exactly one clear Product Owner. That PO may however be shared by multiple teams. This ought to be the case when many teams are working on the same product.

At any given time, there should be exactly one PO for any one product, and all the work for that product should be accounted for by that PO on exactly one Product Backlog.

Ian,

1.Each scrum team must have a clear PO.

2.Multiple teams can have the same PO.

Is is not something conflicting?

No. It's a straightforward one-to-many relationship.

e.g.

Team Alpha has a clear PO (Mary)

Team Beta has a clear PO (also Mary)

The Nexus Framework uses this model. We can expect 3-9 Scrum Teams working on the same Product. Each Scrum Team is well-formed (hence each has a clear Product Owner). In each case the PO is the same person representing the same Product and owning the same Product Backlog.

So Ian, I am concluding it as following.

One PO for each team but this PO can be shared by multiple teams.

One PO for one product i.e one backlog.

correct?

Correct.

Thanks Ian, Olivier and everyone.

Thank You All for this Interesting topic and inputs.

Ian, I have one point "How granular can be a Product ( Product Backlog )?"  Any suggestions? Is it a good idea to breakdown the Product when it becomes clear that the Product Scope is huge with little time in hand? Each broken Product Scope is sufficient enough to be called a Product and a separate Product Backlog is created for it.

Is it a good idea to breakdown the Product when it becomes clear that the Product Scope is huge with little time in hand?

Not really. It would be time to identify and validate the MVP for the Product you have.

Each broken Product Scope is sufficient enough to be called a Product and a separate Product Backlog is created for it.

Rather than just calling something a Product, can you prove that it is one? Can it be developed and delivered to a "Done", releasable standard? Is it discretely valuable in its own right, so that each increment can be released, inspected, and adapted? Does anyone genuinely wish to own the product, and account for its value? Is the product free of integration dependencies, so that teams committed to achieving product goals can achieve a "Done" standard by themselves? 

I am the Product Owner for what once was a 12 developer team for one product.  This is a huge product with many features, domains, etc.  Recently we've added a second Product Owner and split the team.  There was a lot of talk about how to split the work for the teams (both teams have essentially the same skillsets), but before a true decision was made the teams were split and myself and a new P.O. were assigned.  Now we are working out of one backlog that I have owned for 3 years, and trying to split work without any clear defined separation.  It is one product, but we have many interfaces integrated with it.  I believe the best way to manage the work is to identify the interfaces (domains) and assign equally (if that's possible) to the two teams.  The problem is that we have a massive list of day 2 enhancements, corporate goals, vendor-required updates, and those with powers over mine want to be able to divi out the work as it comes along.  The point of bringing in a second product owner and splitting the teams was because the load is too large for one product owner, who is also tasked with managing and prioritizing bugs, to manage.  

But I have already found that anyone and everyone needing anything with our product is now contact both myself AND the other product owner because it is not known whose team will tackle the work they may need done.  I am already finding that both product owners are involved in everything being asked of our product/teams, which actually increases my load from when I did manage one huge team.  Now I'm managing one huge team AND the second product owner is essentially doing the same thing.  

QUESTION - Which is better? Two teams pull work from the same huge scope of the product, or two teams that each have clearly defined pieces of the product where their P.O. has the same clearly defined responsibility and ownership?

Thank you!

What does the Scrum Guide say about how many Product Owners there ought to be for one Product?

In your situation, why are Product Owners managing teams at all? There are only two teams. Can’t they self-organize, with their Scrum Masters to facilitate as needed, and manage their own dependencies?

@Nikki Bergendahl,  From your description you still have 1 product and should have 1 Product Owner. However, you might want to look at the way that product is defined. Is it possible that you actually have more than one product? From the way you described it I am visualizing something similar to an online community or set of cloud based tools.  Could portions of the existing product be released independent of other parts? Can portions of the existing product be seen to provide value to the user and your business independent of other parts? You may be able to legitimately separate out portions of the existing product into segments that can be worked by individual teams. 

I have experienced where the definition of a product is made at too high of a level because it was easier to do so.  But it usually led to the situation that you are encountering. Inspect and adapt your definition of a product.  You might find it much easier to manage. 

QUESTION - Which is better? Two teams pull work from the same huge scope of the product, or two teams that each have clearly defined pieces of the product where their P.O. has the same clearly defined responsibility and ownership?

What challenges to communication and integration might you have to tackle if two teams are working from the same Product Backlog? 

It may be desirable in some cases to decouple a group of features into it's own product so that a new team (PO included) and Product Backlog so there can focus on managing the product life cycle. 

Perhaps consider what your past experiences and outcomes tell you would be best for your Product(s).