Anti-patterns of the Product Owner

Welcome back! In this session, we will focus on Product Owner anti-patterns. There is no doubt that the Product Owner is a critical role in Scrum. Essentially, they are accountable for maximizing the value that the Scrum Team collectively delivers. They straddle both worlds of Development and Business/Stakeholder Management. While there are plenty of tools that we have discussed to help make them more successful, they may be less successful in accomplishing this objective due to a number of anti-patterns. Let's explore some of the common ones that are prevalent today.

What is a Product Owner?

Perhaps you are new to Scrum and are not quite sure what a Product Owner is, let's address that as best we can as quickly as we can. A product owner is responsible for defining and prioritizing the product backlog. They represent the voice of the customer, ensuring that the team delivers value to the end users. The product owner is accountable for the product's success, and they collaborate with the development team to ensure that the product meets the user's needs while maximizing the ROI. Oh they have to manage the economics of the product all along the way (responding to changing requests, changing technology, etc...).

The Importance of Identifying and Addressing Anti-patterns in Product Ownership

To ensure the success of an agile development team, anti-patterns in product management must be identified and addressed. Anti-patterns are basically widespread behaviors that, although they may appear to be the right course of action would eventually prevent the team from providing the customer with value. Anti-patterns will cause inefficiencies, delays, and even project failure if they are not handled. Therefore, it is crucial to spot these patterns early on and deal with them. Usually our ScrumMasters are attuned to these anti-patterns and hopefully have tools to address them.

Some of the more common anti-patterns we will address today are:

  • Prioritization by proxy
  • Oversized product backlog
  • Dominant product owner

Prioritization by Proxy

Prioritization by proxy is an anti-pattern in which someone other than the product owner makes the final decision about which features or tasks should be prioritized. This can happen when managers, team members, or stakeholders make decisions without consulting the product owner and instead based on their own goals or preferences.

This can lead to a lack of focus because different stakeholders or team members may have different priorities, and their choices may not fit with the big picture of the product. Since everyone involved doesn't know how decisions are made, there may also be a lack of transparency. This could lead to confusion and anger, and it could even cause projects to be late or fail.

To avoid prioritization by proxy, it's important to let stakeholders and team members know how important the product owner's role and responsibilities are. The product owner is in charge of prioritizing the backlog and making sure that the team works on the most important features or tasks first. The product owner speaks for the customer and knows a lot about the product's goals and vision.

Prioritization by proxy can be avoided if the product owner and stakeholders work together and talk to each other often. This lets stakeholders give suggestions and feedback to the product owner right away, which the owner can then consider when setting priorities. By involving stakeholders in this way, the team can make sure they are working on the most valuable features or tasks that are in line with the product vision.

Oversized Product Backlog

An oversized product backlog occurs when the product backlog (a list of features and needs for a product) grows too big and becomes challenging to manage. When new items are added without removing or revising the priority of existing ones, the backlog becomes unwieldy.

An excessive product backlog has detrimental effects on team morale and productivity. Team members may feel overwhelmed and lose track of the most crucial tasks when the backlog is too big. Also, the backlog can include duplicate or pointless tasks, which would waste effort and reduce productivity.

Encourage regular backlog refinement sessions where team members analyze and prioritize items together with the Product Owner, ensuring the team participates and share their perspective on the work ahead. Items that are no longer required can be eliminated, and lower priority items can be deprioritized, as well as clarification being added to items. My advice is to limit a Product Owner's backlog to about 100 items.

We think of the backlog as an iceberg with small detailed items at the top and large, ambiguous, and vague items at the bottom. The items at the bottom can be thought of as place-holders. They are large and represent months or years worth of work, but no need to have details on them yet because they haven't moved up in priority. Once they do, we break them down and move them up, allowing new/large items to replace them, thus keeping our list at about 100 items.


"Writing a novel is like driving at night in the fog," said author E. L. Doctorow. You can only see as far as your headlights, but that's enough to get you to your destination."

The same goes for making software. Because the team doesn't need to see everything on the horizon at one time. Our headlights don't light up everything between me and the horizon in our car. They light up the road far enough for me to see and react at the safest speeds for my car.

In a similar way, the iceberg-shaped product backlog works. Teams can see far enough into the future to avoid most problems when they can see what's coming up. The faster a team moves, the further ahead it will need to look in the product backlog.

Dominant Product Owner

A dominant product owner has full control over the product backlog, makes all decisions without input from the team, and manages the development process down to the smallest detail. They could also choose to ignore ideas from the development team and other partners, which would make it harder to work together and talk to each other.

