Skip to content

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


Subscribe to the Newsletter

Stay up to date with the latest news

sidebar-ipad

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:

Company Development Team
Defines and aligns product vision Represents customer
Elicits requirements Manages the backlog of work
Optimizes business value Provides actionable feedback
Oversees release planning Provides domain and business context

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 PO’s lack of availability is often caused by another anti-pattern, which leads 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.

Anti-pattern No. 5: Role confusion

The PO role definition differs per organization. Each individual contributor’s knowledge of Scrum and Agile varies. This makes role confusion one of the most common anti-patterns.

Problem

  • Role confusion leads to mistrust between the Scrum master and PO, as the role and responsibilities are poorly defined.
  • It causes team confusion and can dilute Scrum.
  • The PO role is often confused with a managerial role, which consumes the POs time and results in a lack of product focus.

Solution

  • The Scrum Guide specifies just three roles — read it!
  • Avoid doubling up roles, especially PO and Scrum master. It’s a conflict of interest and counterintuitive. 
  • Leave your ego at the door. No authority comes with the product owner role. You must learn to influence others through strong leadership.

Anti-pattern No. 6: Not participating in the Sprint Retro

This is similar to the availability anti-pattern, but it’s easier to avoid. However, some teams and organizations, and even product owners don’t believe that a PO should participate in the most important team event.

Problem

  • This creates an us (engineering) vs. them (product) thinking, which is harmful and non-sensical for cross-functional Agile teams.
  • The Retrospective is the single most important thing a team can do to improve quality. By not attending, the PO is missing opportunities to improve themselves, the team and the product.

Solution

  • It’s simple: Scrum teams perform Retrospectives. A product owner is in the Scrum team. 

Anti-pattern No. 7: Output-focused versus outcome-focused

POs concerned with providing quality products should strive to prioritize outcome instead. The focus turns to output when a team is under external pressure to deliver, stakeholders have too much influence or when the PO comes from a more traditional project management background. In these situations, the development team is pushed to take on more tasks than it can realistically handle. 

Problem

  • The pursuit of speed of delivery over customer outcomes does not lead to long-term product success. It has an adverse effect instead. 
  • The team focuses on misleading metrics by thinking velocity-first, which leads to a quantity over quality approach.

Solution

  • Go back to Agile basics and focus on addressing customer’s needs with high-quality solutions.

The product owner role is one of the most challenging and demanding Scrum roles. However, most of these anti-patterns are relatively simple to fix and each is an ideal candidate for continuous improvement. Don’t be afraid to challenge your own thinking about bad behaviors that can lead to anti-patterns, and be proactive about coaching your team on how to avoid and stop anti-patterns whenever possible.


Have you encountered any product owner anti-patterns that are missing from this list? Let us know on Twitter or Facebook.

Steve McComb

Steve is a product manager at Signifyd.