In this post I will review what's a Proxy Product Owner, why you can find so often this role in organizations embracing Scrum, and some proposals to avoid this role and achieve a true Product Owner.
What is a Proxy Product Owner?
A Proxy Product Owner (Proxy PO) is a middleman role between the people taking decissions about a product and the people developing it. A Proxy PO usually perform activities that are usually done by a Product Owner, such as:
- Gather the customer needs.
- Define and order the Product Backlog.
- Plan how to realize the Backlog together with the team.
- Decide when the product increments can be released to the customers.
However, a Proxy PO is an incomplete version of a Product Owner. This seriously undermines its efectiveness and makes the value-maximizer mission of a PO difficult to achieve. The main shortcommings of a Proxy are typically:
- It is not the owner of the product! So neither takes the main decissions about the product nor is truly accountable for its success.
- Does not control the product's budget.
- Does not define neither the product's vision nor its strategy.
- Does not have the last say over the Backlog and its items.
So, although having a Proxy PO may enable a Development Team to have a stable demand management, this role does not optimize neither decission-taking nor value management of the product, specially in big and complex organizations.
Functional organizations and the Proxy PO
Once upon a time there was an organization grouping employees according to the type of work they did and to their capabilities. This business groups receive several names such as business areas, departments or teams, being the most frequent organizational model. This model is also a heritage of Scientific Management or Taylorism, introduced by Frederick Winslow Taylor in early twentieth century.
A typical business organization divides their workers between the "business" and the "IT" people, subdividing those areas in smaller function-specific groups such as sales/marketing/HR and Dev/Ops/QA respectively. IT traditional roles such as Business Relationship Manager, or Business Partner, prioritize the business demand, and another IT role such as Project Manager leads their realization.
When it comes to embrace Scrum, those organizations without a good understanding of the Product Owner role oftenly identify that role as belonging to the IT department which is set to maintain the communication between the business users and the Development Team. In addition, this role is expected to analyze the backlog items and even define their acceptance criteria. This set of responsibilities fits quite well those of a Project Manager, who also may see himself closer to a Product Owner than to a Developer or Scrum Master. For all this reasons, Proxy PO easily emerge from the IT department.
Furthermore, business people which have the "MAN" (Money, Authority and Need) are usually too busy to also deal with time-consuming activities such as detailed backlog management and requirement definition. That may makes this new role not so attractive to those business roles, which could be the ideal Product Owners. So that, in Scrum adoptions we oftenly have all the ingredients to cook a good Proxy PO recipe.
Proposals to achieve a true Product Owner
First of all, it is essential that organizations those helping them to embrace Scrum understand deeply the Product Owner role. Even more difficult, they should understand the severe organizational redesign this role demands both in the business and the IT areas. IT should not be an "internal IT provider" any longer.
Secondly, it is also important that everybody understands that a true Development Team should be self-sufficient so it may carry out large parts of elaborated backlog management activities, such as refining, item definition and acceptance criteria. This delegation from the Product Owner to the Development Team should be made on the principles of transparency and trust. The Product Owner should remain confident on being informed and responsible for taking the most important decissions about backlog management and item definition.
Thirdly and lastly, finding a good fit for existing project managers within the new organization shouldn't encourage them to be Proxy POs. If they are experts in team management, who else may help a Development Team to be self-managed as another team member, but avoiding the micromanagement and working in another value-adding activities within the Sprint.