This situation is not the same as prioritization by proxy. The difference between priority by proxy and dominant product owner is how much the product owner is involved. In prioritization by proxy, the product owner isn't involved enough in the process, so stakeholders or other team members have to make decisions for them. This could cause priorities to shift, which would hurt the success of the product in the long run.

On the other hand, the product owner has little room for input from other stakeholders and team members when they are the dominant product owner. This is because they are too involved in the prioritization process and run it themselves (present with their own bias as well). This can stop people from working together and stifle new ideas, which will stop the team from making the best product possible. Agile works best when everyone is involved and everyone works together, "none of us are smarter than all of us together".

Low team morale, less work getting done, and a drop in product quality are all strong negative effects of a dominant product owner. If the team has to redo work because of bad decisions, it can also cause them to miss deadlines and spend more money.

To stop a product owner from taking over, it's important to encourage collaboration and open communication. The product owner should work closely with the development team and make sure that all stakeholders have a say in the prioritization process. I usually implement a monthly meeting with the stakeholders called the Innovation Council. This helps ensure new ideas come into our circle, current trajectories are assessed and changed if needed. It will also help ensure the backlog accurately reflects the needs of all stakeholders. The Product Owner should also be open to criticism and willing to change goals based on new information even if it is counter their own bias. Bias can go both ways, it can help or hurt our decisions.

Conclusion

These three anti-patterns could hinder both teamwork and progressive planning of agility as a whole. But there are ways to deal with these problems, such as telling team members and stakeholders how important the Product Owner's role is, encouraging regular communication, and giving the Product Owner the power to make the final decision on prioritization. The top 3 characteristics of a product owner in my opinion or Authority, Availability, and Domain Knowledge of the Market they are serving (knowledge of the business problems in the market that our product can solve). Ensuring the Product Owner's success is a way to be agile!

Want to learn more?

Come join us at one of our upcoming workshops. We have online or in-person options!

Register

Related Articles

How Great Product Owners Get to Know Their Customers

At a lot of large companies, our customers are so far out of reach that we don’t know anything about them. We don’t have any direct access to customers either, so by the time we get any real information, it’s several layers removed. It’s really common for companies to protect...

Read More

How To Lead Innovation Workshops

As a product owner, it’s important that you’re always leading the team through product innovation ideas or your product can quickly become stale and boring! Without true innovation, your team just builds and builds, but doesn’t get to use their brains creatively, which can stagnant product innovation. In this article...

Read More

Understanding Customer Needs

In the ever-evolving world of product development, understanding what your customers truly want stands as a cornerstone for success. This crucial insight not only shapes innovative products but also ensures they resonate deeply with your target audience. Let's dig a bit deeper on a few of the best practices for...

Read More

Introducing the Top 10 Challenges of Product Delivery

Product Development is an exciting space and the sky is the limit on the products we can choose to develop. Naturally, the market for your product determines its success. You always have to have a great product idea, but then have to have a plan to execute better than your...

Read More

Impact mapping: Business goals to product backlog

Are you struggling with how to create your product backlog? You have a business goal but you are still unsure how to continue? Let me introduce you to impact mapping and why this is beneficial for building a backlog based on your business goals in no time. Impact mapping is...

Read More

Reach-Impact-Confidence-Effort (RICE)

Welcome back (or just welcome) to our series on prioritization techniques. As I work with teams and organizations, I notice a huge component of planning missing in their endeavors; prioritization. I often say that a Product Owner's job is to maximize the amount business value delivered of a Scrum Team...

Read More

Product Owner Certification

Who is a Product Owner? The product owner is a key role in an agile software development project. They are responsible for defining the project vision and bringing that to the scrum team. The product owner creates the product backlog and sets the priority of the backlog items. They focus...

Read More

Story Mapping to Prioritize

As we continue on our series through the end of the year (the one that focuses on prioritization techniques for our Product Teams), we land on Story Mapping in this post. I normally wouldn't think of Story Mapping as a prioritization technique, but in certain situations, I think it's perfect...

Read More

Eisenhower Decision Matrix (The 4D's)

Dwight Eisenhower was one of the greatest military minds and responsible for countless decisions during one of our world's most dire times (WWII). When I was in leadership training at FedEx (many years ago), I was exposed to the 4D's of prioritizing my tasks as a leader (Delegate, Delay, Discard...

Read More

RVCE Prioritization Matrix

For product managers working in Agile/Scrum organizations, featuring and task prioritization is important for effective roadmap planning. Out of all the features you consider, prioritization helps identify the order of importance and drives the delivery of the work that achieves organizational goals. We are continuing our series this year on...

Read More

How Getting to Small Helps Teams Get to Done

I recently visited with Brian Milner over at Mountain Goat Software to discuss some tips you might not be thinking about with Product Backlog Refinement and Team Design. Check it out here!

Read More