Proxy Product Owner (an Anti-Pattern) - Agile Projects with Third Parties

INTRODUCTION

In my previous article, I discussed the prominent anti-patterns and challenges encountered in agile third-party collaborations based on my professional experience.?Among these anti-patterns, one of the most common is the introduction of a so called "Proxy Product Owner," which is intended to ensure control.

This article aims to shed light on the concept of the "Proxy Product Owner" by exploring their identity, the motivations behind such a role, pitfalls coming along with such a role, approaches to eliminating this role or strategies for optimizing collaboration when removing such role is not an option.

It is worth noting that I have not come across projects where this role is explicitly titled as the "Proxy Product Owner". Instead, this role is implicitly recognized as complementary to the "conventional" Product Owner role, encompassing the following supportive roles:

• Client PO,
• Supplier PO,
• Sub PO,
• Interface PO, or
• Deputy PO,?

In some cases, the "Proxy PO" may simply be referred to as the "PO”, while the actual PO is assigned alternative titles such as …?

• Function Owner,?
• Lead Product Owner,?
• (wrongly) Product Manager, or
• (wrongly) Project Lead.

THIS ARTICLE IS STRUCTURED AS FOLLOWS:

# 1 – The Product Owner According to Best Practices

# 2 – Determining a Proxy Product Owner: Signs and Indicators

# 3 – Presumed Motivation behind Proxy Product Ownership

(if TL;DR, start from here????)

# 4 – Pitfalls Associated with Proxy Product Ownership???

# 5 – Eliminating the Proxy Product Owner

# 6 – Coping with a Proxy Product Owner: Making the Best of the Situation

# 1 – The Product Owner According to Best Practices

The role of the Product Owner has been around for quite some time, and it's reasonable to assume that readers are familiar with the classic definition. On one hand, you could argue that most theories converge on the definition of a Product Owner, with minor variations in the details. But on the other hand, when it comes down to it, I'd dare say that many people think they know what a Product Owner does and what their responsibilities are. However, in my own experience, I can count on one hand the number of times I've actually come across "the" Product Owner in practice. It's an interesting paradox worth exploring further.

Let's consider the fact that a Product Owner like by the book doesn't exist, primarily because the nature of our third-party collaboration model doesn't allow for such an ideal setup. Additionally, let's acknowledge that the term "product" might be too sophisticated since development teams often deliver subsets of a larger product, including features, functions, platforms, environments, and more, which could be alternatively referred to as a "solution". Taking these factors into account, I would attempt to distill the definition of a Product Owner into a single sentence, focusing on one core responsibility or, more precisely, accountability:

The Product Owner's primary accountability is to effectively align business requirements of a desired solution with the respective product backlog, ensuring on-time and within-budget development and delivery, while also fostering a sustainable design for future growth and development.

In conversations with clients, I often simplify it to a brief statement:

The Product Owner holds sole accountability for the backlog.

# 2 – Determining a Proxy Product Owner

Based on my previous definition, I would describe the Proxy PO in simplified terms as follows:?

A Proxy Product Owner does not have ownership of the backlog.

The role of a Proxy PO entails undertaking all the demanding and labor-intensive responsibilities typically carried out by a?conventional?PO, except for Backlog ownership.?

In projects involving third parties, it is common to have two types of Proxy PO:

1. Proxy Product Owner on the Client Side: This role arises when the development team is primarily or fully located at the supplier's side, including a?backlog responsible?PO. The "Client Proxy PO" shadows the supplier, monitoring the progress and providing prompt support on the client's side.
2. Proxy Product Owner on the Supplier Side: The "Supplier Proxy PO" usually holds organizational and technical responsibility over the entire team on the supplier's side. This role often involves tasks related to backlog operations, such as refinement, feasibility checks, and risk mitigation. However, it is important to note that the client Product Owner has the ultimate authority over the backlog. The client PO must provide sign-off for backlog items and has the final decision-making power, ensuring that the authority over the backlog fully rests with the client.

