Anti-patterns of a product owner — and how to avoid them

The software industry has invented an impressive array of job titles as a tactic to adapt to a rapidly changing landscape and the latest methodology trends. Product manager is one software role that’s been around the longest. 

However, it is also one of the least understood roles thanks to the various ways it’s applied in Agile frameworks. Scrum is one of the most popular Agile frameworks and is the framework of choice for Signifyd. Within Scrum the product manager is known as a product owner (PO). When such a pivotal role is poorly understood and applied, it almost always leads to a product’s failure. It is often an easily preventable failure by avoiding common bad practices but every PO shouldn’t have to experience them first hand before they know to avoid them again.

What is a product owner?

The PO role has seen a surge in adoption in recent years — especially in the UK, thanks to the mainstream adoption of Scrum.

Each industry and company has various interpretations of the PO role. To ensure we are all on the same page, I’m sharing a definition of the role within the Scrum framework. The product owner is the voice of the customer, represents the internal stakeholders and is responsible for delivering the highest possible value to the business. 

The role carries a range of responsibilities between the two main internal stakeholders:

This wide-ranging array of responsibilities illustrates the complexity of the PO role. It’s easy to understand how multiple interpretations can arise.

The dreaded anti-patterns

The PO role is commonly poorly applied. Rarely done intentionally, the problem starts from a lack of understanding of the PO role itself, or in Scrum or Agile. This sets everyone up for failure: the individual, the team and the company.

This can lead to anti-patterns: common responses to recurring problems that are ineffective and counterproductive. Most people working in software engineering have encountered their own anti-patterns. I’m sharing a list of those I love to hate. However, rather than just rant about them, I will also provide some suggestions for addressing each one.

Anti-pattern No. 1: Serving multiple teams

This is a common issue when organizations scale quickly without the resources to match their growth. The PO can sometimes be a victim of their own success when they’re asked to rescue multiple struggling teams.

Problem

• The PO’s availability is stretched with reduced effectiveness.
• The PO becomes a bottleneck for decision making.
• Product ownership does not scale the same way as servant leadership (also known as scrum masters) potentially can, which can lead to inflated expectations.

Solution

• The PO should limit themselves to a maximum of two teams or risk major performance reduction.
• The PO should monitor their availability across their teams and address any issues early on to avoid negatively impacting their teams.

Anti-pattern No. 2: Multiple POs in a team

The inverse situation of one PO serving multiple teams is just as bad. A multiple PO set-up can happen when a team or company is transitioning from Scaled Agile Framework (a framework for scaling Agile principles in enterprises) to Scrum where roles and responsibilities differ. It can also occur when splitting the responsibilities across two roles via a product manager (strategic responsibilities) and product owner (tactical responsibilities) combination. The latter happens when an individual may not possess all of the required skill sets or in a surplus of resources.

Problem

• There’s no single source of truth.
• Teams can suffer from too many cooks in the kitchen, resulting in a lack of clear direction.
• Conflicts of interest can lead to delayed decision making, which hampers productivity.

Solution

• Each Scrum team should have a single PO. 
• Multiple stakeholders are fine and often encouraged, but one person needs to be empowered as the decision-maker.

Anti-pattern No. 3: PO is not available or doesn’t have time

A lack of availability with product owners is often caused by other anti-patterns, leading to inefficient and counterproductive behaviors. 

Problem

• An unavailable PO creates a slow feedback loop, which causes a reduction in efficiency, capability and morale.
• In prolonged cases, this can cripple the product and de-motivate a team.

Solution 

• PO’s can’t attend every minute at work — but they should be available on-call if needed.
• Always make time to attend the team’s sprint retrospective. They are the single most important ceremony for improving quality. A ceremony is a type of Scrum or Agile meeting. A retrospective is a meeting where the team reflects on how they’re doing and find ways to improve. 

Anti-pattern No. 4: The proxy PO

When the real PO isn’t available, the responsibility usually falls to a department or team lead — or even worse, it defaults to the most senior person. This highlights a poor understanding of the role and a dangerous assumption that the most senior person is the most qualified.

Problem 

• Proxy PO assignments undermine the original concept of the PO role by removing the need for consultation before decision making.
• This leads to delayed decision-making with slow feedback, causing conflicts with direction and prioritization.
• Distrust and disengagement from the team follows, which is almost impossible to recover from.

Solution

• Choose one and stick with it: Either engage the real PO or fully empower the proxy.
• If this isn’t possible, consider employing specialists for additional support, like business analysts.
• Use experiments to remove delays from decision making. In this context, running experiments is the process of testing a hypothesis using data (e.g. A/B testing) to answer a question rather than relying on decision-making from an unavailable individual, who might use a combination of experience, knowledge and gut feeling.