5 Reasons Why a Product Owner Team Might Be a Good Idea


Minuten Lesezeit

Sei dabei und sichere Dir bis zum 31.05.2024 Dein Early-Bird Ticket!

Oktober 13, 2011

Hol Dir hier das kostenlose Probekapitel meines Buchs

Klicke einfach auf den folgenden Link und melde Dich an.

During this week I read an interesting article called „Is Scrum a –ism that doesn’t work for real?„. One of the things that @marcusoftnet mentioned in his article was this:

The product owner is an unicorn

I continue to read and had to agree with him in many points. The rest of the week I kept thinking about this and came to the conclusion that in some environments a product owner team would be a better fit. But what could be a good reason for a product owner team?

1 – Responsibility

One good reason might be a shared responsibility. In some companies it seems to be difficult to define THE one and only PO with all needed responsibilities. Even worse, I saw product owners, whose decisions were overruled by their bosses and managers. This does not only have a demotivating effect on the PO, but also the development team becomes insecure when working with her. When you have a PO team, it is much more difficult to overrule them.

2 – Diversity

Another good reason for the team approach is the diversity you get when you have a team. My ideal PO team consists of a product manager, one person from marketing, one from UX and a techie. That way you have all needed knowledge in the team to create an awesome backlog. I saw a lot of bad POs who were unable to create a good backlog, because he missed some knowledge in an important area e.g the market or technical know how. This will all vanish if you have a PO team.

3 – Availability

Ever heard about ScrumMasters taking over the role of the PO, when he is not available? Bad idea! But it does happen and not only once. This is another good reason for a PO team. Even if one or two members of the team are not available (ill, on vacation), the team is still able to work. No availability issues anymore.

4 – Teamwork

A good backlog is the result of great teamwork. I never saw a backlog that was created by a single person and still was in a good shape. I know that there are no rules that the PO should be the only person to create new items in a backlog, but many teams think so. A PO team forces them to work together. Of course they still have to work tightly with the development team, do backlog grooming sessions or even ask a developer to help to maintain the backlog. A PO team will help to foster the collaboration in a team.

5 – Fun

Last but not least, working in a team is much more fun. I know this should be also the case if you have a single PO, but I never saw a PO that sat in the same office or even floor than the development team. I even saw POs that were not only sitting in the same office but at a completely different location. With a PO team you force them to work at the same location and I swear it is much more fun to work this way.

What do you think? What are your experiences with POs? Do you also think that the role of the PO is a unicorn? I’m looking forward to your comments.


Thanks to @maritzavdh here are some links for further reading:

About the author 

Marc Löffler

Marc Löffler ist Keynote-Speaker, Autor und Mentor für passionierte Scrum Master. Er befasst sich schon seit 2005 leidenschaftlich mit agilen Methoden, wie z.B. Scrum, Kanban oder eXtreme Programming. Bevor er mit dem Thema Agilität in Berührung gekommen war, hat er als zertifizierter Projektmanager (IPMA) bei Firmen wie Volkswagen, Siemens und EADS erfolgreich multinationale Projekte geleitet. Mit Begeisterung hilft er Unternehmen dabei, agile Werte zu verstehen und genau die Form von Agilität zu finden, die zum jeweiligen Unternehmen passt. Dabei nutzt er sein PASSION Modell, um die jeweilige Situation zu analysieren und sinnvolle nächste Schritte hin zur passionierten, agilen Organisation zu definieren. Er liebt es, neue Einsichten zu generieren, und unterstützt Unternehmen dabei, Probleme aus kreativen, neuen Blickwinkeln zu betrachten. Seit September 2018 ist er zertifizierter Professional Speaker GSA (SHB) mit der besten Keynote seines Jahrgangs. Im Jahr 2014 erschien sein Buch „Retrospektiven in der Praxis“ beim dpunkt.verlag. Im Jahr 2018 folgte das Buch „Improving Agile Retrospectives“ bei Addison Wesley. Im Februar 2022 folgte dann das Buch "Die Scrum Master Journey" beim BusinessVillage Verlag.

Leave a Reply

