Should the Product Owner Be One Person Only?

| by Amr Elssamadisy Follow 0 Followers on Feb 12, 2009. Estimated reading time: 2 minutes |

There is an important conversation taking place on the ScrumDevelopment list regarding the role of arguably the most important member of the team - the product owner.   Jean Richardson started off the conversation with the following question:

I’m working with a customer that is new to Scrum. So far, they’re very eager. We had and extended lessons learned last week on a very tough 1 ½ project, and they see Scrum as the answer to their prayers. Their manager has read /Agile Project Management with Scrum/, and one of their team members is halfway through it.
However, the manager has asked for a meeting with me later this week regarding “who will be the Product Owner.” I think his team is pushing him to share that role among all of them—or at least 3 of them (himself and two others). So, my question is, how well does it work to share that role across two or more people. Does it ever work well? If so, what is required for it to work well? What kinds of things do you see happen?

This is, evidently, not an uncommon question or occurrence.  The majority of the advice fell into two camps:

Camp 1: You should only have one product owner.  For example, Dan Rawsthorne suggested:

I always have a simple answer to "who will be your product owner". I just ask "who are you holding accountable for success? Who has the bullseye on his back? That's your product owner." In my experience, the PO is usually anointed from the outside.

This brought up several interesting observations, one of which calling out an inconsistency in the way the product owner is treated and perceived:

However, doesn't this bring up an interesting dichotomy for Scrum? If the PO is the single ringable neck from the requirements/ROI perspective, why isn't there a single ringable neck for the team?
I ask because I've had numerous conversations with skeptics of Scrum who point out the lack of accountability in the team. While the team is responsible for becoming self managing, and ultimately getting done what needs to get done, there's no single neck to ring when they don't. I've seen teams struggle to become self managing. Some never do succeed. It's difficult to hold the whole team accountable, especially when many members are doing their best.

Camp 2: On the "it depends" front, George Dinwiddie's comment was exemplary:

Yes, this can work fine and spread the workload among the three. It can also be a disaster. I've seen both.

 Do they all share the same vision of the project? If not, what vision will the developers have?

Can all three work in the team room with the developers? If not, this is a red flag in my book.

Call all three make quick decisions together? If not, think what this will do to progress.

Can they "speak with one voice?" If not, which will the developers follow?

When they disagree, do they have a reliable way of resolving the conflict? If not, who will the developers follow?

To properly answer the question, there must be agreement on what the role and responsibilities of a product owner really are. Is it primarily a 'single wringable neck'? Are the responsibilities much more extensive such that they cannot be met in a large environment? What are your thoughts and experiences?

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Typo: if it's a bell one rings it, but if it's a neck then one wrings it. by Randy Schnier

Likewise, bells are rung, but necks are wrung.

We now return you to the valuable discussion of product owner....

Should the Product Owner Be One Person Only? by Fidel Chavarria

Scrum use one product owner.

We had learned that trying to make a group of people agree in something is difficult not imposible, but we want to reduce the risk in our projects.

I´m not saying that we should not try something out of the book but remember that a Methodology (An exclusive case) is something that has been proven workable through the years.

Following a single person is easier... but the point is not about easier by Jason Yip

I would expect that the point of the exercise is to ensure the right decisions are made and the right vision is followed. If there is a single person who can facilitate that, then that's easier. If there isn't, then it's quite irrelevant to be thinking about "one wringable neck" or "who will the developers follow".

"One wringable neck" is worrying about finding who to blame. I'd suggest it's more important for everyone to worry about understanding the market, final customer, problem, or whatever reason why the product, project, system is being built in the first place.

Re: Following a single person is easier... but the point is not about easie by Amr Elssamadisy

There is an interesting article on the Agile Journal that touches on this topic loosely. Basically it says we can easily fall into an "alignment trap" when we focus on aligning with the business before getting our technical ducks in a row.

one next maybe, but that's missing the point by Jeff Anderson

having someone stand up to be accountable doesn't mean they're the only one who's going to take the fall...
if the project fails, it's going to roll up and downhill regardless of what scrum says. But having a active stakeholder who's going to take responsibility along with the team is a great thing.

