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.