Confusing the Stakeholder with the Product Owner can lead to various dysfunctionalities with a major impact on delivered value.
Stakeholder vs Product Owner
A Stakeholder is anyone that can affect the product or be affected by it. Usually there are many stakeholders with different expectations, levels of knowledge and availability for building the desired product. Stakeholders are the end users or their representatives, sponsors, part of the company’s management or different departments.
A Product Owner is a single person who should pay attention to the stakeholders’ needs, ensure the convergence of these needs and build a vision that will drive the team. Their mission is to maximize value by filtrating and comparing stakeholder needs mainly based on business value, including the analysis of costs, risks, dependencies, etc.
Their focus must lay on value and not the idea source in order to remain unbiased. Given the role of arbitrator with a clear mind, the Product Owner should be fully empowered.
Most people consider that knowing the business is enough. For example, although CEOs are familiar with the business, they are not usually trained as Product Owners and often do not even have the time to play this role. Thus, when they choose to assume this role, they run the risk of becoming a bottleneck. This scenario is more likely to happen inside small companies.
The biggest trap when working with a Product Owner is to underestimate the need to really master this profession (agile mindset, methods, tools, etc.).
In a best case scenario, the CEO should be considered a stakeholder and a dedicated Product Owner chosen to outline the list of responsibilities, take care of the CEO and other stakeholders’ needs and collaborate with the Scrum team to build the product.
But, this article would be useless if we never made mistakes.
In some ill advised scenarios when one of the stakeholders assumes the role of Product Owner, they may lose objectivity and cater to their own agenda instead of the other stakeholders’ needs.
What are the common cut corners and possible consequences when a Stakeholder is mistaken for a Product Owner?
Backlog not Defined or Detailed Enough
Sometimes, a lack of communication impedes progress because the person who is supposed to assume to role of Product Owner’s is not available or does not have the necessary skills. In such cases, troubles may arise even at the product discovery phase and continue throughout the launching and implementation phases.
Consequently, there are very high chances for the vision, product roadmap and backlog not to reflect the true needs.
Misalignment with the aforementioned points and the lack of detail in the product backlog will force the development team to implement items according to their intuition. The result?
Only when feedback is collected will they realize the need to redo large parts of the application. This generates disappointment, frustration and waste with negative impact on the budget, deadlines and delivered value.
Product Owner by Proxy
This Product Owner will explain the vision, sprint goals (occasionally) and the main flows in a rush, but they do not refine the backlog, work closely with the development team during product creation and instead delegates these tasks to someone else.
We call this a proxy PO or deputy PO.
This is often related to backlog breakdown AND communication with the development team on backlog details. A proxy Product Owner will communicate with the (actual) Product Owner to understand their needs and implement them into backlog items. More often than not, he has no access to either end users or other stakeholders.
This Product Owner becomes a bottleneck because they are not usually empowered to directly manage the stakeholders’ expectations and make important decisions. A proxy Product Owner becomes a middle man between the Product Owner and the development team, details are lost in transition and the message is distorted from both directions.
Such a loss for feedback integration from both sides!
Prioritization by Criteria instead of Business Value
As a consequence of the unavailability of the PO and/or insufficient backlog management, the development team will often be forced to work on ready for development features instead of the most valuable ones. This will lead to the implementation of many useless or low value items that should have otherwise been kept at the bottom of the backlog or even ignored completely.
The impact is obvious. Besides team demoralization, this will also increase costs while decreasing delivered value.
Development Team takes on Product Owner Responsibilities
What’s important to understand is that if the Product Owner’s responsibilities are not upheld, the Scrum Master and development team must compensate – leading to an impact on the project. Why? Simply because the development team will spend more time clarifying functional aspects then building the actual product.
The unnecessary reallocation of time and energy is directly linked to budget, deadlines and delivered value.
Read more: The Scrum Master Paradox
There is definitely a chance your product will be successful despite having the above-mentioned issues, mainly because the rest of the Scrum team is really strong and collaborates well.
Nevertheless, this would make you the exception – not the rule. But, why risk it?
The Scrum Master should be able to coach both the Product Owner and the organization to ensure compliance with the corresponding responsibilities at the needed level as well as the development team to help the Product Owner, depending on the context.
My advice would be to not push your luck and try to find the right person for the right role.
If you need a Product Owner to join your team, the Pentalog platform will support you with skill assessment tools, recruitment services or freelance profiles.
More articles on agility: