Responsibilities of Product Owner (PO)

Before we move on to discuss the role of the Proxy PO, let’s recall what the role of the Product Owner is characterized by and what is the basis for the organization and project.

The daily tasks of the Product Owner are:

• representing a group of stakeholders and clients,
• taking care of a clear vision of a Product Goal,
• creating a product goal implementation plan and responding to changes,
• making the final decision as to the sequence of execution of individual items in the product backlog,
• establishing metrics that will be helpful in controlling the chosen road.

As you can see on the list above, one of the most important responsibilities of the PO is to create a plan. When using Scrum, your project plan is a Product Backlog that contains a list of tasks that need to be performed in order to achieve the assumed Product Goal. It is worth noting that the Product Owner is the only person who manages this list. Of course, they may ask someone to do that or allow other members of the Scrum Team to add items to this list, but anyway they decide the order of tasks.

Product Backlog management is a very important activity in the everyday Product Owner’s job because a well-kept list has a positive effect on building transparency and trust in the team. When the list is in an easily accessible place and at the top of the list are the tasks with the highest priority and already well detailed, then Developers can easily see what tasks will be performed next. Another feature of a well-managed Product Backlog is the so-called “bigger picture” – this list should show a broader view of what will be done later.

It should also be recalled that the Product Owner is the only decision-making person for the development team. According to the Scrum Guide:

Nobody can tell the development team to work with a different set of requirements, and the development team must not take action based on what other people say.

In order for all of the above to take place, it is necessary to ensure that the Product Owner has enough time to devote themselves to these duties and is available to developers in case they have questions about their ongoing or future tasks.

Theory vs reality

The theory is one thing, but it’s more important how it all works in reality. Personally, I have experienced different involvement levels of people in the role of Product Owner. You may be tempted to define a certain pattern that the larger the company is – the smaller the availability of PO may be. 

On one of the websites about Scrum, you can read that “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 make this new role (PO) not so attractive to those business roles, which could be the ideal Product Owners” (more on that can be read on the Scrum.org website). 

This is one of the situations that may arise. Another challenge may be working in other time zones. When the team and the Product Owner are in a different time zone (when the time difference is more than about five hours), there may be a situation where points of contact between them and the development team may be few, which may affect the pace of work.

Let’s imagine that developers start work at 8 AM in their time zone and encounter some ambiguities in the task description or any other complications. They would like to discuss possible solutions with the Product Owner, but they have to wait until the PO comes to work because in their time zone it’s 3 AM. This is a real problem in the organization of work that can destroy even the best plan. Of course, the ideal solution would be for the Product Owner to work in the same time zone, and it would be even better if they were physically in the same place as the team. It is clear that in the current pandemic situation, most of us work remotely, but there is still a more accessible person who works in the same structures rather than someone in another organization.

The question we should now ask is: what can you do to reduce this type of risk? Fortunately, we are not the first to face such difficulties and we can benefit from the experiences of the others.

The solution we can find when introducing the so-called Proxy Product Owner role.

Why do I need the Proxy Product Owner in my project?

In order to explain the role of Proxy Product Owner, let me quote a pretty nice sentence I found when reading about this role:

Proxy Product Owner is the PO representative for a specific team. This means that to some extent he takes over some of the Product Owner’s responsibilities, especially those related to working for the team.

This description tells us pretty much everything about who the Proxy Product Owner really is. A representative of the Product Owner, very often chosen by them to help. To relieve the workload in a specific scope.

What are the Proxy Product Owner’s responsibilities?

• communicating with the people in a project,
• taking decisions about a product and about the people developing it,
• gathering customer needs,
• defining and ordering the product backlog,
• planning how to realize the backlog together with the team,
• deciding when the product increments can be released to the customers.

Regarding the last point on that list, I would be careful with such important decisions.

Please note that the Product Owner is still responsible for the product and its success! Therefore, it should be up to them to decide whether to release the new version to end-users.

