Tips for the beginner Product Owner: How many PO? We are the many! How many Product Owners do you need? Basically, this article is about why it is a bad idea trying to counter a dysfunctional situation by adding more people to the job. A phenomenon that I encountered often ...
I am a true believer in agile, lean and yoga. Sometimes a prophet, sometimes a pirat.
Tips for the beginner Product Owner: How many PO?
We are the many! How many Product Owners do you need?
Basically, this article is about why it is a bad idea trying to counter a dysfunctional situation by adding more people to the job.
A phenomenon that I encountered often is that companies tend to hire more Product Owners when their setup with one does not seem to work. Can the reflex to just hire more people when the existing ones are not doing what is expected from them help?
Before we take a deeper look into what can go wrong, let‘s summarize how it should be.The three main qualities of a PO are:
The Product Owner needs authority. When he says something and gives information to the team, that should be valid and hold. If he cannot say anything because either he does not know or is not allowed to make a decision, this is a major dysfunction.
In order for the Product Owner to make a decision, he needs to be knowledgeable. He needs to know about the product and the product domain. He needs to understand his customers for whom he is building the product, so he needs to be in contact with them. Without knowledge, his authority will not hold and he will lose the ability to make decisions.
And finally, he needs to be available for the Team Members and Scrum Master if they have questions. As well as for the stakeholders when they bring new ideas to the table or have concerns. The best PO is of no use if he is not there to answer a question.
All these qualitites enable the PO to optimize the Return on Investment, for which he is responsible. Being responsible also means (apart from the burden) to be able to act or decide on one‘s own without supervision. If you are dissatisfied with the work of your PO, the first thing that you should look into is: Is your PO really empowered and can she ultimately shape the ROI? Does she have the tools, like a clear product vision and business values attached to product backlog items? Is the team stable and is she the only channel from whom the team can pull product backlog items?
Often occurring problems after a transistion to Scrum is that there are still managers that give direct tasks to members of the team, overrule the decision of the PO or do not really allow him to make decisions. Often, the PO is not allowed to talk directly to customers and stakeholders, so someone else becomes the main source for information that the PO depends on. Lastly, another problem is that the PO is not solely a PO but also responsible for a multitude of other tasks, reducing his availibility and focus on the product.
If one of these things is happening, it does not matter how many people are sharing the PO position, it will not get any better.
Normally, one PO can deal with one Team (5-9 developers). Under rare and complex conditions, it might be a good idea to give him a business analyst as an assisstant, but at least as often, a PO might also be able to deal with two teams at once. By adding more POs to the job, you dillute the ideal „one face to the team“. If the Backlog is set up as suggested and the team is following the Scrum rules, this will work out.
So before you decide to add more people to the PO position, think about how it could help and if there are no other dysfunctions that need to be solved if your PO tells you that he is overloaded.
Conditions where it is a good idea to put more POs on the job for one team is when you have a lot of „disruptiveness“ of the business and have to work out different „branches“ of strategy or be prepared for quickly opening opportunities. Another one may be a highly complex outside world with many different stakeholders that you need to care for. When you should do this, keep in mind that you need a shared responsibility for the ROI and a clear distinction who is responsible for what.