In this article, I will describe some dilemmas of the Product Owner (PO) role, challenges associated with it, and anti-patterns that can emerge in the process.
Due to its complexity, the Product Owner role is often poorly understood. It extends far beyond the development team of which the PO is a member. However, delegating the team is not their responsibility.
Mantra regarding the PO role could be summarized as follows:
“In the Agile ecosystem, Product Owner is responsible for maximizing the business value of the initiative.”
Variations of the PO role are also present in other Agile frameworks (Product Manager, Solution Manager, Customer rep., Executive Sponsor, Project Manager). What’s written here applies to them as well.
CONDITIONS FOR SUCCESS
For a Product Owner to successfully perform their duties, several conditions must be met:
- PO must have the authority to make decisions about the product features that are the subject of the initiative.
- PO must have the authority to approve resources for product development.
- PO must have access to non-development resources of the organization, such as marketing, business analysts, customers, and management.
- The PO needs the support of senior management.
Meeting these conditions is not a guarantee of success, but they are its foundation.
PRODUCT OWNER SPECTRUM
There is an entire spectrum where a PO can be positioned within an organization.
The left side of the spectrum is reserved for “endangered” POs who don’t have enough influence on the initiative to successfully guide development. Nevertheless, they often bear the blame for product failure.
A Product Owner who wants to maximize project results must strive to move as far to the right on this spectrum as possible.
They won’t take on the role of entrepreneur (unless they’re the owner), but ideally, they should have the role of project sponsor. This effectively means also taking on the role of Product Manager with all the tasks associated with this function. In this case, the conditions listed above are met, enabling the PO to effectively guide product development.
I won’t go into specific tasks and techniques used by the PO or Product Manager. This is well documented in other sources, and I cover this topic in detail in the Product Owner course.
Let’s look at where things can go wrong.
ANTI-PATTERN 1
Recently during a consultation, I encountered an extremely professional and proactive PO who couldn’t find common ground with developers (two teams on the same product). After a brief discussion with the developers, it became clear they felt over-delegated. Instead of PO presenting a business problem at Backlog Refinement or Sprint Planning, explaining why he considered it to have high business value, and then discussing possible solutions with developers, the PO provided his own envisioned solution. Often even in the form of GUI wireframes or architectural framework.
The developers didn’t feel being heard. They felt they were on autopilot and their potential wasn’t being utilized. Consequently, developer motivation was low. In my opinion, deep resentment hadn’t yet set in, but they were probably heading in that direction.
Delegating the development team is not in line with the idea and doesn’t utilize the potential of a self-managed team.
Unfortunately, due to certain organizational “deviations”, the company hadn’t considered the developers’ objections until then. PO had previously been a developer, and management considered him competent to continue guiding developers in technical areas.
The PO should have realized that his tasks are now different and should understand the factors that influence developer motivation. Additionally, a full-time PO doesn’t have time to deal with technical details but should focus on product management.
The relationship between PO and developers could be summarized as follows:
- PO determines WHY a certain problem has business value (market research, user interviews, analysis).
- PO and developers together agree on WHAT needs to be done to solve the problem. These are the solution features (scope).
- Developers decide HOW and WHO will implement the scope.
Not just in development teams, but in all of Agile, problems should be solved by those closest to them. Maybe the delegated solution could even be better, but if developers don’t accept it as their own, motivation, quality, and feedback for future upgrades will suffer. Delegating the team is not the PO’s task. Agile teams are self-organizing and self-directing (within the product and organizational vision).
“A less optimal solution chosen by developers themselves in execution typically outperforms a more optimal delegated solution.”
ANTI-PATTERN 2 (COPY-PASTE PO, TICKET MONKEY)
The PO treats the Product Backlog simply as a repository of functionality requests submitted by clients/stakeholders. The requests are broken down into sub-functionalities, epics, or even user stories and placed into the backlog as a block. Often, this is a FIFO backlog, where the PO has not checked the business value of the submitted requests. Considering that they are responsible for the success of the entire initiative, this should be self-evident. Unfortunately, it is not.
This anti-pattern results from misunderstanding one’s own PO role in an Agile environment. Such teams often don’t conduct Backlog Refinement meetings. These are (among other things) intended to avoid the traps created by such an anti-pattern:
- Identification of dependencies between Product Backlog Items (PBIs), which can affect the business value of individual requirements.
- Combining PBIs into a common architecture enables synergistic implementation, thus reducing development costs and increasing the business value of individual PBIs.
- Critical evaluation of PBIs by developers regarding complexity or even business value. Developers are often in direct contact with the client themselves and have insights that the PO might not have.
- Solution optimization. A client might request an entire new program module, when their goal could actually be achieved by changing a few lines of code.
- Even clients can be wrong in their requirements. Maybe the functionality they want already exists?
Backlog Refinement offers other benefits not directly related to this anti-pattern. In mature development environments, teams spend about 10% of their time on Backlog Refinement.
ANTI-PATTERN 3 (DISGUISED PROJECT MANAGER)
The PO behaves like a traditional project manager. They monitor task completion, deadlines, and individual developer performance, instead of focusing on maximizing product value.
This anti-pattern results from an outdated way of thinking. Such a PO is probably evaluated (and rewarded) based on the amount of work completed, regardless of the business value created.
In such a case, it’s necessary to:
- Check if the company is really prepared to implement the organizational changes required by the Agile approach. Many companies aren’t ready for this, yet they wrap themselves in the flag of Agility while operating in a traditional hierarchical framework. Of course, results in such cases fall far below potential. Unfortunately, as long as the company is profitable, no one will notice this. But when market pressures become too great (technological lag), it’s often too late.
- The PO needs to be educated about the benefits of Agile work methods and be stripped of the ability to evaluate individual developer performance (and thus influence their rewards). In Agile, only team performance is evaluated, and this is measured by the business value created.
- Implement OKRs to align business requirements and development work. In our case, this helps primarily “upward”, as it forces management to define profitable business objectives, which probably hasn’t been the practice until now. OKRs also enable measuring the success of initiatives and thus determine responsibility for their success. Of course, many people don’t want this.
