What is a proxy Product Owner? And who should become the proxy Product Owner? This is one of the most commonly asked question people ask during my Product Owner Certification course.
The Product Owner role is a rather demanding one. However, the Product Owner is not even a full time role in several organizations. People are asked to be Product Owners while doing their regular day jobs. It’s difficult for these people to work closely with the Team. These busy people tend to find Proxy Product Owners to share some of the responsibilities and lessen their workload.
The proxy Product Owner helps the real Product Owner in creating and maintaining requirements, in the form of the Product Backlog. This makes the life of the “real” Product Owner a bit easier. And the team gets to discuss the issues and questions it have with a nominated person. Life becomes easier for everyone, well, almost.
The proxy Product Owner pattern seemingly solves immediate issue of availability and response time. On the other hand it creates several problems, some rather serious ones. Before going into pros and cons of the proxy Product Owner role, it’s important to understand the role of the Product Owner. What is the core responsibility of the Product Owner? Why does this role exist?
The role of the Product Owner is mistakenly limited to creating, writing and managing the Product Backlog, typically in the form of User Stories. The Product Owner attends the Sprint Planning meeting and at the end of the the Sprint returns to attend the Sprint Review meeting to see the work the Team has done during the Sprint.
From the look of things, it’s looks easy to delegate this work. However, managing requirements is one part of the job of the Product Owner. The core responsibility of the Product Owner is to maximize value and return on the investment for the Product.
A proxy Product Owner can only partially help the real Product Owner. However, this pattern does expose the organization to some dangerous and potentially expensive consequences. This article sheds more light on the role of a proxy Product Owner.
Great introduction to the proxy role. Not surprised to hear asking what the point in a proxy owner is a common question on your course – it’s seems antithetical to the point of agile to put an extra communication barrier into the process, but the limitation of time a PO has available to commit to the product in RL often make the proxy necessary – at least in the small orgs I’ve experience in.
I’ve served in the role of proxy PO in several projects. I believe that one of the critical success factors is for the proxy PO to have some real decision-making authority. If he has to run back to the real PO for every decision, he becomes a simple conduit and merely introduces delays and redundancy. The role works well when done properly.
Sure. An empowered proxy PO is hardly a proxy anymore. She’s a PO.
We have a similar arrangement but the product owner proxies to a number of different stakeholders. The problem is that the PO can’t really make big decisions about direction or features but can sign things off.
How can you improve the suituation?
The person who can make decision about the direction and features is the PO. Try to help that person become a PO by offloading some of the work to the Scrum Team, i.e. some Product Backlog work.