What does the PO actually do?
POs are responsible for the value-maximisation of the product. They develop and advocate the product vision, based on a deep understanding of stakeholder requirements and business processes on the one hand, and on the ability to represent this vision to the outside world on the other. He has an idea of what the finished product could look like; who will use it, when, and for what purpose; how it will interact with existing processes; and most importantly, how it will add value to the company.
To bring the idea to product maturity, a PO must face three challenges:
- the stakeholder management,
- the product management, and
- the management of a development team.
Stakeholder Management
A product has many stakeholders, e.g. end users, business departments, QA, IT, legal, marketing, development. Each of these stakeholders has requirements regarding the product. The larger the product and the more distributed the stakeholders, the more diverse the respective requirements are, and the more often they conflict with one another.
In the service of value maximisation, the PO is responsible for collecting and structuring these heterogeneous requirements and deriving from them a product vision which can be supported by everyone. A certain amount of methodological competence is required here, as workshops have to be moderated, conflicts resolved and compromises achieved.
Product Management
Some of a PO's tasks can be thought of as a subset of product management: definition of personas and features, derivation of a development roadmap, and active management of the product scope. This includes writing user stories, maintaining a backlog and prioritising it by business value, and planning releases, among others. This, too, is a demanding sphere of activity that cannot be learned overnight.
Management of a development team
Ultimately, the value of the development team's work must also be maximised, ideally through a methodical approach to daily collaboration. It is crucial that the PO is able to communicate to the developers both what the product vision is and what is actually to be built. He should know the components of the "agile ceremony" and be able to use them productively for himself: Sprint Review, Team Retrospective, in particular the Sprint Planning.
In addition, the PO must also contribute to the formulation of acceptance criteria in user stories - an indispensable component for the acceptance of finished software increments. What's more, the PO also coordinates UX- and design-activities and discusses technical issues with the team: architecture, test automation or DevOps are just a few examples. In most cases POs can rely on the competence of their team in these areas. Nevertheless, they should have enough knowledge to be able to contribute constructively and also to question critically.