Scrum Guide | 7. The most common mistakes of Product Owner

In today’s post we will focus on the most common challenges Product Owners face. We will also tell you how to prepare for situations in which these mistakes of Product Owner occur most often.

Mistakes of Product Owner – table of contents:

1. What may go wrong between the Product Owner and Customer
2. Challenges the Product Owner face regarding the rest of the Scrum Team
3. Summary

What may go wrong between the Product Owner and Customer

The Product Owner is the person who is personally responsible for the failures of the Scrum Team. Because of this position beyond the activities of the team, it is considered that the Product Owner is the single wringable neck. In other words, it is the Product Owner who suffers the most when the Scrum Team goes wrong. So how to deal with troublesome situations when they appear or better yet prevent them from happening in the first place?

To answer that point, we’ve provided a clear and in-depth analysis of some major mistakes of Product Owners and Customers in the following table together with a detailed discussion of each.

Error	Problem generated	Suggestions for a solution
Inability to prioritize	Non-optimized Product Backlog, blurring of Product Objective	Listening, questioning, negotiating the Product Objective with the customer, carefully processing the results of the negotiation
Lack of assertiveness	Too many tasks for the Scrum Team to complete	Thinking realistically, knowing and remembering the capabilities of the team
Insufficient business skills	Risk of lowering the business value of the Product created by Scrum Team	Continuous learning and acquisition of business competencies

Inability to prioritize

The mistake of not knowing how to prioritize is the bane of many Product Owners. Why is task prioritization a core competency? Because when everything becomes equally important, the Product Goal disappears. That is the intended effect of Scrum Team activity.

The problem starts already during the first conversations with customers about the Product Objective. The customer usually wants all his ideas to be realized as quickly and cheaply as possible. The Product Owner’s task is to establish a list of priorities. His task is to create a list of clear and feasible expectations ranked from the most to the least important, based on unstructured customer expectations.

The problem with prioritization most often originates from misunderstanding the customer’s expectations. It appears when the Product Owner is not able to extract information about the real Product Objectives from the Customer. That is the answer to the question of what needs the product is supposed to respond to.

So how do you protect yourself from this mistake? First – listen carefully to the customer. Second, learn to ask questions about the Objective and how each product feature works. Third – negotiate and limit the Goals to achieve. And for this, you will need assertiveness.

When the Product Owner has a list of tasks to do, there are proven methods to enhance their progression and elaboration. For example, using the so-called Eisenhower matrix is used to prioritize tasks according to importance and urgency criteria.

Product Owner’s lack of assertiveness

The problem that is closely related to the inability to prioritize is the lack of assertiveness. It results in inappropriately queued tasks and leads to blocking the realization of the Product Goal by compounding it with excessive tasks. Therefore, the ability to say no to the customer is crucial.

Product Owner assertiveness should be based on three pillars:

• knowledge of the team’s capabilities,
• knowledge of the solutions used and developed by the team,
• awareness of their role and value based on their place in the Scrum Team.

Therefore, one of the most important ways to prevent assertiveness problems is for the Product Owner to work with the Scrum Team daily. This will help him build realistic beliefs about the time and ability to implement the Customer’s ideas.

Insufficient business skills

The next mistake we would like to discuss is the lack of proper business qualifications. The strengths of these Product Owners are usually specialized qualifications. Their competencies are more closely related to the area of the Development Team than to the business. So there is a lack of well-established, practical knowledge about the competition, about the rules of the market, and the final customer of the product created by the Scrum Team.

There is no simple remedy for it, as it may occur in very specific situations. Surely, however, a good course of action for a Product Owner is to acknowledge it and keep learning and gaining experience and business competencies.

Challenges the Product Owner face regarding the rest of the Scrum Team

The ability to prioritize tasks, the assertiveness of the Product Owner, and his high business skills are the necessary prerequisites for creating an exemplary Product Backlog, the long-term foundation of the Scrum Team. If the Backlog is not outlined consistently and accurately, the problems in the Product Owner-Client relationship will spill over into the Product Owner-other Scrum Team member’s relationship. And in turn, they directly affect the effectiveness of the Scrum Team. What other pitfalls await the Product Owner in his relationships with the other Scrum Team members?

