Product Owner

Scrum is an agile framework that enables teams to develop products and adapt them progressively. Within this framework, the Product Owner (PO) is accountable for maximising the value of the product resulting from the team's work. They champion the Product Goal and are accountable for effective management of the Product Backlog, the ordered list of work to be done. Their role is to make priorities understandable and connect development work to user needs.

This accountability goes beyond writing up requests. The PO must explain why a feature is worth developing and how it contributes to the goal being pursued. They engage with stakeholders, clarify backlog items and make their order visible. In the product practices described by the EQL framework, they also draw on their business knowledge and user feedback to adapt their decisions.

How the role is carried out depends on the organisation. Before recruiting, clarify who defines the product's goals, which decisions the PO can make and whom they report to. The job title alone does not establish their autonomy or reporting line. Responsibility for prioritisation must come with genuine authority to decide between competing requests.

Product Owner, Product Manager and developers: who does what?

Within the Scrum framework, responsibilities are divided as follows:

• The Product Owner champions the Product Goal and determines the order of the backlog. They make requirements and decisions clear to the team.
• Developers select the work for the Sprint through discussion with the PO. They are responsible for estimating that work and deciding how to carry it out.

The Product Manager works on the product's direction and priorities. This role is not defined by the framework. If both roles exist, clarify how they share decisions without assuming that the PO is limited to execution.

The PO therefore influences decisions through an understanding of needs and trade-offs. This accountability does not, in itself, give them line management authority over developers.

The aim is to focus the team's work on needs that matter to users and to the product. A backlog can be detailed without making those choices understandable. If the reasons for a priority remain implicit, stakeholders have little information with which to discuss a request or understand why it has been deferred. This lack of transparency can lead to decisions that diminish the value of the product.

For a business leader, a key question is therefore how much decision-making authority the PO is given. Asking someone to be accountable for priorities while allowing each stakeholder to change them independently creates a contradiction that needs resolving. Defining the role should include clarifying how requests come in, how they are discussed and who decides their order. According to the Scrum Guide, the reference document that defines the framework, Product Owner accountability rests with one person, even if they represent the needs of many stakeholders.

Another concern is how well the problem is understood. A request framed as a solution may still require discussion about the users affected and the intended outcome. Analysing user journeys and feedback on usage helps the team reconsider what it should develop. Expected value remains a hypothesis to test against results, with no universal indicator applicable to every product.

Fictional example: a team is deciding between adding a filter and simplifying a form. The PO starts by clarifying the difficulties users face. They then discuss the expected value and constraints with the team and explain the chosen priority. Feedback after delivery may lead them to reconsider that choice.

Finally, reviewing completed work should allow for adaptation. The Sprint Review brings the team and stakeholders together to examine results and adaptations to make to the product. Reducing it to a demonstration deprives the session of its purpose as a collaborative discussion of what comes next for the product.

• Formulate and communicate the Product Goal to give the team a shared understanding of the purpose behind its decisions.
• Understand user needs and clarify expected outcomes with stakeholders.
• Clarify backlog items so that the proposed work is understandable.
• Order features according to their expected value and the product context.
• Make the backlog visible and explain priorities to the relevant stakeholders.
• Discuss trade-offs with developers while respecting their responsibility for estimates and implementation.
• Analyse user feedback to adjust product decisions.
• Contribute to examining results in the Sprint Review and adapting the backlog.

Several routes can prepare someone for a Product Owner role. Business analysis and business-side support for IT projects (assistance à maîtrise d'ouvrage, or AMOA) provide useful skills for understanding a need, defining a request and engaging with those involved in a project. Moving into a PO role also requires learning agile principles and how to apply them. If the role is within a team that uses Scrum, AMOA experience alone does not demonstrate mastery of the Product Owner’s responsibilities within that framework.

Product management courses offer another route. The OpenClassrooms Product manager framework includes Product Owner among its target roles and uses projects and oral presentations to assess learning. This work can show how a candidate analyses a problem and explains a decision. It should not be confused with responsibility already held within an organisation.

An engineering background can also provide an understanding of software, project management and indicators. Multidisciplinary work helps with communication with developers and designers. When recruiting, look for technical understanding suited to the product, without automatically requiring previous experience as a developer.

It is helpful to express the experience required in terms of responsibilities. Distinguish between a candidate who has clarified requests with support and one who has made trade-offs and revised priorities following user feedback. The complexity of the product, the people involved and the intended level of autonomy should guide this choice. These are possible routes into the role, rather than mandatory prerequisites.

GetPro uses a set of criteria, each with a defined assessment method. Interviews explore skills through open questions and concrete examples. Reference checks supplement the observations gathered about skills and areas that need further exploration.

The steps below are recommendations for applying this framework to a Product Owner role. Adapt them to the product, the expected level of autonomy and the people the future Product Owner will work with.

1. Define criteria linked to the role's decisions

Choose observable criteria: understanding users, backlog clarity, prioritisation, feedback analysis and communication of decisions. Specify which decisions the candidate will need to make independently and which will involve support.

Link each criterion to a real situation in the role. If requests come from several departments, give more weight to explaining trade-offs. If the product involves technical constraints, plan a discussion with developers.

A suitable candidate connects their skills to the work expected. Be cautious about a presentation that lists methods without explaining their usefulness in this context.

2. Ask the candidate to describe a past decision

Ask the candidate to describe a priority they argued for, the information available and the other options considered. Ask them to clarify their personal contribution and who else was involved in the decision.

Where sharing is possible, examine an anonymised example of a backlog or a documented request. Look for the connection between the user need, the work chosen and the expected outcome.

Then invite the candidate to explain the feedback received and the changes it led to. A strong answer distinguishes expectations from observations. A warning sign is when delivery is the only success mentioned, with no explanation of its usefulness.

3. Offer a prioritisation exercise close to the product context

Fictional example: present two competing requests involving a form and a search filter, with incomplete information about their users.

Ask the candidate what further information they would seek before deciding. Invite them to propose an order for the work and explain what might make them change their mind.

Continue by asking them to clarify a request for developers. A user story with acceptance criteria can provide a basis, without requiring every candidate to use this format.

Assess the coherence of their reasoning and the limitations they acknowledge. Do not reward only the application of a prioritisation formula. A calculated score without justification of the assumptions deserves discussion.

4. Examine communication with the team

Ask how the candidate responds to an estimate that differs from their expectations or an urgent stakeholder request. Ask them to specify what they decide and what they leave to developers.

If your team uses Scrum, check that the candidate respects developers' responsibility for estimates and implementation decisions. A candidate who uses authority to dictate technical tasks confuses their prioritisation role with implementation decisions that belong to developers.

Also observe their ability to restate a disagreement and explain a deferral. If the role includes line management, assess that responsibility separately rather than inferring it from the PO title alone.

5. Compare observations before reaching a conclusion

Involve someone able to assess product decisions and a technical colleague to examine implementation constraints. If this expertise is unavailable internally, involve an assessor with experience in the relevant context.

During a reference check agreed with the candidate, seek to clarify their autonomy and contribution to the decisions discussed. Compare this information with the observations gathered, without asking a referee to replace the assessment.

Conclude which responsibilities the person can take on and what support they will need. A disagreement between assessors should prompt them to make the criteria and observed facts explicit.