Confusing the stakeholder with the product owner can lead to dysfunction that significantly impacts delivered value. Your project will benefit from understanding the difference.
There’s a distinction between stakeholders and product owners.
A stakeholder is anyone that can affect the product. Typically, there are many stakeholders, all with different expectations, levels of knowledge and activeness in the development process. Stakeholders can be end users, sponsors, company management or people from various departments
The product owner is a single person who pays attention to the stakeholders’ needs, ensures those needs are met and builds a vision for the project. Their mission is to maximize the value of the project by filtering and comparing stakeholder needs based on business value, including the cost analysis, risks, dependencies and a few other factors. Their focus is on the idea’s value, not the idea’s source, to remain unbiased.
Most people think that knowing the business is enough for them to be the product owner. Although CEOs are familiar with the company, they likely don’t have the training or time to be the product owner. Thus, when they choose to assume this role, they run the risk of acting as a bottleneck. This scenario often happens inside small companies.
When considering who will be the product owner, the worst mistake you can make is underestimating the experience and skills needed to master this profession. This might include an agile mindset, experience with certain methods and tools, and more.
The best-case scenario is that the CEO remains a stakeholder. A dedicated product owner is then brought in to outline the responsibilities, take care of the CEO and other stakeholders’ needs, and collaborate with the scrum team to build the product.
Avoid the ill-advised scenario of having one of the stakeholders assume the role of product owner. They may lose objectivity and cater to their agenda instead of the other stakeholders’ needs.
The backlog isn’t defined or detailed enough.
A lack of communication can often impede progress due to the proposed product owner’s unavailability or missing skill set. In this scenario, trouble arises as early as the product discovery phase and continues through the launch and implementation phases.
Poor communication leads to a high chance that the vision, product road map and backlog won’t match what’s needed.
Misalignment with the points mentioned above and a lack of detail in the product backlog will force the development team to implement items according to their intuition.
The result?
When feedback is collected, the team will realize they need to redo large parts of the application. Redoing work generates disappointment, frustration and waste, negatively impacting the budget, deadlines and delivered value.
A product owner by proxy creates a communication breakdown.
The product owner explains the vision, sprint goals and main flow in a rush, but they don’t define the backlog or work closely with the development team during product creation, and they delegate these tasks to someone else.
We call this a proxy PO or deputy PO.
A proxy PO often creates a backlog and communication breakdown with the development team on backlog details. They will communicate with the actual product owner to understand their needs and implement them into backlog items. More often than not, he or she has no access to end users or other stakeholders.
This product owner becomes a bottleneck because they can’t manage the stakeholders’ expectations or make critical decisions directly. A proxy product owner becomes a middle man between the product owner and the development team, and details are lost in transition, leading to distorted communication between the development team and stakeholders.
You prioritize by criteria instead of business value.
When the PO isn’t available or fails to manage the backlog, the development team will often be forced to work on ready-for-development features instead of the most valuable ones. Working on these features will lead to implementing many low-value items that should have otherwise been kept at the bottom of the backlog or ignored altogether.
The impact is evident. Besides team demoralization, costs increase while lowering the value of your product.
The development team takes on product owner responsibilities.
What’s important to understand is that if the product owner’s responsibilities aren’t upheld, the scrum master and development team must compensate, which will negatively impact the project.
Why?
The development team will spend more time clarifying functional aspects than building the actual product. The unnecessary reallocation of time and energy is directly linked to the budget, deadlines and delivered value.
Belatrix can offer you support.
There’s always a chance your product will be successful despite having the issues mentioned above if your scrum team is skilled and collaborates well.
But, this would make your team the exception — not the rule. Why risk it?
If you’re searching for a skilled product owner to join your team, the Belatrix platform can support you with skill assessment tools, recruitment services or freelance profiles. Browse through our services, or contact us if you want to learn more about how we can help.