Antipatterns in Product Ownership

What is an antipattern?

Antipatterns are common solutions to common problems where the solution is ineffective and may result in undesired consequences. An antipattern is different from bad practice when:
It is a common practice that initially looks like an appropriate solution by ends up having bad consequences that outweigh any benefits
There’s another solution that is known, repeatable, and effective.
(Agile Alliance)

Antipatterns in Product Ownership

When we talk about Product Ownership, we can identify two principal versions of antipattern:

Shared Product Ownership

In this situation there is not just one Product Owner, but a set of people who collectively play its role. There is no single decisive leader on vision and product strategy; on the contrary, all people have to discuss, debate and align with each other before making a decision.

This leads to a slowdown in the decision-making process, and furthermore, all decisions have to be negotiated, which means that one time one alternative is favored, while the next time the perspective considered will be another at the risk of losing a single thread in product growth.

This slowdown has negative effects in team dynamics: the group is forced to wait for answers until all the different Product Owners are aligned on priorities. This could lead the team to: avoid questions and involve the Product Owner Committee only when strictly necessary, to limit further discussions.

In the long run, these dynamics discourage collaboration between product ownership and teams.

Divided Product Ownership

Whereas in the first case Product Ownership was shared at the same level by a group of people, in this case there is only one Product Owner who, however, has not the authority to fulfill the responsibilities of his role. He can be defined as a “scribe”: he writes user stories and he interacts with the team by attending events. But he is deprived of the responsibility of deciding on what really impacts the future of the product.

Instead, there is another figure, generally a Product Manager, who is in charge of product vision, product marketing strategy and of keeping in touch with the market and stakeholders.

This dynamic could be seen as a solution to different situations, for example when the Product Owner is overworked or when he/she is distant from the team. In both cases, it comes from PO’s need to have someone to his side to intermediate with the team.

Let us look at the two cases specifically.

• Overworked Product Owner

The causes of the Product Owner’s overload can be different:

• • Lack of time due to the many other projects he/she has to follow (he is not only a Product Owner, but also manage other activities)
  • He/she is the PO of several teams or several products (so, he is not always available)
  • The team does not support the PO in the right way (Scrum Master and team do not support him/her in writing stories or preparing the Product Backlog Refinement).

Regardless of the various reasons, an overloaded Product Owner leads to several negative consequences.

First, he/she becomes a bottleneck in decision-making. Thus, the team often has to wait for answers; alternatively, it must avoid asking and decide on its own (risking finding solutions that are not suitable for the business or the customer).

Secondly, if the Product Owner fails to participate in Product Backlog Refinement, Review or Planning, the team has to continually look for him/her in order to know the updated priorities.

Moreover, it can often happen that the Product Owner is late, forcing the team to interrupt to update him on what has been done so far during the meeting.

Finally, he often does not take part in the retrospective with the team. Thus, even if the team wants to address the problem, he is not there to decide how to solve the issue.

• Distant Product Owner

In this case, Product Owner and team are in divergent contexts: in two geographically separate offices, in two different organisational functions, or in two different time zones with only few working hours in common each day.

So, communication is difficult, there are delays in decision-making and there are few moments available to share ideas and information. In such a circumstance, whatever question the team asks to the Product Owner, people will probably have wait days for an answer. Having one or more team members blocked means that they will start working on other tasks, increasing the team’s Work In Progress and maybe consequently the lead time.

There may also be another situation in which a Product Owner is “distant”: when he/she and the team belong to different departments (in a silo structure) where people often blame each other for failures. Consequently, even teams and the Product Owner could stop collaborating (led by the corporate culture) in case of problematic situations, but rather try to blame each other in order to only pass the buck.
This is a fictitious distance, which can, however, create even more problems than a real physical distance.

Whatever the reasons, in both Shared and Divided Product Ownership this solution discourages collaboration between team and Product Owner, even leading to a loss of authority of Product Ownership in front of the team.

Some tips

But how can we solve or avoid those dynamics?

The first step is to make the dysfunctional dynamics evident and to start highlighting the resulting effects.

For a long term solution, in the case of an Overloaded Product Owner, the organisation should relieve him/her of activities or projects which are not related with the product, in order to allow him/her to have the right focus on the evolution of the product. For this purpose, other people could be delegated or selected to take over extra activities.

In the short term, however, the team should make the problem obvious, for example explaining what the Product Owner has time to do or not and to make team agreements to support his/her activities. Possibly, the team could also think about agreeing on how to receive the necessary information asynchronously, without the risk of being blocked by the Product Owner’s absence during certain meetings.

Conclusion

In order to solve this antipattern, people should give a single person the authority to decide on product evolution and the necessary strategy.
The Product owner is one and only one: he/she is responsible for the product (and thus the decisions about it), ideally controls the budget and can greatly influence the creation of a collaborative corporate environment (of course, it also depends on the corporate culture).

The Product Owner, of course, considers the opinions of all the involved stakeholders and gathers information from many people and functions around him/her; but he/she is the final decision-maker. The Product Owner must be able to have the time to focus on the products and to allow the team to get the answers it needs to work in a continuous flow.

Obviously, team support in operational activities is also crucial. Each team can find the right balance by defining clear agreements that can help people to avoid grey areas where they do not know who has to perform a specific task and to define collaborative ways that best enable people to work toward a common goal.