Likewise, this whole "the team is equally accountable" idea is great in practice, and shared responsibility is something worth pursuing but if something fails, the resources with the most years of experience are going to be most impacted in their careers, again, it doesn't matter what scrum says, that's a reality you will never escape.


"Single Wringable Neck" - Ugg by Mike Bria

This euphemism lives right below "Chickens & Pigs" on MB's I just hate that list.

If any one person has to have their neck wrung for your agile project/product's failure, then you're screwed anyway, you missed the point. This, really, is referring to "accountability"; and that my friends is a team sport, if you be smart (and you "be agile"). That team, it sure as heck includes Dr. (or Dr.'s) Product Owner, but it also includes every single member of the team itself. "We are ALL accountable, we fail together, we succeed together."

That said, now, the idea of a single point of "vision" (or "prioritization") - I do see value in that. As with all things, it depends though. Does that have to be one person? No, of course not. Might it be easier if it's one person? Sometimes.

I can say that it is possible to take a group of Product Owners and get them to come together to speak with one voice, it can take work and some fancy footwork, but I've seen it happen.

As usual, just my wooden nickel.


Shouldn't really matter? by Dmitry Tsygankov

I'd say, if it matters - that's an indication that something is wrong. That means, two people have different opinions on what should be done. And that could mean one of the following:
- Neither of them understands what should be done
- One of them understands what should be done but cannot explain to the other person why, or the other person doesn't bother to listen.
So, basically I'm with Jason.

Re: "Single Wringable Neck" - Ugg by Mike Bria

Decided to go into a bit more detail on what I'm saying here. Check it out and let me know what you think!


Re: "Single Wringable Neck" - Ugg by Siddharta G

I agree with Mike: the "One neck to wring" euphemism doesn't sit well with me. I'll go a step further and say that I don't think that's the point of a PO anyway - like you say everyone must share responsibility.

For me, the job of a PO is to set the vision and make business decisions regarding the software development. For that I'd prefer a single PO who understands the domain and the customers, rather than a committee. That's probably why I'd still prefer a single PO, though not for the accountability reason.

Re: "Single Wringable Neck" - Ugg by Amr Elssamadisy

From Mike's blogpost:

...the members of Agile Team 2.0 trust one another, engage in unfiltered conflict around ideas, commit to decisions and plans of actions, hold one another accountable for acting on those decisions, and focus on the achievement of collective results.

Here! Here! (or is it Hear! Hear! ?) Anyways, well said!

Missing the benefits of the Product Owner role by Charl Dreyer

Most articles like this focus on the "expecting trouble" outcome with the view of wringing someone's neck. (That this threat is hidden in euphemism tells us something.) This misses the point of the Product Owner role in my opinion. Product Ownership is neither a part time role, nor one that should be split amongst a number of people. The role is big enough and senior enough to be entrusted to your single best person.

In my definition of the role, the "Product Owner directs the team to deliver the right solution to market that meets user needs and stakeholder expectations, in a way that is innovative, ethical, and respectful of the rights of others." There's so much in this role to benefit most organizations, and it addresses what software development has been missing over the years, especially unity between the market (both customers and users), business, and development. When you do all this, I'd be surprised if you had time for anything else.

Hmmm by Steve McGee

I'm pretty surprised there is no mention of product/program size and number of teams. Regarding the single team:

Each development team needs a scrum master and PO. They serve as the team leader and provide direction to help the team do the work.

The dynamic I see is that, by splitting team leadership tasks into 2 different roles, a more realistic amount of work is tackled and higher quality is the result. One leader focuses on the work process and the team's adherence to it. The other focuses on what everyone is working towards and helps make decisions of which direction to take and how many steps forward (or back) to take in each iteration.

With two different people measured by their ability to achieve this sometimes conflicting interests, businesses get rid of the dysfunctional management where one interest trumps the other - as the PO tasks are visible and appreciated by upper management, those interests (build more features faster) are the choices an average project manager will make versus SM-type tasks (ensure disciplined development practices to reduce technical debt).

So let's say there is more than one team - does this change the dynamic mentioned above? No, it doesn't. That means each team needs/gets a PO.

How to coordinate between PO's? I've been researching this and have seen there are many good answers to this issue. Scrum of Scrums in and of itself leaves a lot to be defined yet.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

12 Discuss