As if that were not enough the workload is further increased when Agile itself is successful. Teams which become more productive through Agile methods need to be fed with more requirements.
When the workload is too high it is all too easy to take short cuts: speak to fewer customers or spend less time on analysis. In the short term the effects are hardly noticeable but over time it means development strays from the highest value work.
I recommend a ratio of one product owner to every three to seven developers. When a product is new, fast moving, when users are coming up with lots of ideas for change then one Product Owner to three developers is appropriate. More developers and the Product Owner will spend too long working with developers and not enough time talking to customers and undertaking analysis.
When a product is stable, has an established niche or function and when the development team know the product one Product Owner may serve up to seven developers. In such cases the requests are normally more measured, much work has gone before and developers don’t need so much guidance.
Of course, sometimes companies want to go faster than this. They have a new product and they want 10 or 20 developers cutting code! The solution is to divide the Product Owner role.
If the product can sensibly divided into two parts then there should be two Product Owners. As long as the Product Owners work closely together and present a unified roadmap then each may look after one part.
When the product cannot be so divided, or when there are several divisions then the solution is to divide the Product Owner role into strategic and tactical roles.
A single Strategic Product Owner (SPO) focuses on the overall goals and spends more time with customers or users. Several Tactical Product Owners (TPOs) work more closely with the development teams and testers. Naturally there needs to be close communication between all the Product Owners and agreement on roadmaps and goals.
The SPO/TPO divide can also help when there is an obvious Product Owner but they do not have the time – or will – to spend with developers. In such cases this person becomes the SPO and one or more TPOs are responsible for translating the vision to developer goals.
Legitimacy and authority
The Product Owner role changes depending on the type of organization, product and team. One size does not fit all.
The key requirement for a Product Owner is that they have legitimacy in the organization to ask questions and the authority to make decisions. What development teams need is a single voice who can say “This iteration we are doing X” and for that decision to stick.
Problems arise when the Product Owner lacks legitimacy or authority and after the start of the iteration starts someone else tries to impose their will.
The other problem faced by Product Owners is overwork. When done well the Product Owner reduces the amount of work going to the development teams and increases productivity. When the role is overloaded short cuts are taken, work is not well understood and priorities are not properly assessed.
The product owner performs their job behind the scenes talking to customers and learning what needs to be done to keep pointing the delivery team towards the audience and their needs. Knowing what the customer wants and showing the team the priorities for delivering it to them is a make-or-break role and with a good PO doing their job, the delivery team can shine and deliver massive