Product Owner Myths

The Scrum Guide states that a Product Owner is a professional responsible for achieving the utmost value to the product. Also, the Scrum Guide states that a Product Owner is responsible for maximizing the development team's work. However, the technique a Product Owner follows to achieve these things might differ from one individual to another, one organization to another, and one Scrum team to another. However, the problem with this role is that it is a highly misunderstood position. This is why many Product Owner myths are believed to be real by many organizations. Let us debunk some of these myths here:

1. The Product Owner Must Ensure the Best Satisfaction to Stakeholders:

Of course, stakeholders can be influential and powerful in any organization. Nevertheless, the value that a product creates is decided by its actual users. If a product cannot solve the problems faced by users, it cannot last in the market. Further, a product will be considered valuable only when it creates tangible benefits. Otherwise, the product should help users achieve some of their goals to succeed. 

Indeed, in any organization, internal stakeholders like support, sales, and marketing play a crucial role in offering a successful product. Nevertheless, it is better not to accept all their ideas to please them. When this is done, your team can end up with a product that satisfies the needs of stakeholders, but it will not address the requirements of users.

However, it does not mean you should completely eliminate taking stakeholder suggestions. But, it is better to leverage their expertise. Also, getting some valuable tips from them would be a good idea. However, as a Product Owner, you should not allow stakeholders to dominate your moves and they should not instruct you on what to do. Make sure that you do not consent to a weak compromise. You should say the final word regarding the product when no agreement can be reached.

2. The Product Owner Should Be the Maximizer of Speed:

The Product Owner is responsible for maximizing the product's value as per the Scrum Guide. But, how organizations interpret this statement is crucial for delivering real value. Otherwise, they tend to fall into traps.

The common issue is that most organizations co-relate the world, maximizing with increasing speed. However, some organizations believe that the Product Owner maximizes features. In this case, when a Product Owner offers a product with more features, he is seen as a successful person. But, these organizations overlook the impact of the features. The outcome will be that the product becomes more confusing and nobody can benefit. As a Product Owner, you should always remember that the presence of more features is not always better.

So, rather than seeing a Product Owner as a maximizer of speed or features, it would be the right thing to consider him as the maximizer of the value of products to end-users. As a maximizer, you should spend maximum time spotting issues worth solving.​​​​​​

3. There Should Be One Product Owner Per Development Team:

Many organizations misbelieve that there should be one Product Owner per product development team. But, the reality is that the organization should ensure the presence of one Product Owner per product. At times, many development teams work on the same product. In this case, all the development teams will have only a single product owner.

4. Only the Product Owner Can Write User Stories: 

It is not only the product owner who should write user stories. They can be written by stakeholders and teams dedicated to writing user stories. Nevertheless, the ultimate responsibility for creating user stories lies with the product owner. Indeed, user stories are not part of the core Scrum. The reason for the popularity of user stories is that they are written from the perspective of end users. However, the backlog can be in any format.

5. In Managing Product Backlog, the Product Owner Plays a Tactical Role:

In Scrum, the framework that created the Product Owner role, this professional is responsible for improving the value that a product creates for the end users. This needs complete ownership. It means that the Product Owner should have the authority to make strategic product decisions apart from tactical decision. As a result, a Product Owner in a Scrum organization should own a product completely. It means that he should own everything right from the product's vision to the complete product details.

Apart from taking care of the items in the product backlog, the Product Owner should carry out product discovery and strategic work. But, when it comes to Agile Scaling Framework, things are different. The Agile framework uses its own Product Owner role that is different from the one in Scrum.

The SAFe Product Owner is tactical and pays attention to clearing the product backlog. Also, the Product Owner will guide the team of developers in this regard. The strategic work is taken care of by the SAFe product manager. Dividing product ownership and using a tactical and strategic role is a commonly used scaling methodology. Nevertheless, this technique is not that helpful. You can understand the difference between the Product Owner roles in different frameworks from the picture below:

So, to avoid confusion and myths, you should understand which Product Owner role you play. Your accountability and authority will considerably differ depending on whether you are a SAFe Scrum Product Owner. ​​​​​​​

5. Define Solutions In Advance:

When a Product Owner starts his profession, there is every chance that he will be pressured to develop the right solution and deliver it on time. Even in some organizations, the stakeholders show interest in knowing the solutions in minor details. So, Product Owners in some organizations will have to work closely with the stakeholders to agree on how every component will work.

To handle stakeholders' requirements, the Product Owners will have to keep a detailed and extensive product backlog. When they have a Product Owner with a clear plan, the stakeholders feel highly satisfied. However, too much planning can lead to a validity illusion trap. Too much planning can trick your eyes. So, in the end, you will spot the issue only when the users get in contact with the solution.

Experts feel that validity illusion is the evidence we can foretell success. It is something similar to turning blind to a plan. However, the problem with product management is that you can ensure success only when the end-users could solve the issue they have been facing for a long.​​​​​​​

6. The Product Owner is the Only Person Talking To Customers:

One of the common product owner myths is believing that the product owner is the only person responsible for interacting with customers. Further, organizations believe that only the person working in this position should understand customers' needs and accordingly design the product. But, in reality, the Product Owner need not essentially be the only person interacting with customers to spot the issues they face. The development team should be deeply involved in the product discovery process to get to know the purpose of their product/solution building. The reason is that when they know what problem their solution is going to solve, they can bring out the best solution to customers.​​​​​​​

7. The Product Owner Can Be a Team:

Many organizations think that they can have a team of product owners. But, for any product, having only a single individual as the Product Owner is better. You can consider the role of a Product Owner as a funnel. It means that this professional will funnel the work to the team so that things can be completed. He should be the only voice getting the work to the team. It is better not to have five people feeding the funnel. It can lead to confusion, the general idea is to have a single Product Owner per product if an organization produces different products or solutions.​​​​​​​

8. The Product Owner is a Proxy To Stakeholders:

Believing Product Owners to be the proxy to stakeholders is one of the common Product Owner myths. This belief crops from the Scrum fact that the Product Owner is the only person interacting with stakeholders representing the entire Scrum Team. But, many Scrum teams express their disagreement with this myth with the behaviors mentioned below:

When a question about a feature is raised, the development team contacts the Product Owner to get the answer from the stakeholders. The Product Owner can get the answer from the stakeholders within a minute with a single phone conversation, as opposed to debating the entire day in a meeting.

When a stakeholder expresses fresh ideas to the members of the development team, they are referred to the Product Owner, and the development team does not take note of them.

The Product Owner alone is expected to spot and clarify the work on the product backlog on behalf of the Scrum Team.

So, rather than thinking of the Product Owner as a proxy for stakeholders, it is better to explain him as the individual responsible for including stakeholders' suggestions in the collaborative discovery process.  

Conclusion:

Dispelling the myths surrounding the role of a Product Owner is essential for fostering a clear understanding of their responsibilities and contributions within agile frameworks. From debunking misconceptions about stakeholder satisfaction to clarifying the role's strategic versus tactical nature, it's evident that the Product Owner's function extends far beyond task management.

Moreover, the delineation between frameworks, such as Scrum and SAFe, underscores the importance of recognizing the nuanced variations in Product Owner roles. Whether navigating product discovery or managing stakeholder input, a well-informed Product Owner is the linchpin for delivering value to end-users.
In this context, Simpliaxis offers Certified Scrum Product Owner (CSPO)® Certification, providing professionals with the expertise and credibility needed to excel in this pivotal role. By embracing agile principles and dispelling misconceptions, organizations can empower Product Owners to drive innovation, foster collaboration, and ultimately, deliver exceptional products that meet the needs of users and stakeholders alike.