Business Analyst as Proxy Product Owner in Ukrainian outsource

I’ve been working as a Business Analyst for more than 8 years now. I’ve worked in outsorce, outstaff, and product companies. Each of them had their own way of organizing work on projects. Some used a more Waterfall approach mixed with Agile principles, some just used Kanban without complex configurations, while others employed different Agile frameworks like SAFe, Scrum, Scrum of Scrums, etc. Interestingly, as a Business Analyst, I’ve worked in all of these different setups. How come? As we know, there is no Business Analyst role in Agile. There are only Product Owner, Developers, and Scrum Master. So, who am I?

After some investigation and analysis, I can definitely state: myself, along with many other Business Analysts in Ukrainian outsourcing, often function as Proxy Product Owners.

A Proxy Product Owner lies somewhere between the Product Owner and the Development Team.

For me, this setup is pretty straightforward, as it is used in most outsource/outstaff projects in Ukraine.

According to Scrum theory, the Product Owner is accountable for:

Maximizing the value of the product resulting from the work of the Scrum Team.

Effective Product Backlog management, which includes:

• Developing and explicitly communicating the Product Goal;
• Creating and clearly communicating Product Backlog items;
• Ordering Product Backlog items; and
• Ensuring that the Product Backlog is transparent, visible, and understood.?

(Scrum Guide 2020)

Sometimes, Product Owners are overwhelmed with this work. Most of their time is spent in meetings, communicating with customers or end-users, conducting feedback analysis, and high-level planning. As a result, the Product Owner may not have the capacity to write detailed requirements, manage the backlog, or stay in close contact with Developers, especially if they are in different time zones.

Because of this, many companies use Business Analysts as Proxy Product Owners and delegate some of the Product Owner's responsibilities.

Nevertheless, the Proxy Product Owner role has its limitations:

• Decision-Making Authority: Even though Proxy Product Owners take on a large part of the Product Owner's responsibilities, they cannot make final decisions. This can cause delays if the Product Owner is busy.
• Responsibility for Product Success: Despite many responsibilities being delegated to the Proxy Product Owner, the Product Owner remains accountable for the product's success. They define the product strategy and make key decisions that impact the product’s direction. In this case, the Proxy Product Owner acts more like a facilitator or consultant.
• Lack of Domain Knowledge: Proxy Product Owners (often Business Analysts) may lack domain knowledge, especially in outsourcing or outstaffing contexts. In outsourcing, people often switch to a new project once the previous one is finished, and the next project may be in a completely different domain. So, the Business Analyst in a Proxy Product Owner role faces the challenge of quickly learning the domain to perform their job effectively.

Despite these limitations, this team configuration is the most common in Ukrainian IT, and both the Contractor and Client companies seem satisfied with it. I was surprised to learn that, according to Agile/Scrum best practices, this is not considered an ideal setup, and companies should avoid having a Proxy Product Owner or treat it as a temporary solution while the actual Product Owner is busy. Essentially, the Proxy Product Owner lacks decision-making authority, accountability, vision, and access to the budget. They say that having a Proxy Product Owner leads to miscommunication, longer decision-making processes, and unnecessary interactions between the Development Team and the actual decision-maker.

Yet, this setup has existed for a long time, and it seems like no one is trying to eliminate or change it.

I started to wonder, why? Shouldn’t companies adhere to best practices as much as possible?

I raised this question with an Agile Coach. If I work as a Business Analyst in a Proxy Product Owner role, and it's not considered correct according to best practices, then what should I do?

According to best practices, there should only be a Product Owner, Developers, and a Scrum Master in the Scrum Team. So, Business Analysts could either communicate with management and the client company to take on the full Product Owner role, with all responsibilities and accountabilities, or become part of the Development Team, though in this case, they would have less influence over the backlog, priorities, and communication with stakeholders.

If we’re talking about a standard Western enterprise, organisation or product company, then I completely agree with the best practices. But the IT industry in Eastern Europe, where there are numerous outsourcing and outstaffing companies, this approach may require adjustments.

Disclaimer: The next part is just my personal opinion.

1. For example, let's take the first approach. A Business Analyst in the role of a Proxy Product Owner tries to transition to the full Product Owner role with complete responsibility and accountability. This can be a big challenge for the Business Analyst. In most cases, the client company will not agree to this, and there’s a reason why.

The Product Owner role is strategic, with a significant impact on the company’s income, growth, and success. Outsourcing this role puts the company at great risk. The client company can switch contractors or an employee could leave the contractor company, leaving the client without control over that person’s decisions. Being without a Product Owner and finding a new one can be costly. From the client company's perspective, it is safer to have a person handling Product Ownership tasks on the contractor side while retaining a decision-maker on their side to step in if necessary.

Another reason could be NDA (Non-Disclosure Agreement) constraints. Some companies are not permitted to share specific information with third parties (e.g., contractors). In this case, it would be difficult for the Product Owner to perform their job without access to the proper information.

2. The second scenario, where the Business Analyst is part of the Development Team, is different. In this setup, Business Analysts work closely with the team and gain a deep understanding of the development process and technologies. But this also has limitations. In such a setup, there could be a lack of understanding of the business and strategic view. Access to stakeholders might be restricted, and if the Product Owner is busy, the Business Analyst may be left waiting for answers. In this case, it's challenging for the Business Analyst to work directly with stakeholders due to a lack of power and authority. Full decision-making and prioritization typically remain with the Product Owner. Sometimes, in this scenario, the Business Analyst can end up playing the role of the Product Owner’s secretary or scribe.

Therefore, my personal opinion is that the setup with a Proxy Product Owner is a golden middle for Business Analysts and companies. It ensures interaction with the business, stakeholders and developers. Additionally, the Product Owner can empower the Proxy Product Owner to make decisions in specific areas, allowing them to work more independently and reduce reliance on the Product Owner for decision-making. Business Analysts have strong skills for working with requirements, changes and different systems. They may notice issues that were missed or spot dependencies on other teams. Or use BA techniques to solve different problems and craft solutions. At the same time, customer communication, strategic planning, and decision-making remain with the Product Owner, which helps the client company manage risks and stay in a safe zone.

I believe transparency and openness are the key elements in this setup, fostering trust, respect, and constructive dialogue within the project.

What do you think? Does this make sense in your case? Share your experience!