What are the scenarios that a PO may work and which are the differences?
There are at least 5 different scenarios that we will find ourselves as a Product Owner.
There are at least five different scenarios that we will find ourselves as a Product Owner.
The Product Owner, in theory, is the owner of the product vision, so he or she makes the decisions to maximize the value for the business and lead the team towards that. Therefore, the PO must be solely accountable for the backlog and its priorities. However, some variations happen in practice concerning which department the PO belongs. The hierarchy tends to change the role of the PO considerably.
During my journey as a PO, I had the opportunity of working in different structures, which I would say that there is no right and wrong, there are various scenarios that require different approaches, but what are the differences?
The structures in which a PO can work in general are:
Product department
In this structure, there is usually a Head of Products, CPO (Chief Product Officer), or VP of Products, who is in charge of how the Product Teams work together and which is the product vision. The team is generally compound of Product Owners, UX and UI. The POs work directly with the UX and UI to maximize the value of the product.
In this scenario, the focus is on the product, and the PO has full autonomy in terms of prioritization. This scenario brings advantages concerning dependencies with other teams since the POs are all in the same team, it is easier to remove dependencies.
Regarding the disadvantages, there may be conflicts in the definition of priorities, as POs may have a different view than UX and UI about the level of details and importance of a particular interaction for the product. To resolve such conflicts, the PO must find a commitment together with the team. The focus must always be maximizing the value for the customer.
Business Team
In this structure, the PO represents a business area; for example, in one of my roles, I served the Marketplace. In this case, I was responsible for the direction of this part of the product. However, the alignment must be crystal clear with the business area.
The big difference here is that the PO does not belong to a team with other POs, as he or she works between the business area and the development team. In this scenario, the most crucial aspect is to define which KPIs (Key Performance Indicator) require attention and need to be improved. The PO identifies this opportunity and leads the development team towards it.
The advantage of this format is that the PO is continuously within the business and clearly understands what works, what doesn’t, and what requires more attention.
A significant disadvantage of this scenario are the dependencies among teams because the PO works practically isolated from the other teams, it will be highly complicated in general to resolve dependencies because of different priorities for each business unit. Generally, each PO prioritizes the backlog according to what is vital for the business area, so dependencies require more negotiations to find a commitment.
IT
The PO tends to work in the IT area if it is a product where the target audience requires more advanced technical knowledge, or perhaps the company is still in transition from a traditional methodology (waterfall, RUP, etc.) to an agile framework.
This structure tends to bring significant conflicts in general, as the PO has an interest in maximizing the value of the product, but reports perhaps to the CTO or another technical lead, which aims to improve the structure of the systems and technology in usage.
In this format, the PO is most probably far from the business area as well as from the customer, which makes it more complicated to understand what are the real opportunities and problems to be solved.
The focus on this structure is generally technical, and the PO needs typically to face a lot of conflicts, so that the business value becomes the focus. I would say that in most cases, the PO needs to align with the stakeholders what is more important, but to make the decision, it is required a sponsor; in such scenarios, the PO tends to have a low level of autonomy.
Notably, this is the structure that I avoid at all costs, as it is against the role of a PO and makes it very difficult to focus on the business itself. In my opinion, IT and Product are complementary areas, but they are not the same:
Product: the focus is on discovering the opportunities, which is the best way to interact with the customers and ensure that value is delivered;
IT: the focus is on the technology, ensuring that the systems are running as they should, defining the right technology to use for each opportunity.
Hybrid structure
This scenario is a combination of the scenarios: product area and business team. The big difference, in this case, is that the PO represents and reports to a business team; however, there are frequent ceremonies with the other POs to ensure constant alignment.
There is the figure of a CPO or Head of Products, but he or she does not manage the Product Owners. However, he or she plays the role of a leader to convey essential company messages, such as direction, relevance, and what is critical at the moment. This role also helps to resolve conflicts between areas. Also, it helps to find the balance between the priorities among the Product Owners.
It is an exciting structure, because the PO knows about the business, but there is a CPO that helps the Product Owners to follow a sustainable and clear direction, conflicts are resolved in a clearer and simple way.
A possible disadvantage would be, the CPO is not in charge of the POs. Therefore, conflicts can be harder to resolve. For example, the business areas are directing the POs to opposite ways; this conflict is complicated to fix because the CPO would need to align with the Business Directors to find a commitment. That will, for sure, require many discussions and negotiations.
Proxy
The proxy is a common scenario for outsourcing. For example, a company outsources the development of a product. However, it keeps the role of the Product Owner on the company side. In this case, the PO would be too far from the development team. Therefore there would be a Proxy PO on the side of the outsource company as well.
The Proxy PO is in charge of aligning and clearing the expectations with the Product Owner from the company side. In this case, the Proxy PO takes mainly no decisions towards the future of the product. The focus is on bridging the company side with the development team.
The challenge of this scenario is setting the expectations; it generally requires a more reliable PO, because the company most probably pushes hard for more. The problem here is to set the balance and ensure that we don’t break the team into micro-units.
The advantage of this role is that the PO is as close as possible to the development team so that the PO can provide feedback as fast as possible, therefore avoiding later failures.
One disadvantage is that the PO has little or no influence in the Product Vision, which needs to be clear from the very beginning, so that the PO will not get demotivated because of that.
Willem-Jan makes the same point in his article about Proxy PO. That’s why it is a disadvantage that Proxy POs face.
The proxy PO doesn’t have the last say on the Product Backlog. Product vision and strategy are somewhere else. This is heavily conflicting with below passage of the Scrum Guide:
“For the Product Owner to succeed, the entire organization must respect his or her decisions.” — Scrum Guide 2017
In short, there is no better or worse structure, there are different scenarios, and for each one, it must evaluate what will bring the most significant value to the business. Remember, the role of the PO is to maximize the return on investment, so this is always the focus.
The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.