Given my perspective, I believe that the role of the "Supplier Proxy PO" entails a higher degree of conflict potential, challenges, and pitfalls compared to the "Client Proxy PO". Moreover, the "Supplier Proxy PO" role is more commonly encountered. Therefore, for the remainder of this discussion, I will exclusively concentrate on addressing the issues from the standpoint of the "Supplier Proxy PO".

# 3 – Presumed Motivation behind Proxy Product Ownership

Let's consider a business context where all parties involved have purely noble intentions when installing a (Supplier) Proxy PO in the project – whether the Proxy PO is appointed by the client as a contractual demand or at the request of the supplier.

The?client's motivation?is typically to outsource managerial duties related to the team?itself to the supplier. The client's PO brings business expertise, serves as the sole source of requirements, and is internally aligned with the delivery dates of requested deliverables. The Proxy PO is responsible for the?team coordination: active participation in all ceremonies, making short-term decisions on backlog level, facilitating the technical transfer from requirements (what) to implementation (how), and coordinating with other entities such as testing, platform, or other stakeholders on the supplier's side.?

On the other hand,?the?supplier′s motivation?is often driven by a desire to enhance control, coordination, and communication. As the supplier takes on the responsibility of delivery, they are determined not to jeopardize their obligation to the customer, therefore the Proxy PO is appointed as a representative of the team, serving as a single point of contact for the customer.?

The Proxy Product Owner is responsible for ensuring the delivery of the Sprint Backlog, while the Product Owner focuses on determining what needs to be delivered by the end of a milestone.

# 4 – Pitfalls Associated with Proxy Product Ownership

The engagement of a Proxy PO can introduce significant challenges, mainly due to the discrepancy between the real scope of the Proxy PO and the expectations of the team members, which have been shaped by their experience with a more traditional PO role. Management often delegates project responsibilities to the Proxy PO, leading to increased workload and responsibilities. Nevertheless, it's crucial to remember that the final authority in decision-making remains with the "actual" PO, typically the client's representative. This arrangement can fuel frustration, especially when the Supplier Proxy PO (in a lower status position) needs to negotiate with the client's PO (holding a higher status). Such a situation may eliminate the benefits of a lean and agile working model, where typically, the team members enjoy an equal status, fostering open discussions on backlog-related matters.

To underscore the significance of these points, let's explore some concrete and measurable examples of prominent pitfalls that arise from the role of a Proxy PO:

1. Communication gaps:?Since the Proxy PO acts as an intermediary between the client and the development team, there is a risk of miscommunication or misinterpretation of requirements. The Proxy PO may not have the same level of understanding or domain knowledge as the client, leading to gaps in conveying the client's needs accurately.
2. Lack of direct client involvement:?With a Proxy PO in place, the direct involvement of the actual client or end-users may be diminished. This can result in a reduced understanding of their specific needs, preferences, and priorities, potentially leading to a product that does not fully meet their expectations.
3. Delayed decision-making:?Decision-making may be slowed down when the Proxy PO needs to consult with the actual client or stakeholders before providing feedback or making decisions. Especially when the only opportunities for alignment come from formal check-ins scheduled at specified intervals.
4. Misalignment with client objectives:?Without direct client involvement, there is a risk of misalignment between the Proxy PO′s decisions and the client's strategic objectives. In various everyday interactions, such as dailies, team chat rooms, or impromptu brainstorming sessions at the whiteboard, numerous misconceptions are effectively addressed and resolved – the opportunity to actively observe the “team thoughts” and make immediate adjustments is therefore often limited.
5. Reduced accountability and ownership:?Since the Proxy PO is not the actual client or end-user representative, there may be a lack of accountability and ownership. As the Proxy PO is merely a "supervisor", their intrinsic motivations?to?think one step ahead?are often limited in practice. There is no incentive to deliver better work, especially since more work ultimately means more work. Therefore, the Proxy PO might not bear the full responsibility for the product's success or failure, potentially impacting their dedication and commitment to delivering the best outcomes.?

