≡ Menu
Pawel Brodzinski on Software Project Management

Why Having Multiple Product Owners Is a Bad Idea


The other day I had a presentation on Kanban in my company and during Q&A session we were going through the case of one of our teams which, among other problems, has to deal with a few people playing concurrently the role of product owner.

It wasn’t much later when I read Johanna Rothman’s post touching the very same subject. Johanna shares some advice how to deal with environment where there are more product owners than teams.

Smaller teams, shorter iterations and smaller stories, which Johanna prescribes, are all means to the same end: avoid having multiple product owners working with a team and with a product.

Having multiple product owners for a single team and/or single product is just a bad idea. Why? I’ll answer with another question: what do product owners (or product managers – I don’t really give a damn about titles) do all the time? At least when they don’t drink coffee? Well, they make decision about their products. This is important but that can be done in “never-never” iteration. This is urgent but that can wait until the weather in Seattle is better. This is a top priority right now but that should be on the top of the Bottom 100 list (if there was such thing anyway).

Basically it is product owner who tells the team what they should work on right now (even if it doesn’t happen in such a direct way).

Now, imagine there are a couple of these priority-setters around. And they differ on most decisions. Anyway if they agreed on everything one would be um… redundant. Which one is the one the team should follow? Now imagine there are three or four of them and they are randomly landing on team meetings throwing their ideas at developers expecting to see working results right after this iteration. Now imagine one of them is C-level exec. Man, that sucks, doesn’t it?

That’s the basic problem when you introduce more than a single person responsible for setting general priorities for a group. When it happens so, you likely need some kind of an arbiter to enforce consensus when decision-makers around can’t find one by themselves. And the guy becomes a kind of Uber Product Owner who does the same job as simple product owner but on a higher level – deciding which product/project gets highest priority at the moment and overriding decisions of plain product owners when necessary.

Another approach which can solve the problem is splitting product and/or team until you can end up with a few pretty independent streams of work and a single priority setter for each stream. This way each group works on their small chunk of work while you keep your finger crossed to avoid having too many integration issues.

Actually both approaches are two different implementations of the same basic concept. There should be a single product owner/product manager per team and per (part of) product. That’s because having multiple product owners is just a bad idea.

in: project management

7 comments… add one

  • Michał Paluchowski May 11, 2010, 8:04 am

    You are very right. When you have multiple product owners you get into a case of “design by committee”, which means plenty of conflicts, few decisions being made and those that are made tend to be mediocre.

    Any task or project should have a single owner – one person responsible for making decisions and having the authority to make final ones when conflicts arise.

  • Pawel Brodzinski May 11, 2010, 8:10 am


    You brought one point I have omitted – it’s not very rare when consensus decisions achieved by multiple trade-offs are suboptimal and they push the product into mediocrity.

    Not that I’m an enemy of consensus, but when it comes to lead, either a product or a team it takes guts to choose bravely but so-called safe options rarely makes a winner. Besides, no risk no fun.

  • jfbauer May 12, 2010, 6:48 am

    Indeed, good points … I recently had a similar experience of multiple product owners. Basically, one was “senior” and one was “junior”. Our Agile team was working with both as product owners. When they both were in the same design meetings, we could all sort out what needed to be delivered when and at what priority level. But when the “senior” one was unavailable, the “junior” one was empowered to speak on his/her behalf. This kept things moving until the “junior” product owner said X only to have the “senior” one come back a day or two later and say Y not X. This lead to confusion and some stop/start re-work.

    To solve this, we had to pressure the “junior” product owner to confirm/double check with the “senior” owner on unclear priorities. Basically, the guilt and embarrassment we created for the “junior” person when they made the wrong call motivated that individual to get his/her story straight prior to development design/prioritization meetings.

  • Pawel Brodzinski May 12, 2010, 8:51 am


    Sounds like you just tried to enforce on “junior” guy to have their decision accepted by the real product owner before moving them into development.

    By the way: I think much fault was on the “senior” person – if they were available when the team needed them there wouldn’t be a problem with wrong product decisions in the first place.

    Anyway I know it is usually a big problem to have the “senior” person at place all the time, but still in these situations I’d say it is a problem of (lack of) delegation.

  • Ronald Voets May 13, 2010, 1:47 pm

    I can only partially agree to the opinion in this blogpost.
    I fully agree on having one product owner per scrum team. As scrum teams get more sprint under their belt, they’ll start to make higher demands to the product owner and their involvement in grooming of the backlog will intensify the cooperation level. Having a single point of contact and decision maker towards the scrum team, is essential.

    Where I have a different opinion, based on my experiences, is to have one product owner per product. Especially in larger software development organizations, one product isn’t handled by one scrum team but several. In my company, there’s close to 10 scrum teams on 1 product. The teams are distributed across multiple locations and partially via outsourced development as well. That product consists of multiple functional areas and the scrum teams are aligned around those areas. We make a distinction between the tactical product owner (liaising with the scrum teams on almost a daily basis) and the strategic product owner. The role of the strategic product owner is one one hand the alignment with the C-execs you refer to and own the product roadmap, on the other hand ensuring overall consistency of the backlog items across the scrum teams.

  • Pawel Brodzinski May 13, 2010, 11:14 pm


    I know where are big products which virtually can’t be led by a single person since they’re just too big. And I agree it a better idea to have a number of product managers there instead of putting everything on one’s back.

    Actually exactly this scenario I had in my mind when I was writing “Another approach which can solve the problem is splitting product and/or team until you can end up with a few pretty independent streams of work and a single priority setter for each stream.” My point here is the same as yours – one product owner/product manager for the part of a product which is covered by a single team.

    I guess I should have focused more on a perspective of a team (one priority setter for a team) but I didn’t want to leave out a scenario where one team deals with a few projects and have different product owner for each of these projects.

    Anyway the approach you describe works well within general boundaries of “a single priority setter for a group and (sub)product” rule.

    The only trick there is to split the workload in a way which limits potential integration to easily understandable interfaces and at the same reduces chances of conflicts between teams and/or respective product owners.

  • Radu Davidescu May 25, 2010, 7:09 am

    My post as an different perspective over the same problem.


Leave a Comment