The product owner is a crucial role in every Scrum team. They are the interface between stakeholders and the development team. They stay in close contact with customers and listen to their wishes and needs. They organise the product backlog and are single handedly responsible for the prioritisation of work. To achieve all this they have to be strong communicators, be empathic, have great organisational skills and a deep understanding of the industry they are operating in.
Sounds like a lot? Well it is. There’s a reason this role is also described as the single wringable neck. In this article I outline why this role is doomed to fail and how we can do better as a team.
This is the first part of a three part series on collaborative product ownership. It covers the practical downsides of traditional product ownership.
The second part outlines basic concepts and advantages of a collaborative product ownership approach.
In the third part we go through the transformation process from traditional product ownership to collaborative product ownership.
Common issues with the product owner role
Becoming a bottle neck
By definition the product owner is a bottle neck in Scrum:
The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.
This leads to the product owner being the information silo. They receive the needs and wants of many different roles, from customers to internal stakeholders, and have to rehash this information into the product backlog. A lot of information is lost in this process already.
Centralised decision making
A product owner is responsible for formulating customer needs and prioritising them. Even though there are great tools to aid prioritisation one person can always only do so much.
Have you ever heard of the wisdom of the crowd? It’s a phenomenon which is best described with an example: Get 100 people and let them estimate the weight of a cow. Almost all of them will be wrong, many of them horribly so. But the average of all those wild guesses will be insanely accurate. Why on earth would you want to give a single person the authority to make a decision when you can reliably get better results?
The four eye principle is widely used from accounting practices to the cockpit of airplanes that it almost seems malicious to let a single, fallible human make decisions alone.
Communication filter
As a good-willed product owner it is easy to become the windshield for your team and take on all outside requests to keep the team focussed. But while you can think of it as building a bridge to your team you can also think of it as a congested bottleneck. What if the product owner is sick? What if they forgot to write something down? What if they simply misunderstood or misinterpreted a vital piece of information?
There are certainly advantages to having a go-to person for all matters of a product. But there is a high chance this can turn into a filter on the communication channel which distorts or drops information at random and it certainly limits the total amount of information flowing from the customer to the team and backwards.
Jack of all trades, master of none
We have already mentioned many of the necessary skills and responsibilities of a typical product owner: Strong communication and organisational skills. Empathy for the customer as well as the development team. Being a visionary and taking care of a product or team vision.
Swiss army knives don’t come in human shape
But how about actual domain knowledge? It’s crucial. You will both need domain knowledge of the product and industry and some basic technical understanding to form the connection between customers and the development team. However, Swiss army knives don’t come in human shape. Especially for new technologies or emerging industries and product categories no single person can cover all those bases.
From a recruiting perspective it’s already hard to find versatilists, or in other words people with a T-shaped knowledge profile. You’re looking for something even rarer: a knowledge profile like a broken comb: An expert in more than one area and broad and deep knowledge in many other topics. So your options usually boil down to operate completely without a product owner or run with a sub-optimal solution. At best you such a person can fill the biggest gaps and keep the daily business going. At worst this can sink a whole product and development team.
Responsibility overload
None of the issues outlined above necessarily have to be present in every product owner’s day. But many of them are likely to occur at some point in their careers.
Many organisations implicitly recognise the issues encoded in the product owner role and build crutches around it. They add product managers and business analysts to the mix to better understanding the market and competitors and fuel the product vision. They outsource more technical tasks to a lead engineer or requirements engineer.
Unfortunately this is only fixing the symptoms instead of curing the root cause: responsibility overload. Even worse, it might leave the product owner with too little authority and render them essentially an information proxy, passing decisions from higher ups to the development team.
I do think all those roles have an important function in a healthy organisation. But their value does not come from being a secretary for overburdened product owners.
Looking for alternative approaches
Instead of centralising product ownership it can also be done collaboratively. The next part of this series on collaborative product ownership covers the fundamental concepts and advantages of shared product ownership.