Your email address will not be published. Required fields are marked

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

  1. Marc,

    Interesting thoughts!

    We don’t use formal “Product Owner Teams,” but we incorporate many of the elements you discuss. We have dedicated Product Owners that sit with the teams and they are the voice of the customer – and stakeholders – to the team. And while a PO acts as the voice, Product Owners act collaboratively with customers (either directly or through proxies, such as Program Managers/Account Managers who are dealing with a specific customer) and stakeholders (typically the management team) to set priorities.

    Ultimately, the Product Owner needs to create and own the actual backlog, doing so with inputs from outside the team and leveraging technical resources within the team. In practice, I feel that this should be a very collaborative process.

    The Product Owner role can be very demanding, and like a lot of things, you need to evaluate the needs of each specific situation. We have some products that are established in the market and can be more easily managed than other, newer products. It is very easy to overload a Product Owner, and the “classic” PO role doesn’t account for the large amount of time that can be required in dealing with the externally-facing aspects of the role in many situations.

    Given that requirements and priorities are critical to the business and essential to delivering valuable software, stakeholders should be paying attention to this and supporting the team and the PO and not overloading/overworking someone. Scrum is a framework, and it shouldn’t be implemented as a one-size-fits-all process. Misused, a PO can be a unicorn, but if the role is applied correctly with support from the organization, it fulfils a critical role in the software development process.

    1. Hi Dave

      Thanks for your comment. I fully agree with your last sentence, but I also believe that the PO team may be the better concept. I think that way, because I saw it way to often that the PO role was screwed.

      – marc

  2. Hi Marc,

    some thoughts about that:

    1 – Responsibility
    From my point of view you would only obfuscate that you have a problem with the relation between management and product owners if you install a PO team for the sake of not beeing overruled that simple. If it happens regularly one should rather invest in resarch for the reason than fighting the symptoms. Does your company really want to do Agile/Scrum? Is it a personal thing? Lack of trust? Can you resolve it – or should you move on?

    2 – Diversity
    Basically you should have all these skills in your development team when you need them. So why don’t involve the team or at least some of them in creating the backlog and doing product discovery?

    3 – Availability
    If your PO is constantly not available you have a fundamental problem. If he is not able to do his job in a good way you should fight the cause. If he is ill/on vacation it looks like a good idea at first glance, but to follow this team-idea only for that reason? Not sure. Alternatively there should be a way to handover your work on beforehand in most cases. The best may be to stay in touch closely with your colleagues and keep them informed.

    4 – Teamwork
    You’re right – no one says the PO is the only one who should create the backlog items. Honestly I don’t understand where you see the that a PO team fosters collaboration on the backlog besides the responsibility aspect from 1).

    5 – Fun
    That’s a good point. But why do you have to have fun in a PO team – and not with your developers (and ScrumMasters as well)? Finally as PO you are not more or less than a developer. Everybody is in the boat, responsibly for the succes, doing his work in the best way. So you all should have fun together (or get hung together) 🙂

    Finally from my experience there is a large risk of running into more confusion and friction when you don’t have the one face responsible for the question of „what to do“. I worked with teams with multiple POs – and there was constantly uncertainity about who to ask about what and who may decide what and so on. In fact it worked out much better if only on PO where available for a longer time because of vacation or illness 🙂

    Just my 2 cents.

  3. By having a Product Owner, that is surely introducing weakness – the strength from a Agile team comes from the continuous interaction between people in the various Agile roles. Having a team strikes me as more management required – i.e. management of the PO team – which is full-time job. Product Owner’s are part of the Agile team. if they aren’t then that is a problem. And one that won’t be resolved by throwing more people into the mix.

    If the Product Owner cannot be available, then how seriously is the stakeholder taking their project? Scrummaster’s can end up taking over PO role to some extent, if PO is either absent, and is simply weak in the role. The Product Owner may be taking advice and input from other departments, but they should be the sole representative on the project. And committed!

  4. Sorry, mate… I disagree, whole-heartedly.
    You miss the most important point:
    Authority. The PO must be authorised to have the final decision to maximise the ROI of her project. I agree that could work with a team, yet most organisations don’t delegate authority this way.
    1—Responsibility is hard to share for this reason.
    2—POs should work with teams, using the diversity of developers, testers, stakeholders to create the most valuable product. Diversity is key, but that does not require multiple POs.
    3—If you want the PO to create the best value with the team, create an environment where she is available. She needs to make decisions…
    4&5—Fully agree on teamwork and fun: POs need teams. The other team members need not be POs though.
    To put this into perspective: for a bigger product development endeavour with multiple teams, you should have a team of POs—ideally, one per team. IMO these need to have a senior PO to make the final decision, who has the authority from management and the ultimate responsibility for the product’s ROI.

    I don’t think POs are unicorns btw. Yet good POs are hard to find. But I don’t believe developing great products is easy. And it shouldn’t be because it would be much less fun were it less hard:-)

    Thank for the post, it highlights most of the important issues in the environment of a good PO!

    Take care

  5. Olaf has hit on the core of my argument against a team of peer Product Owners. I’m currently a PO in such a team that was established for almost exactly the reasons you cite.

    On paper, it sounds like a great idea. But in practise, the functioning of the PO team quickly turned dysfunctional because instead of being more empowered, they were less empowered. Even worse than managers overruling the PO, is when fellow POs start overruling each other! And when POs can’t make an effective decision because they’re constantly having to get buy-in from N other POs, the wheels start coming off very quickly.

    My preference, having had this experience, would be for the PO Team model that Mike Cottmeyer suggests. In this model, you have a single, accountable PO working with team members in the SCrum team to elaborate requirements and write stories. This addresses the availability and engagement concerns, provides the depth of skills needed to write customer stories and has the further advantage of distributing knowledge and learning in the team, rather than having it reside within the PO team.

    Incidentally, I recently spoke at the Cape Town Scrum Gathering about the team dynamics of 3 types of PO teams, using spider charts to map the personal dynamics. The peer PO team came out of the exercise scoring very poorly on number of personal productivity axes, including Responsibility, Accountability and Achievement, and very high on Role Confusion.

    The slides are below, with a blog post about the results still forthcoming.


  6. Interesting post.

    I have been facilitating Agile Finland coaching circle and we’ve had controversial discussions about this topic. According our (the group) experiences the single product owner model does not work. I hope we’d have possibility to describe the cases we talked about in a blogpost or such to share the experiences.

  7. Wow, thanks for the awesome comments! Maybe instead of describing what might be good reasons for a PO team I should have started with what is my understanding of such a team. Of course the PO team shouldn’t be a commitee. You still need one person who leads the the team. Some people call it the „Single Wringable Neck“.

    @ReneMT: I have to rephrase my sentence „A GOOD PO is a unicorn“. I still believe a team with a product manager, marketing guy, UX person and a techie is the better solution in most cases. In this setup I would appoint the PM as lead of the team.

    @Paul: I don’t believe that you need more management, when you have a PO team. That’s the task of the PO team lead.

    @Olaf: I think with introducing a PO team lead your objections are mostly solved 😉

    @Maritza: I totally agree. If you have a PO commitee you will get into troubles with responsibilities.

    @Marko: I had the same experience. I never saw the single product owner model work. I’m looking forward to your blog post.

  8. I believe that a Product Owner functionality can, to some extent, be had with an Enterprise Transition Community (E.T.C.) where one or all members of such a group might participate in sponsorship of Improvement Communities (I.C.) as they tackle items from the E.T.C. Improvement backlog as part of a complete enterprise wide Agile transition that seeks to keep Agile gains from retrenching after initial successes. It would seem though that this would work only because there might be less demand on the Product Owner role in this situation.

  9. Hi Marc,

    I have to agree with Olaf. I don’t think there should or can be a team of many PO, but one responsible PO with a team helping her getting a better idea of his vision.

    Actually your suggestion to have a PO Team lead is not far from how we do it. Every PO has a team consisting of UI, UX and a Developer(in most cases the dev team lead). This teams works on ideas including customer tests, before things can be pulled by the dev team.
    They all work on the future product backlog items, but the PO is the one having the product vision and the last decision what makes it into the product.

  10. I must agree with Olaf Lewitz. I understand your points and do think its important that the productowner has a team around him that consists of all the nescessary stakeholders. For both the team and the company it’s important that they can rely on the person in charge.

    Very good discussion, go’s to show the product owner role is probably the most difficult role in scrum

  11. >> Last but not least, working in a team is much more fun.

    Uh ?
    Needed yes. Great for the company, absolutely yes.

    But let’s not pretend that it’s fun for the individual; it lowers sense of accomplishment as the result is not something you accomplished yourself, but – meh – with others.

  12. Hmm it looks like your site ate my first comment (it was extremely long) so I guess
    I’ll just sum it up what I wrote and say, I’m thoroughly enjoying your blog.
    I too am an aspiring blog blogger but I’m still new to the whole thing. Do you have any tips and hints for novice blog writers? I’d really appreciate it.

  13. i’d love to take you nay-sayers on a little thought experiment:

    image you guys are put twenty years into the past (before the times of wide-spread XP-Practices, collective Code-Ownership,….) – kind of in the middle of the medieval IT-Days.

    What if some consultant had told you to have a team of developers take responsibility for their code, maybe even to test that code themselves and not have a developer-teamlead that hast „the final say“ in coding decisions. what if that guy told you, that architects should be hands-on developers learning the latest stuff from younger colleagues (that have less experience in that particular field)..

    you would probably say, that there needs to be ONE developer that is responsible for hard decisions, that a team could never do what is needed to be done and that there always has to be a single wringable neck (especially for management?)

    now come back to today and think about your answers 😉

    maybe we are not as far away from medieval times as we want to think we are.
    happy new year

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Hol Dir die kostenlose Anleitung für
Deine persönliche