Why every agile project should think about a Proxy Product Owner

Scrum as a framework is deeply established in project and product management. The roles and responsibilities of the Scrum team, consisting of developers, Scrum Master and Product Owner (PO), are clearly defined. But opinions vary about the value of a Proxy PO: Is it a reasonable sparring partner for the PO? Or a dysfunctional sidekick with no real impact? We shed light on the role, benefits and challenges of a Proxy PO and help you decide when it actually makes sense to assign one.

Better results through agile software development

Scrum is practiced primarily (but by no means exclusively) in agile software development. The method provides a framework of fixed roles and processes, defining the cycle of software development. The ambition is clear: achieve faster results and produce usable software. To do so, the Scrum Guide defines three roles: the Scrum Master, the Product Owner and the developers.

In short,

• the PO is responsible for defining and tracking the outcome and value of the product, as well as prioritizing and communicating the backlog,
• the Scrum Master ensures the introduction of and compliance with the Scrum rules
• and the developers implement the product features specified by the Product Owner.

In summary, these elements build the Scrum team. The surprising thing here: a Proxy PO is not involved.

The role and limits of the Product Owner

The PO is responsible for maximizing the value of the product and represents the product vision. In general this person is located on the side of the commissioning company, while the Scrum Master and development team can also be part of the service provider. In his position, the PO is responsible for communication with the stakeholders and the technical coordination of the development team. One of the most important tasks is the preparation of the product backlog to ensure that it is in a usable state at all times.

In theory, that sounds like a manageable amount of work (spoiler: it’s a hell of a lot of work). On top of that, in an ideal world….

• POs are available 100% of their working hours towards the project.
• POs speak the „language” of the developers.
• it’s not the first development project as a PO and he has experience with software development.
• POs should have appropriate status, reputation and trust within the customer organization - ideally the PO is in charge of the product.

Unfortunately, reality often turns out to be different and the PO provided by the customer is not able to fully serve the role. There are many possible reasons for this:

• POs often don’t have the time to answer urgent questions from the development team and provide feedback.
• POs are competent in the technical field. However, it’s difficult for them to communicate what they want. They have less experience with prioritization and, in the worst case, do not know what is required.
• The title „Product Owner” is often assigned lightly when a project is due - mostly additional to the actual tasks of the person and/or without the option of further training.
• The Product Owner has little organizational support (or believes he or she has none).

The effects caused by a less than ideal PO setup are numerous: time pressure right at the start of the project, additional workload for the development team, as well as unclear responsibilities and a lack of product vision.

Therefore, reality often differs from those ideal conditions. This is why the Scrum Guide explicitly acknowledges this circumstance: The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.

This is where the Proxy PO gets involved.

What is a Proxy PO and how can he be of service

The term „proxy” comes from the Latin term “proximus” and means “the next one”, which already suggests the role of the Proxy PO: A Proxy Product Owner stands between those who make decisions about a product and those who develop the product. He is considered an incomplete version of the Product Owner.

A Proxy PO typically takes care of activities that are normally done by a PO. These include:

• capture the needs of the customer
• creating user stories
• Ddfinition and prioritization of the backlog
• planning the implementation of backlog items (together with the team)
• deciding when to release increments to customers

In short: With the help of the Proxy Product Owner, the Product Owner’s workload can be reduced and the workflow improved. In the best case, the Proxy PO acts as a team with the Product Owner. However, it is important to note that the Proxy PO is not a second PO!

The Proxy PO…

• is not the owner of the product. He neither makes the main decisions about the product nor is he really responsible for its success.
• does not control the product budget.
• does not define the vision or strategy of the product.
• does not have the final decision about the backlog and its items.

Thus, it has to be clear internally (and externally) when to address the „original“ and when to address the proxy, and how long the stand-in will last (short-term or permanent, temporary and situational, or continuous).

Another possible scenario besides a „substitution“ of the PO by the Proxy Product Owner is PO coaching. Here, the Proxy PO provides support in terms of consulting, especially with regard to methodological issues. PO coaching is especially helpful when the Product Owner has enough time for the role, expertise and a clear vision for the product, but too little experience with the tasks of a PO itself.

How to decide if a Proxy PO can support your project

Establishing a Proxy PO in the project can bring significant advantages for agile software development. Product development can be improved in a complex environment, the Proxy PO can contribute his skills, and the PO can expand his skills.

Nevertheless, we recommend that you do not „blindly“ rely on a Proxy PO. Instead, the first priority should always be a joint discussion between the customer and the service provider. The following questions should be covered:

• Which tasks in the area of product ownership must be fulfilled in the process of product development for the project to be successful?
• To what extent can the customer meet these expectations - both in terms of capability and the availability of his PO?
• If gaps are to be expected, it is recommended to define what form of support is to be provided. Here, the Proxy PO can be an answer.
• At the start of the project, roles, responsibilities and expectations should be discussed and documented.
• To ensure that the agreements are being fulfilled as expected, they should be checked regularly during the course of the project.

Our teams highly appreciate this approach in our projects and thus ensure the success of our customers. We are committed to the agile way of working and are happy to put together the right team for your technical challenge.