The list of pitfalls can probably be expanded further depending on one's experience. In summary, I would like to emphasize once again that the essential aspect is not the "project management problem", which relates to resources and schedules, but rather the "product management problem", which poses the greatest dangers by jeopardizing the product or limiting its full potential.

# 5 – Eliminating the Proxy Product Owner

In a simplified manner, our goal is to remove any intermediaries between the "Backlog Owner" and the developers, fostering an open and ongoing dialogue on eye level. This entails having a single PO who directly interacts with the team. In a nutshell, the PO′s duties in relation to the owned backlog involve creating and prioritizing backlog items based on strategic alignment and value, continuously refining these items, defining clear acceptance criteria for each, communicating backlog content and its importance to the team, reviewing completed items and providing feedback, managing stakeholder expectations to reflect their needs in the backlog, and planning iterations in line with development capabilities. Therefore, I see only two realistic options:

1. Hybrid Setup – Client PO & Supplier Team

In this model, the PO is situated on the client side. All responsibilities/tasks, such as those previously described, rest solely with the Client PO. All project-related tasks and the accompanying people management are then handled by a "Supplier Project Manager" – depending on the size of the project, dedicated to a team, domain, or the entire project.

Depending on the model and scope of responsibilities – for which some "scholars" will chase me with fire – one could hand over the project-related issues to the Supplier Scrum Master, which would likely result in better team dynamics.

In general I see the following benefits:

? Client-Specific Knowledge & Faster Decision-Making:?Our client-side PO brings deep business knowledge, fostering a product closely aligned with business strategy and user needs, while enabling swift decision-making.

? Strong Stakeholder Management & Control:?Our PO can effectively navigate internal politics, ensuring smooth communication and expectation management. Additionally, we retain control and visibility over product direction.

? Harmonious Collaboration & Joint Ownership:?Our setup integrates the "WHAT" and the "HOW", promoting seamless collaboration. The shared ownership drives commitment to product success and cultivates an enriching knowledge exchange.

In general I see the following major risks, we would need to tackle upfront:

??? Lack of Accountability:?In a joint working model, there is a risk that the client may place all the blame on the supplier if the software does not meet expectations, even if the client's PO contributed to the problems.

??? Mitigation:?Document all decisions, and keep clear records of the actions taken by both parties. This will make it easier to determine responsibility if there are issues with the final product.

??? Misaligned Expectations:?The client's PO and the supplier's development team may have different understandings of the project's goals, timelines, and quality standards.

??? Mitigation:?Create a project charter or similar document that clearly lays out these details. Make sure both parties agree to it before work begins. Regularly revisit and update it as needed.

??? Tensions between Client and Supplier Team:?Despite the potential for harmonious collaboration, there may be inevitable tensions due to different working styles, expectations, or communication issues.

??? Mitigation:?Establish clear communication channels and escalation paths. Regular team-building activities can also help in fostering a good working relationship.

2. Full Supplier Setup – Supplier PO & Team

In this model, both the PO and the development team are from the supplier side. The supplier PO takes on all responsibilities, such as making key decisions, and prioritizing work, as well as managing the project and the team. The client might have a "Client Project Liaison" role, responsible for providing domain knowledge, setting strategic direction, and resolving any escalated issues.

The Supplier Scrum Master could handle the project-related issues, fostering better team dynamics since all members share the same organizational culture and processes.

In general I see the following benefits:

??Streamlined Communication:?As all roles are filled by the supplier, communication could be more efficient, without the need for a go-between or translation of concepts and requirements.??

??Clear Accountability:?Responsibility for the delivery and quality of the product rests solely with the supplier, eliminating any potential conflict about roles and responsibilities.

??Supplier Expertise:?The supplier could have a better understanding of the technology and processes, and might be more adept at navigating the complexities of the project.

