Dangerous Proxy Product Owner

Elena Sviridenko
Product Coalition
Published in
4 min readJun 11, 2020

--

In IT outsourcing, software service providers often introduce the role of Proxy Product Owner (PPO) to compensate for the lack of product leadership.

If the product leader on the client side is non-responsive, lingering with decision-making, doesn’t provide direction and priorities, doesn’t do requirements, this causes inefficiencies in the work of the engineering team. It only seems natural to want to help the client to move forward with product development and keep the engineering busy implementing the defined requirements. And so someone from the team (often, Project Manager, Business Analyst, or Architect) takes matters into their hands and backs the client up as a PPO… And the trap snaps shut.

Although having a PPO may enable the engineering to have stable demand management, this role optimizes neither decision-making nor value management of the product. Furthermore, this is one of the quickest ways to derail product development and lead it away from execution on the business objectives. And here is why:

  • PPO doesn’t have access to as many information channels as the product guys on the client side has, which makes it impossible to make well-informed product decisions
  • PPO is not a product management professional and therefore doesn’t possess the knowledge required to make the most of the situation, properly evaluate the strategic risks and get through to the client to reconsider the approach to leading the product
  • PPO can only operate on a purely tactical level. But what is tactic without a strategy? If there is no firm product leadership in the team, no sense of strategic purpose and priorities, no understanding of the desired outcomes for the business, tactical decisions are mostly random moves that push the development forward and keep the engineering busy while don’t get the product any closer to success.

PPO doesn’t have the authority to make any product decisions, like at all. Proxy means no autonomy: every move of theirs must be signed off by the real product guy to ensure the product development stays on track. Introducing a PPO role not only doesn’t improve efficiency but makes inefficiencies even worse by adding another step to the chain of product decision-making.

But we absolutely dislike inefficiencies and hate keeping the development team ‘hungry’. And so we create an artificial decision-making authority for ourselves and fill the product backlog as we see fit, based on the limited knowledge we have. As even if we had access to strategically important information, we couldn’t have leveraged it due to the lack of product management expertise.

Such behavior only masks the real issue of the product leader on the client side not doing their job and ensures they will never get better at it. Really, why should they? They now have a person who will do the work for them and take the blame for every bad thing that happens.

Essentially, it will lead to a point where you will no longer be able to make any decisions because of having flown blind too long. The problem will escalate, and the fact that you’ve informally taken over the product leadership, even tactical, will eventually fire back at you.

On the one hand, ‘proxy’ means no authority, and you think you’re safe thereby indicating you aren’t really responsible for anything. On the other hand, the title also has the words ‘product owner’ that does assume responsibility. This gives freedom of interpretation of responsibilities and accountabilities of the role depending on the context of the situation.

Can you imagine a role of ‘proxy test engineer’? How about ‘proxy project manager’? Just because one can help test the software and, for instance, participate in risk management, doesn’t make them closer to any of those roles, and they don’t call themselves that way. But somehow with product ownership the story goes differently.
It’s totally okay to have people help the product guy on the client side. But they are not ‘proxy’ anything. They are just that — helpers.

Clients often want the product guys to be in the business units, but those people are sometimes unwilling or unable to fulfill the role, while one is too important to be filled weakly. That will inevitably lead to unwanted consequences for the reputation of ours, quality of relationships with the client, and for the fate of the product.

If you are choosing to be a PPO because the ‘real’ PO isn’t getting their job done, just don’t. Instead, look for the ways of establishing a full-fledged product leadership, with clear set of responsibilities. Select the right arguments and pull the right strings so that the client sees the strategic risks of such behavior and the business benefits that a different behavior of the PO brings. It also helps to slice and dice the areas of responsibilities and shed light on the “holes” in competencies that remain uncovered/unserved, alongside the consequences this situation will lead to.

--

--