Whether it’s the production of software, designing cars or watches …
Whether it’s building products in the approach of Agile, Waterfall or in any other way …
Whether it’s Agile, Scrum, Kanban, DSDM, RUP or XP …
No matter how we call him …
… Product Owner is a key role in product development.
Since the role of the Product Owner (PO) is so important, even crucial, why is it so difficult to find organizations in which it is not distorted in any way?
But to speak of distortion, I must first determine how to correctly understand the role of PO.
Looking at the above, in order to perform his duties,
At the very beginning, I wrote that the role of PO is assigned to a person. Why not to a few people who share tasks and competences? There are many reasons, but the most important is the coherence of the vision for the product, and the ability to efficiently respond to changes in the product environment. Decisions must be made swiftly, without unnecessary discussions and stalemate. The third reason is one-man responsibility for the value and success of the product. The one-man role of PO does not allow blurring responsibility for the lack of decisions, and at the same time allows the organization to learn faster in the event of taking the wrong direction.
But let’s come back to problems with the creation of such a Product Owner. There are several, but the root cause is one: fear on the business side.
1.“Product Owner is another name for an analyst in Agile” — fear of real change.
Such treatment of PO for a long time reduces his position in the organization and cuts him off from the business context of product development. In addition, it imposes on him the obligations of the PO regarding the development of the application, without giving him the right to decide on its vision, development path or components. The fear of such a change is unfounded — managers become stakeholders of such a product and can still submit their needs and ideas for development, and the PO chooses those that, in his opinion, will provide the greatest business value. Of course, the particular interests of some people in the organization may not be met, but the PO’s task is to choose the best possible path for the product, and not to improve the well-being of managers.
2.“Product Owners are so important to our organization that we have forty-two of them” — fear of responsibility.
Yes, 42 is the answer to all the puzzles of the universe, however, the product requires the centralized power of the PO. Distributed decision making over time causes dispersion of responsibility, and taken decisions do not cover all aspects of a product’s performance. The product must be considered in the context of the system as a product of the entire organization and a global view of its operation is needed. The product operates with many elements of the organization. Moreover, if some element of the organization is not related to the product, it means that it should be related to it in the future. If it doesn’t make sense to the product — it’s probably redundant.
3.“I decide on the product, but I will not be a Product Owner because it’s such a low position that even talks to programmers” — fear of losing position.
Nothing could be further from the truth. It may seem that the work closer to the programmers looks like a lower position, but the responsibility and independent decision-making about the product allows the Product Owner to be credited for its success. Of course, this is the success of the entire team, but the PO has the greatest decision-making power. PO does not talk to programmers — PO talks to everyone in the organization. He is practically the most important person in the organization, because he creates and is responsible for the product, and it is the products that bring value to the organization. The success or failure of the product depends on his decision, and thus its position in the organization is crucial.
4.“Product Owner is very technical role, I’m a manager” — fear of incompetence.
Product Owner must have skills that go beyond the manager’s set, but it isn’t difficult and highly technical. The theoretical part of the skill can be acquired fairly quickly through training. The practical part of skills can be acquired while working on the product, and the initial deficiencies don’t cause the product to crash if they are quickly replenished. The list of skills that a Product Owner must acquire over time is not short, but achievable:
- evidence-based decision making (conducting tests, conducting experiments)
- product performance data analysis (user behavior analysis, software behavior analysis)
- market analysis (competition analysis, market share analysis, global change analysis)
- user research (quantitative research, qualitative research, conducting control groups, collecting feedback)
- user-context thinking (user story, user centered design, business value estimation)
- planning releases and major changes (release management, release goal, user story mapping)
- creating a product vision (lean canvas, elevator pitch, personas)
- ability to cooperate, collect feedback and present the product to stakeholders
- ability to cooperate with development teams (backlog management, technical debt).
Organizations that promote the product approach and strengthen professional and correctly set Product Owners have the opportunity to quickly develop their products in the direction expected by their clients. In addition, correctly introduced agility in the organization allows for quick response to unexpected market changes.
That’s why I urge you:
Managers — try to be Product Owners, because it’s worth it.