Recently I was coaching an Agile Release Train where they were struggling with the concept of a Product Owner. The teams were organized with a Scrum Master and a Product Owner each. This organization’s product management team was very resource constrained so one technique employed was the use of “Product Owner Proxies”.

Product Owner Proxies was individuals that take on the Product Owner role when they don’t have the full knowledge and authority of a true Product Owner. This happens when an organization does not have the scale within their product management group to support all teams effectively. When this happens the organization is left with a few options to supply teams with Product Owners.

  1. Hire product specialists / analysts to work within the Product Management organization.

  2. Contract with business / strategy consultancies to bring in the business / product acumen.

  3. Re-provision existing employees from different disciplines.

I’ll go more in depth in these options (and their respective benefits and detractors) in a future post.

My client, for a number of reasons, chose option three.

Whenever you scale an organization it requires significant focus and constant diligence with regards to knowledge transfer. Especially when you are attempting to re-provision employees from one discipline to another. In this specific case, they took engineers (really good ones) and made them product owners.

I observed a few things that happened.

  1. The ‘Product Owners’ did not have a relationship with Product Management.

  2. The ‘Product Owners’ did not fulfill their responsibilities as Product Owner to the team.

  3. The ‘Product Owners’ were still allocated user stories to implement as part of the team.

  4. The ‘Product Owners’ capacity was reduced because they were dubbed ‘Product Owners’.

  5. The ‘Product Owners’ really didn’t know what their responsibilities as Product Owners were to the team.

They were Product Owners ‘in-name only’. They were ‘Poinos’. This was bad. Really bad.

What was the affect on the teams?

  1. The Backlog was not being owned and managed.

  2. Capacity and velocity were reduced with nothing tangible to show for it.

  3. The broader team was unaware of a major issue: they didn’t have any Product Owners.

In affect, these engineers that had been dubbed Product Owners were really acting as technical architects, which isn’t necessarily a bad thing. They were providing a valuable service to the team but they were not acting as Product Owners, even though they were called as such.

The problem with labels is that they often have practical consequences. These architects that were labeled ‘Product Owners’ were inappropriately attending meetings for Product Owners but they were ill-equipped to contribute as Product Owners. They attended these additional meetings almost blindly but they silently questioned the value of their attendance. They were too afraid to voice concern over the inappropriate use of their time because they thought they would get in trouble for not upholding their ‘Product Ownerly’ duties.

As the old saying goes ‘If it ain’t broken, don’t fix it’ but inversely, ‘if it ain’t working, you bloody well do something about it’. Don’t keep on pretending that everything is okay just to check a box and say ‘We’ve got Product Owners’. This is a huge disservice to your team.

ONE. Your teams won’t get what they need from a Product Owner and TWO, the Program or Value Stream leadership won’t be aware of the resourcing issue.

It’s almost like when a tire is flat, instead of changing it to a new tire, you throw on real donut and keep driving. Does it mean you can drive efficiently and safely? No. Quite to the contrary. However, due to your self-deception, the mechanic will never get the memo to replace your tire!

Your teams need a real Product Owner. If the team arbitrarily assigns an engineer to be the Product Owner just to check a checkbox then they are taking the responsibility from the business stakeholders and product management to provide a sufficient resource. I can’t emphasize enough how much of a disservice this is to your teams.