Scrum and many Agile Coaches claim that it is of utmost importance to have one Product Owner who makes all product decisions.
I can agree that this is the simplest thing that can possibly work in a majority of the situations. It is a good starting point and if it can make sense in the context, most of the time it will be a good thing – and frequently a huge improvement over what you had before.
There are many discussions going on around this, and many people are advocating a CPO – Chief Product Owner role. And many people agree that it works fine for a Product Owner to delegate the detailing of some requirements – as long as everyone knows who to talk to and as long as there are constraints on what to do. I agree with this, and I have positive experiences from delegation (but also negative in situations that have been unclear). See for example Roman Pichler’s advice on Scaling the Product Owner. Sometimes I believe that a split into business-facing and team-facing Product Owners is another viable option. And to complicate things even more I believe sometimes Control Models should be used even in an agile setting (when I say complicate I am talking about the methods – not doing the work which is intended to be simplified).
But it is not enough to just have a hierarchy, you need clear ways of working within that hierarchy. And I have also seen another serious issue that is not always connected to scale which does not seem to be discussed. In this post I am outlining a possible solution to both how to set up the CPO / PO hierarchy and to the other issue as described below.
Let’s consider two examples:
- Small company with 40 employees and two products.
- Large corporation with 100 000 employees and hundreds of business supporting applications.
Small company example
Let’s say the CEO is busy with financing the company, setting up offices in new markets etc. In this situation there is no way the CEO can fill the Product Owner role in a good way. So someone else takes on the role Product Owner. Is it realistic that this person should be authorized to make all feature decisions? I would argue absolutely not, but it is equally unrealistic that the CEO should also be Product Owner and make all decisions since he/she will not be together with the team much and probably won’t be knowledgeable about the details of the product and customer requests.
Let’s say for example that the company is entering a new market and customers on that market requires a whole new set of features. Should the Product Owner be the sole decision maker of the priority of those features? That would not make sense. And if the CEO and the Product Owner are of different opinion on the priorities we may have a major issue.
Large corporation example
In this example many business improvements come from improved IT-support of the business processes. Most business processes are supported by a number of integrated applications. Process Managers have the overall responsibility for process improvements in their processes – which normally involves changes in the supporting applications.
In this example one of the Process Managers has initiated a major change program with huge improvements in his process. This process is supported by five different major applications – each with a Product Owner. Each of these applications have hundreds of important feature requests that are unrelated to this process improvement program. Would it make sense for each individual Product Owner to decide the priority of the features related to this change program? Would it make sense for the Process Manager to also be Product Owner for all applications that supports the process?
The flaw in the Product Owner concept
The Product Owner concept is too simplistic as it is today. Which is fine as long as you see it as the simplest thing that could possibly work – and adapt in situations where it will not work. And lot of companies realize this and adapt it to their circumstances. But unfortunately some people are religious in following methods, and a lot of people use methods as a political instrument to gain more power when it suits them.
In my experience the emphasis that is put on having one Product Owner that is authorized to make all Product Backlog decisions can cause major issues and political fighting.
First of all – when possible stick with the one Product Owner as advised by Scrum. When this is feasible it is by far a preferable solution to anything more complex. And aim for it even if it involves changed responsibilities, learning new stuff for the person taking on the role and meets resistance. And fight for it when you can!
But when one Product Owner is not feasible for legitimate reasons, I believe the solution is a combination of CPO’s together with PO’s (in large scale settings), delegation of detailed requirements (when necessary and with some constraints) AND a distinction between strategic and tactical decisions. In some settings I also believe in the
I believe a viable solution is to stick with the one Product Owner on team level – it creates chaos with multiple Product Owners where it is unclear who is deciding what. But the authority of this Product Owner might be restricted to making tactical decisions. The Product Owner must be authorized to make binding decisions in Sprint Planning meetings that won’t be changed later by someone else.
Strategic decisions can be discussed at the appropriate level and taken there (for example in the Management Team, on the Board of Directors or in the Process Management Team).
The key is to keep the strategic discussion at the appropriate level and not let those get bogged down into the details of the Product Backlog. A tool that in my experience supports strategic discussions in a good way is a high level Roadmap. Of course the Product Owner is a key player in this discussion, but might now have the final say. The agreed Roadmap can then be used to create boundaries for the Product Owners Product Backlog priorities, for example be stating that one epic or theme should be implemented before another.
I believe this solution is fairly intuitive and fits with our traditional way of organizing companies. It works both with a hierarchy of Product Owners and with a split into business-facing and team-facing Product Owners.But unfortunately we are sometimes afraid to trust our common sense since Scrum has been so hugely successful – and if Scrum says something then it must be right, right?