To make it easier, we have presented the problems between the Product Owner and Scrum Team in a table. Below you can find a detailed discussion of each problem and suggestions for solutions.

Error	Problem generated	Suggestions for a solution
Insufficient charisma	Development Team does not perform tasks included in Backlog, Product Owner’s opinion is challenged	Building authority based on soft skills and knowledge
Insufficient specialized skills	Misunderstanding of the daily operations and capabilities of the Development Team	Orientation to the specialties of team members, as well as gaining knowledge of the Team’s area of expertise
Dependence	Dilution of responsibility	Empowerment

Insufficient charisma

On a daily basis, the Product Owner’s job is to coordinate the Customer’s guidelines with the way they are implemented by the Development Team. This undoubtedly requires having the right authority, listening skills and charisma.

The problem of insufficient authority cannot be solved overnight. It requires long-term work on soft skills. And also gaining knowledge about the scope of tasks and skills of other team members.

Insufficient specialized skills

As we wrote in the article answering the question of Who is a Product Owner?, the role of a Product Owner is not strictly technical. However, knowing the basics of specialized skills of Development Team members can significantly increase the authority of a Product Owner. Insufficient qualifications in the team’s area of expertise can not only generate problems with the charisma and authority of the Product Owner. The mistake of not being interested in what the members of the Development Team specialize in and the basics of their competencies can generate funny situations, but also situations with disastrous business and interpersonal consequences.

Therefore, in order for the Scrum Team to deliver the best quality products, the Product Owner must have a thorough understanding of the product. It should not be difficult to get the right qualification considering that the Product Owner is part of a team of professionals. They can provide not only explanations but also suggestions on where to get knowledge about their field.

Dependence

The Product Owner must be able to make decisions independently. Of course, the key issue is to know Scrum Team conditions and constantly communicate with the Development Team. However, it is the Product Owner who is held responsible for the effectiveness of his or her actions. For this reason, the Product Owners need to build their authority and take responsibility for the decisions they make. The final call on team direction, prioritization, and acceptance of tasks belong to them.

Summary

We’ve discovered the most common mistakes of Product Owner. The role of a Product Owner is not an easy one. That’s why, when taking it, it’s worth preparing yourself for the problems that others have encountered on their path.

Client relationship problems usually stem from a lack of assertiveness, inability to prioritize, and insufficient business skills.

Mistakes of Product Owner that arise during the work with the rest of the Scrum Team result from the lack of independence and insufficient charisma of the person who took the role of Product Owner. Another reason may concern the lack of specialized skills and unwillingness-or lack of time to expand the knowledge.

If you like our content, join our busy bees community on Facebook, Linkedin and Twitter.

Scrum Guide:

1. Glossary of basic terms, roles and notions
2. What is Scrum?
3. Scrum values
4. How to implement Scrum in your company?
5. Scrum Team - what is it and how does it work?
6. Who is a Product Owner?
7. The most common mistakes of Product Owner
8. Who is the Scrum Master?
9. Characteristics of a good Scrum Master
10. The most common mistakes of Scrum Master
11. What statistics and metrics should the Scrum Master track?
12. Cooperation between Product Owner and Scrum Master
13. Development Team in Scrum
14. The most common mistakes of Developers
15. Scrum artifacts
16. Scaling Scrum
17. Sprint Backlog
18. What is the Product Backlog?
19. What are User Stories?
20. Creating the best User Story with INVEST
21. The most common User Story mistakes
22. User Story Acceptance Criteria
23. Estimation and Story Points in Scrum
24. Planning Poker
25. Team Estimation Game
26. Defining Increment
27. Scrum events
28. What is Sprint in Scrum?
29. Scrum Team Commitments - Product Goal, Sprint Goal and Definition of Completion
30. What is a Burndown Chart?
31. How to create and interpret a burndown chart?
32. Advantages and disadvantages of the burndown chart
33. Kanban boards in Scrum and Scrumban
34. Velocity in Scrum - Speed of the Development Team
35. Daily Scrum
36. Sprint Planning
37. Sprint Review
38. What is a Sprint Retrospective?
39. Common mistakes during a Sprint Retrospective
40. Product Backlog nurturing