Clayton Lengel-Zigich, Derek Neighbors, Roy vandeWater and Drew LeSueur talk about the role of Product Owners.

• Is it necessary (to have a single product owner)
• Problems with multiple product owners
• Priorities
• Who determines done
• Proxy product owners
• Accountability issues
• Delegation of authority
• Dealing with multiple products and a single development team

 Transcript

Derek Neighbors:  Welcome to another episode of “The Scrumcast.” I’m Derek Neighbors.

Roy van de Water:  I’m Roy van de Water.

Drew LeSueur:  I’m Drew LeSueur.

Clayton Lengel‑Zigich:  And I’m Clayton Lengel‑Zigich.

Derek:  What you are talking about today guys?

Roy:  We are talking about the benefit and also the necessity of having a single product owner.

Derek:  Is a single product owner really necessary?

Roy:  I supposed it isn’t really necessary, but I certainly think it helps things a ton. A lot of times when you have multiple product owners on the scene, you get a lot of conflict of interest. You have one guy, who thinks his entire priority queue is the most important thing in the world and another guy, who thinks his priority queue is most important thing in the world.

And you have to have somebody that ends up reconciling those two queues. Often times that ends up falling to the developer which really shouldn’t be his responsibility.

Derek:  So is the number one reason that multiple product owners is a problem is one of priority? Meaning that four product owners, all four think their thing is the most important thing. They all have a number one thing in determining which one of the four number ones is really number one is the problem? Or are there other problems with having multiple product owners?

Roy:  I think there’s a lot of other problems with it. I find that in my recent experience this has been the specific symptom that’s hurt me the most, but another huge issue to it is you don’t know who to go to for a particular issue. If something comes up, who do you talk to? Do you start tagging every story with one product owner or the other, and who decides when a certain piece of functionality is done?

Derek:  Have you guys had any instance where a proxy product owner has been deemed for sub‑product owners? So maybe there are four product owners, and everybody agrees that that’s unilaterally a bad idea. So neutral product owners put in place to prioritize or speak on the behalf of the four other product owners. Have you seen that? If so, have you seen it work or what are some of the problems with it?

Drew:  I think one of the problems with that is if you’re not talking to the source, then you don’t really get the same power or authority that the source will give you. So if I’m talking to a proxy, he might not understand it the same way that the actual real product owner understands it.

So I’ve seen that, and I’ve seen it where when we are talking to the source, everything’s a whole lot clearer. You feel like you can really have the communication that’s needed to figure out what you need to do.

Clayton:  When you think of the roles that are required for the product owner on the scrum team, when there’s a proxy product owner or more than one product owner, it gets really easy to skirt the responsibility that they have. So, maybe, the development team needs the product owner to do some interfacing with some stakeholders and prioritize the backlog, or do some backlog grooming, or whatever.

But when there’s a proxy, it’s easy for them to say, “Well, I would love to do that for you, but I need to go talk to these three people and I can’t really do it.” Or if you have more than one product owner, then it’s like, “Well, that can be Joe’s job, I have more important things to do.” So, the responsibilities of the product owner get wishy‑washy, and some of that gets avoided.

Roy:  I think, too, one to the defined responsibilities, for both product owners and scrum masters is to protect the development team from the stakeholders and all the people outside of the scrum team. I think that when you start making the stakeholders the product owners themselves, technically they’re not outside the scrum team. Now you’re having all of this outside interaction coming in and interfering with the development team as well.

Derek:  Do you think that one of the problems, I’m trying to think, what are some of the reasons why we end up with multiple product owners? Is it because stakeholders are unwilling to let somebody represent them?

Let’s start with that one. In the case where maybe there’s three stakeholders to a product, and none of the three are willing to give up control of determining priority or making sure the direction of the product is going their way. What are some ways that you could effectively potentially use either a proxy or get one of the three to speak on behalf of the others?

Clayton:  I think if you have a strong product owner, even if they are a proxy, they can still treat the other people as stakeholders, do all the interfacing and prioritization that they need to do, and helping the team define done. They can still do all those things.

In my experience I’ve seen, maybe the flipside of what you’re asking, Derek, it’s not so much that the three people don’t want to give up the responsibility. It’s more often than not, where the proxy person doesn’t really want to take all that responsibility on, because they don’t want to stick their neck out and be the single wringable neck, so to speak.

They don’t want to take that responsibility and then be accountable to those three people. They would rather say, “Oh, sure. I’ll be the product owner.” And then, when push comes to shove they can say, “Well, I’d love to help you out, but I need to go talk to these guys.” And I don’t think they want to be accountable to the organization.

Derek:  So could we say a certain smell when you’re using a proxy to try to eliminate multiple product owners is when they constantly defer back to, “Well, I’ve got to go talk to some group of stakeholders or even a single stakeholder. I don’t feel that I’ve got the authority to make that decision”?

Drew:  Right, I think that’s definitely a smell when you recognize that the product owner needs to have equal parts authority, time, and knowledge about your project. If he’s got to refer to a bunch of other people, then he’s severely lacking in the authority, which doesn’t place him in an ideal position to be a product owner.

Clayton:  Right. Especially if it’s over every single story. Having to do that, that’s a definite smell.

Derek:  Now, let me maybe posit a slightly different scenario that I’ve seen in a number of companies, and maybe we can talk about what are some ways to handle this.

Maybe I’ve got a development team of five or six developers, and our company has eight different products. They’re all fairly mature products. So the six developers are responsible for all eight products. But each one of those products has a different product manager.

It doesn’t make a whole lot of sense to…Each product manager is willing to take responsibility and be a product owner for their product. But how would you go about dealing with creating a unified backlog so to speak between eight products where you didn’t have to interface with all eight product owners? What are some ways you could go around that?

Clayton:  I think, in general, when you have a bunch of product owners and you want to delegate the responsibility of the product owner and bring it down into one person, it’s generally easier to go up because responsibilities tend to converge when you go up, and also authority tends to be higher when you go up and sometimes knowledge as well.

In that example, we have a bunch of different project managers. I would say, “Who’s the person in charge of all of them?” Is there a C level officer who can be the product owner? Although, a lot of times an issue you run into in that situation is that that person doesn’t have the time to prioritize the backlog and do the other responsibilities.

Derek:  Say that there was a product manager that was over all eight products. Then there was a product owner defined for each one of the particular products or a project manager or whatever you want to call it.

If that product manager was willing to say, “I’ll prioritize the queue for you. I’ll make sure that I’ll be responsible for the queue.” They’re probably still not the best person to probably be in the planning meeting because they don’t know all the specifics about the stories.

I guess what I’m saying is how would you go about a situation where you had multiple subject matter experts or product owners? Even if you didn’t have an issue of prioritization but you had one of specialization, what would be some potential recommendations that you could do to combat that?

Roy:  To me, the prioritization in that scenario sounds like the biggest problem, but if we are saying that the prioritization thing is taken care of by the overall, overarching project…