Absolutely nothing! That would be a fitting first sentence for this blog post. But if this is the case why are we (myself included) still around? Here are some reasons that make the Product Owner role an absolute “must” in some organisations and some ideas if you are interested in changing that.
Feature granularity
Imagine that your team is involved in developing a feature, some capability that will move the business value needle. This feature can only be completed if multiple teams deliver their part of functionality. Understanding, defining and coordinating how the bits and parts of each functionality will fit together as they are being developed, is usually the task of the respective Product Owners. The bigger the complexity of each feature, the bigger the task on the Product Owner side. Looking into Value Stream Mapping and Team Topologies could simplify things, resulting in reduced workload.
Developer product chops
I have been privileged to work with developers that were equally skilled in coding as well as understanding the problem that their code needed to solve. They could easily “translate” user needs to requirements and technical solutions. Nevertheless, there are also many excellent developers that this “translation” doesn’t satisfy or interest them as much. In teams that have mostly the latter type of developers, the Product Owner has the task to invest lots of time in that “translation”. The Continuous Delivery YouTube channel does a great job in “teaching” the foreign language of product to developers (Requirement Specification vs User Stories is a great example).
Unnecessary Bureaucracy
There are all sorts of ways to develop and release software. Some of them come with the mandate to produce a respectable number of artifacts. Think, excessive backlog management (categorise user story vs enhancement vs bug vs …), summary Power Points that will be forgotten five minutes after the presentation is over, requirements documents never to be read and so on. If getting developers interested in the user needs poses a challenge, asking them to produce such artifacts is almost impossible. So, the Product Owner is the lucky one to do it for the team. The Product Operations book has an interesting chapter on defining “just enough process” to reduce the load on such tasks.
Compliance process
In some cases, the Product Owner is accountable that their part of the product complies to the quality standards of the company. Some compliance standards are easy to understand and document on development level, say static security checks so they can be taken over from the the development team. Platform services can also help in this direction of baking-in compliance requirements, removing any need to work on them. Unfortunately, higher level requirements like export control classification, usually need dedicated knowledge to document. This task is not very attractive neither to engineers neither to product people. Unless simplified or automated, the Product Owner takes one for the team.
Product Owners will continue to exist as long as there are tasks that no one else either has the time nor feels responsible or inclined to do them.
If you are trying to move to a Product Operating Model as captured by Transformed where the Product Owner role does not exist, you could invest the time to identify these tasks and then
- eliminate them, e.g. improve team scope with Team Topologies or reduce bureaucracy with the focused recommendations of product operations,
- automate them, e.g. use platform services to automate compliance tasks, or
- delegate them, e.g. educate developers in product needs.
Another way would be to look if there are already teams that do not have the Product Owner role in our organisations and learn from them what were the conditions that lead to that. For example, see how e.g. see how Microsoft retired the SDET role.
In conclusion, I disagree with the “absolutely nothing” statement. I would say that Product Owners are good for maintaining the flow of software delivery in good quality in many teams. But this is the situation today. I can equally see a future where the role is no longer necessary and we, that now have it, moved on to other tasks. And some of the new tasks can be more challenging and fun.
More Questions Than Answers 