Benefits of the Proxy Product Owner

Nevertheless, the introduction of the Proxy Product Owner role has several benefits. The advantages of this approach that can be found in numerous studies are:

• improving communication in the Scrum Team,
• continuous availability of the business context for the team,
• removing the problem of time zones,
• opportunity to build personal relationships,
• positive influence on team motivation,
• a chance to strengthen the perception of the software house as a partner in the eyes of the client.

As you can see, many of these benefits correspond to the risks I mentioned earlier. Having a Product Owner representative close to the project implementation team means that you can quickly answer any questions that appear. It is also very important to spread the business context and remind about the Product Goal.

In addition, a big benefit is reducing the risk resulting from time differences. Having a person with extensive knowledge about the direction of project development and domain knowledge about the client can set the direction of work and not block their progress. In the long term, such a solution may positively affect the team’s motivation and deliver increments of better quality. That may be a huge profit for an executive company, as it can be perceived as a reliable partner in the eyes of the client.

Shortcomings of Proxy Product Owner

Of course, every stick has two ends. There are advantages to this approach, but you should also remember that there are some limitations and risks posed by a Proxy Product Owner. The main shortcomings are listed below.

• Proxy Product Owner is not the owner of the product – they neither take the main decisions about the product nor are truly accountable for its success,
• they don’t control the product budget,
• they define neither the product vision nor its strategy.
• they don’t have the final word over the backlog and its items.

Additionally, you must remember that it is not always possible to introduce such a role in the project.

Often the implementation time is the client’s domain. Learning all its secrets and understanding the processes in the organization, getting to know stakeholders and, more importantly, building trust can be a very long process. Often, clients may also not agree with the introduction of such a role, because they feel fully responsible for the project and do not want to share responsibilities. 

This role can also be seen as a kind of “dead phone” in communication between the Product Owner and the team implementing the product. Therefore, the introduction of the role of the Proxy Product Owner should be considered on many levels. Nevertheless, based on the projects I have participated in so far, I believe that such a role can only benefit the team but also the success of the entire project. It is also important who we appoint as the representative of the Product Owner.

What about the Business Analyst?

Anybody who likes to create and manage documentation – raise your hand, please. 🙋‍♂️ Maybe there is someone who likes to write it, for example by creating User Stories? To do that, you need to add Product Backlog management, answer questions about functionality and potential solutions, analyze stakeholders and manage them in an appropriate way. 

Probably not many of you like it, so finding a willing person to become a representative of the Product Owner can be a real challenge. However, there is a role that has similar responsibilities when working on a project. It’s a Business Analyst.

The scope of Business Analysts duties very often includes:

• gaining knowledge about the client’s domain,
• getting to know the current processes in the client’s organization,
• analyzing the stakeholders,
• getting to know the purpose of the project and the final state you are aiming at,
• describing and managing the requirements,
• verifying and validating requirements with stakeholders.

The Business Analyst focuses on transforming the question “why?” into “how?” by working with the development team or analyzing the competition and the market. 

As the research conducted by the IIBA (International Institute of Business Analysis) organization shows, 35% of analysts working with Agile methodologies already perform tasks related to the role of the Product Owner. A Business Analyst seems to be an ideal candidate to become a Proxy Product Owner.

Summary

From the client’s point of view, it’s good to remember that the introduction of a Proxy Product Owner doesn’t mean that you lose control over the project. The Product Owner still has the decisive opinion on the direction of product development as well as setting priorities.

However, remembered that in the absence of sufficient availability for the team, for various reasons, the emergence of the role of the Product Owner’s representative may significantly improve the pace and smoothness of work. You should not be afraid to use this type of help. Of course, it is worth establishing the terms of cooperation and the scope of duties between the Product Owner and the Proxy Product Owner, but if you have an experienced person selected to be Proxy Product Owner, it shouldn’t be an obstacle.