In general I see the following major risks, we would need to tackle upfront:

??? Lack of Client Involvement:?If the client is not actively involved or engaged, they might feel detached from the development process, which could lead to a final product that doesn't meet their needs.

???Mitigation:?Set clear expectations about the client's role and level of involvement from the start. Regularly share progress and seek feedback to keep the client engaged.

??? Lack of Client-Specific Knowledge:?The supplier's PO might not have a deep understanding of the client's business, customers, or company-specific challenges.

???Mitigation:?Arrange for regular knowledge sharing sessions between the client and supplier. The client could also assign a liaison to provide domain expertise.

???Supplier Overreach:?The supplier might make decisions without adequately considering the client's perspective, or assume a larger scope than intended.

???Mitigation:?Define clear boundaries and decision-making processes from the start. Ensure regular checkpoints and reviews with the client to validate the direction of the project.

# 6 – Coping with a Proxy Product Owner: Making the Best of the Situation

While the benefits of a?Client PO & Supplier Team setup?or a?Full Supplier Setup?are clear, there are circumstances where these options are simply not given. Reasons can encompass everything from company culture to contractual constraints. In such cases, we may need to operate within a Proxy PO setup.

It's not an ideal situation, as previously described, however, by identifying the challenges and preparing proactively, we can leverage this situation to our advantage.

Strategies to maximize the benefits of a Proxy PO setup:

???Clear Roles and Responsibilities:?Define clear roles and responsibilities for the Proxy PO and the Supplier or Client PO. Ensure that decision-making accountability, stakeholder communication, and expectation management are properly distributed.

???To optimize this setup, a helpful strategy could be the implementation of a RASCI matrix, differentiating the tasks of the actual PO from those of the Proxy PO. This matrix could be applied throughout the feature delivery process, aligning with stages such as TO DO, IN REFINEMENT, IN PROGRESS, and so forth. By detailing who is Responsible, Accountable, Supporting, Consulted, and Informed during each stage, we can clearly delineate roles, promote more efficient workflow management and especially set clear boundaries for both parties.

???Communication Is Key:?Establish frequent and clear communication channels between the Proxy PO and the Supplier or Client PO. Regular meetings, shared digital workspaces, and clarity in written communication can ensure synchronicity.?

???Try to establish the project's priority and urgency at the outset, as this will shape the style of communication. In essence, decide whether ad hoc information exchanges are acceptable or if all communication should occur within formal meeting formats.?

???Knowledge Sharing:?Encourage the Proxy PO's active involvement in the Supplier or Client PO's team to understand project nuances and gain domain knowledge. Concurrently, keep the Supplier or Client PO updated on progress and challenges.

???Feedback Loop:?Foster a robust feedback loop. Enable the Proxy PO to share PO feedback with the respective teams, which aids in the timely resolution of issues.

???Document Everything:?Due to the inherent risk of miscommunication or misinterpretation in a Proxy PO setup, ensure that everything—from decisions to action items—is well documented. This aids in progress tracking and dispute resolution.

???Regrettably, this represents one of my primary recommendations. While I acknowledge that it may impede agility and lean, trust-based product development, it serves as a necessary safeguard in our operations. Particularly within the intricate dynamics of the PO - Proxy PO construct, this strategy is essential to prevent the undesirable situation of attributing blame when circumstances become challenging. Align your "documentation responsibility" with the roles and tasks defined in your RASCI matrix. By doing so, you ensure that the person most equipped to document each task or decision is responsible for doing so, without creating redundancy.

Conclusion

As we wrap up, let's remember that true agility isn't just about roles or methodologies—it's about collaboration, flexibility, and consistent improvement. Proxy Product Owners might not be the ideal, but they're sometimes part of the journey, and our focus should be on transforming these challenges into opportunities. Remember, our Agile journey is a marathon, not a sprint, and it's all about delivering value, fostering trust, and aligning with the customer's vision. Let's take this trip together, folks!