PO Proxy - the Not Always Silent Helper

• The role of the Product Owner is complex and challenging.

• It has proven useful in our projects to support this role with a PO proxy - either permanently or for a certain induction period.

• Working together, PO and PO proxy can lead the project to success both technically and methodologically.

In the Scrum Guide the world can be so nice and tidy. The best example is the product owner (PO) of an agile development project: they have appropriate training and are always available for the team. Yet the reality is usually somewhat different. Although many POs have business experience and a product vision, they are not very familiar with product development and have many additional tasks or deadlines. The consequences can be fatal for the project. But there is a solution to this problem: a PO proxy.

We at Zühlke have had very positive experiences with this concept and have helped many customers to achieve good results. Basically, we recommend that an experienced engineer or consultant be named as PO proxy. This person acts as an interface between the product owner (PO) and the development team. In this way, we can not only ensure that the Scrum rules are followed and the project is completed on time and on budget; the PO also avoids possible overload and can continue to perform their other tasks within the organisation. 
 

What does the PO actually do?

POs are responsible for the value-maximisation of the product. They develop and advocate the product vision, based on a deep understanding of stakeholder requirements and business processes on the one hand, and on the ability to represent this vision to the outside world on the other. He has an idea of what the finished product could look like; who will use it, when, and for what purpose; how it will interact with existing processes; and most importantly, how it will add value to the company.

To bring the idea to product maturity, a PO must face three challenges:

• the stakeholder management,
• the product management, and
• the management of a development team.
   

Stakeholder Management

A product has many stakeholders, e.g. end users, business departments, QA, IT, legal, marketing, development. Each of these stakeholders has requirements regarding the product. The larger the product and the more distributed the stakeholders, the more diverse the respective requirements are, and the more often they conflict with one another.

In the service of value maximisation, the PO is responsible for collecting and structuring these heterogeneous requirements and deriving from them a product vision which can be supported by everyone. A certain amount of methodological competence is required here, as workshops have to be moderated, conflicts resolved and compromises achieved.

Product Management

Some of a PO's tasks can be thought of as a subset of product management: definition of personas and features, derivation of a development roadmap, and active management of the product scope. This includes writing user stories, maintaining a backlog and prioritising it by business value, and planning releases, among others. This, too, is a demanding sphere of activity that cannot be learned overnight.

Management of a development team

Ultimately, the value of the development team's work must also be maximised, ideally through a methodical approach to daily collaboration. It is crucial that the PO is able to communicate to the developers both what the product vision is and what is actually to be built. He should know the components of the "agile ceremony" and be able to use them productively for himself: Sprint Review, Team Retrospective, in particular the Sprint Planning.

In addition, the PO must also contribute to the formulation of acceptance criteria in user stories - an indispensable component for the acceptance of finished software increments. What's more, the PO also coordinates UX- and design-activities and discusses technical issues with the team: architecture, test automation or DevOps are just a few examples. In most cases POs can rely on the competence of their team in these areas. Nevertheless, they should have enough knowledge to be able to contribute constructively and also to question critically.
 

Where does the PO proxy come into play?

Where does the PO proxy come into play?All these tasks and demands can be quite challenging for a newly named PO. Even if they work full-time on the product, at least at the beginning they need a coach to support them. However, many POs simply do not have enough time: they can dedicate perhaps one or two days a week to the product.

For this reason, Zühlke often suggests that the PO should be provided with a deputy, called a "PO proxy". This is an experienced engineer or consultant, often from the Requirements Engineering or User Experience area. It is a classic consulting task - communication and methodological competence, a structured approach and a lot of initiative are important.
 

What exactly does the PO proxy do?

Together with the Product Owner, the PO proxy forms a team. Two of the main advantages of this type of cooperation are: the Product Owner learns the methods required for the role and at the same time can introduce the PO proxy into the specialist domain. At the same time, the PO role in the person of the deputy is continuously accessible for the development team.

The PO proxy is the PO's sparring partner. Together, they develop and clarify the product vision, so that - if the project situation allows it and the necessary trust has been established - the PO proxy can make certain decisions on behalf of the PO. The prerequisite for this is that the proxy is fully aware of the PO's position and has a good understanding of the vision. Nonetheless, the PO proxy never has product responsibility - this necessarily remains with the PO and thus with the customer.

How does that look?
The purpose of the PO proxy role should be clear to all parties involved, and many projects fall into one of the following two categories: PO coaching or PO deputising.

PO coaching helps in projects where the product owner is technically sound, has sufficient capacity and a clear product vision, but has no experience with PO activities. In this case PO proxies will advise the PO on all methodological issues, with the aim of making themselves redundant over time. At some point their backing will have enabled the PO to fulfil their role on their own.

PO deputising is advisable if the PO designated by the customer cannot fill the role due to time constraints and needs support in their daily work. In this case, the role of the PO proxy is intended to be permanent, and it is essential that the PO proxy understands the product vision as quickly as possible in order to take over the daily PO tasks. Despite the limited availability of the PO, the PO proxy must regularly coordinate with the PO so that product development is always in line with the product vision.

We at Zühlke see the PO proxy role as a sensible and pragmatic addition to the roles proposed by Scrum. It can contribute significantly to the success of the project and fits very well with an important basic principle of agile working methods: namely, to understand the development of complex systems as an ongoing, team-based and highly communicative learning process.