The question of using product owners is something that has plagued me for some time. I’ve always thought that there’s something not quite right about the concept and through my experience with this over several years, I have come to try and avoid formalising the product owner role where I can. When I say product owner, I mean it by the term used in scrum (see the scrum guide), as distinct from a product manager.
Some of the key problems I have with it include “The product owner is one person, not a committee”. What I often see is that this becomes (whether rightly or wrongly) a central point for decision making. Often this is a bottleneck and can start to disable flow in uncertain situations. For example, what happens when the decision maker takes leave and goes on holidays for a few weeks? What if this is unexpected medical leave and there’s no handoff? Usually what happens is decision making is greatly reduced or stopped and the organisation suffers from this.
Furthermore, I often consider “what if the PO is wrong” – what happens in this situation? I’m reminded of David Marquet’s work in this area where he encouraged leadership at all levels and decision making was more distributed to where the appropriate amount of information to actually make that decision resided.
Another issue that I have with it is at the adoption stage – in order for scrum to be effective they need experienced product owners. These kinds of people are not necessarily grown overnight and really need some intrapreneurial tendencies. It can often take several years to grow a good product owner. With many organisations, I often see people granted the “Product owner” role, but they don’t have any, or very little, understanding of what this is and how to make it a success. Often organisations pour a lot of time and money into this, which although it may payoff in the future, you are likely to have better spent that money improving the products and services for customers and getting them out to market more rapidly.
Another problem I have seen is the “part-time” product owner. If they are chosen from the business they’re often given these duties in addition to their “day-job”. Teams rarely get enough time to discuss things with the product owner and often their absent for most of the time. Teams flounder like a rudderless ship in a storm. In order for new product owners to learn they need to immerse themselves in their product initiative and take some of their day job tasks away. There is a balance here, because you want them to continually be in contact with the broader aspects of the business, but their focus needs to be correct.
I guess another thing to consider is whether to bring in outside help. In which case you have to deal with the fact that the folks coming in likely know how to be a product owner, but don’t understand your business. It will take them some time, perhaps a year in larger companies, to form relationships in your organisation and be able to understand the inner workings of your product or business. There’s an up front investment here and you have to wonder if the pay off will justify the outlay.
In larger organisations, particularly when you look at organisations that adopt SAFe or other like scaling frameworks, you tend to find that the product owner at the team level does not really resemble what scrum had intended for this role. Essentially, there’s little decision making at this level as things are usually sliced at a higher level. I’ve found that often in this context you’re better off making sure you’ve got a good Agile BA who understands the domain and can detail the work coming into the system who can work collaboratively with stakeholders around prioritisation.
Additionally, the statement “For the Product Owner to succeed, the entire organization must respect his or her decisions” is often hard to achieve. Many organisations appoint puppet product owners with no real authority, or what authority they have is often overridden.
Another point about the product owner is they often become a proxy sitting between the team and the customer(s). Although POs are intended to be this, which can work in some circumstances, it’s still good for the team to get out and interact with users and customers. Again, the PO is a single point of failure and only applies their own single lens to information coming through the system. Having different perspectives for customer / user / stakeholder interaction can provide a richer feedback loop and allow you to pick up on nuances and opportunities you would otherwise miss. I recall the XP framework being big on ensuring the team are talking to the customers / users. I think this is important and often a product owner, especially if they’re learning the role, may get in the way of this.
Are product owners a broken concept? In view of their implementation is often very problematic, enough for me to question the benefit of and avoiding their introduction wherever possible. I’m not saying the “committee” is the right option either – I really think you need to consider other options. If you haven’t introduced them, it might be worthwhile considering first ensuring your decision making policies are explicit and pushed down to the appropriate level in the organisation. See how distributed decision making can work and enhance you overall organisational agility before centralising it and introducing a product owner concept.