Are Product Owners Too Much Overhead?

October 9, 2024

Last week, I published ‘Are Scrum Masters Too Much Overhead?’ with around 500K views on Reddit. Here’s a selection of some of the most upvoted responses:

Ouch! Pretty harsh, right? I want to stress that this is also a reflection of the Agile gold rush that occurred, where the market was flooded with inexperienced Scrum Masters to meet the demand. This demand has since dropped because these inexperienced Scrum Masters could not pull their weight yet.

One might think I have a personal vendetta against the Scrum Master for writing such an article and expressing these thoughts. To prevent these kinds of erroneous assumptions, I thought it would be fair to ask precisely the same question for Product Owners:

Are Product Owners too much overhead?

I believe there are many situations in which Product Owners may be dragging you down and preventing you from fixing the actual problems you’re facing.

Let’s get cracking: here are three situations where you should reconsider the effectiveness of your Product Owners and the value they bring to the table.

1. Product Owners and Product Managers Working Together

The Product Manager and Product Owner combo is almost like an enterprise version of Batman and Robin: a favored duo among larger companies. Despite its prevalence among bigger companies, is it really such a good idea?

In my experience, having Product managers and Product Owners is a clear anti-pattern you should investigate. There are quite a few reasons why companies opt for the PM/PO split:

Complex domain. The domain in which they are working is pretty complex, and finding someone who understands the domain well and understands Product Management is difficult.

The team is super demanding. The Product Owner spends all their time feeding the team and has no time to talk to customers. To solve this, the PM is introduced, who relays information to the PO.

The team wants to speak in technical terms, not to the business. To make this possible, the PO is introduced as an interpreter.

You’re doing SAFe. To keep those release trains running, you need PMs and POs.

I want to stress, these different reasons may all be happening at the same time and the list is not even exhaustive.

In short, the fact you need to split responsibilities across a Product Manager and Product Owner is a symptom of something else. And when you’re unwilling or incapable of fixing that something else, you sweep the problem under the rug by having both Product Managers and Product Owners working in conjunction.

Having the PM/PO-duo may alleviate some symptoms, but it won’t fix the actual problem.

Is your domain complex? A Product Manager or a Product Owner with product management expertise can figure out how to interact and collaborate with stakeholders who possess the necessary expertise in your domain to be successful. Adding another layer introduces unnecessary complexity and noise.

Is your team demanding and requires lots of hand-holding? Then that’s the problem you should fix. Working towards empowered teams isn’t easy, but disempowering them by hiring a ticket babysitter sets you up for failure in the long run.

Is your team unable to speak in ways the business can understand, or do they not even understand the business? If you want to create products that are viable, usable, and feasible, then your empowered team should be able to understand each other’s world to some extent. Don’t outsource that understanding by adding another layer that will create unnecessary noise.

Are you doing SAFe? That probably means you’re spending more time discussing the work than doing the work. Maybe that’s your comfort zone, but if you want to have empowered teams instead of disempowered release trains, it’s time to get out of your couch potato comfort zone.

2. One Product Owner For Each Team

If you have one Product Owner for every team, then you can be pretty confident of two things:

Either all your Product Owners are bored out of their minds.

You have many problems that require lots of Product Owner hand-holding.

Either way, you’ve got something you should investigate. Usually, a Product Owner should be able to handle more than one team, but this depends on the circumstances. According to the Scrum Guide, it doesn’t depend on the circumstances: there is ONLY one Product Owner per product.

It could be you’re in a real stakeholder-heavy environment, where the stakeholders suck up all the time of the Product Owner. Another valid reason could be that the team wants to endlessly discuss work during refinement over and over again.

Those are all symptoms of something else. Having a Product Owner per team is a temporary fix, it’s much more sensible to try and resolve the real problem.

3. Product Owner For a Component Team

As the name suggests, a Product Owner is supposed to own a product. A technical component isn’t a product. I’ve seen many cases where companies have a Product Owner who is responsible for a technical product, usually with poor results.

The challenge with component teams is that usually, other things and considerations are leading, and they must follow what’s leading. Then you add a Product Owner who often attempts to create the illusion that they’re leading a product team, and it results in nothing but frustration.

In this case, you don’t need a separate Product Owner, as the team is not building a product.

You Don’t Need Product Owners, You Need Product Managers

In short, there are more than enough cases where Product Owners don’t add all that much value.

Imagine you have a Product Manager, and you decide to add a separate Product Owner to the mix to solve a problem you’re facing. Now you likely have three problems:

You didn’t fix your original problem

You’re disempowering the Product Manager to discover viable, usable and feasible solutions together with the team.

You’re disempowering the Product Owner from talking to customers and understanding the market.

Product Managers can be Product Owners, but the moment you’re splitting them up, you should ask yourself: are we trying to cover up a symptom of a much bigger problem, or are we fixing an actual problem?

In my experience, you often just cover up problems and do not address the actual issues. You think adding an intelligent person will fix it, but you’re only making fixing the actual problem much harder.

Changing things is hard, but adding more layers is rarely the best solution in the long run. The more complex your organization and the more layers, the more difficult it will be for teams to take ownership of what they’re doing. They’ll be stuck talking to other people to coordinate work, over actually collaborating to produce results with the work.

We suck at removing, but that’s exactly what we should be doing: removing things and reducing layers, to put teams in the pole position to take ownership over the results of their work.

No, not results as the work they promise to deliver, but the results we’re trying to achieve with the work. You will never achieve ownership over results with release trains, big room planning, or having separate Product Managers and Product Owners.

Remember: we want to decrease the distance from teams to the customer and the business as much as possible. You should be skeptical of anything that makes it more difficult for teams to understand how they create customer value and capture business value.

By increasing the distance, you’re increasing the risk that we’ll be chasing paper victory plans over delivering actual results that make a difference for our business.