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!