They decide what the product must solve now, what can wait, and what the organisation explicitly chooses not to build.
A Product Owner is not defined by keeping a backlog, running ceremonies or writing acceptance criteria. Those activities may be part of the job, but they are not its core. What genuinely engages their responsibility is turning incomplete signals — sales requests, user feedback, usage data, technical constraints — into product decisions that are comprehensible and owned.
A Product Owner who merely executes orders requests that have already been formulated. Someone who fully holds the role first checks that the problem is worth solving, tells a need from a proposed solution, and gauges what each decision moves. They do not assume that something shipped has automatically produced value: they organise the confrontation between the initial hypothesis and real usage.
The role sits under permanent tensions: answering stakeholders without turning the roadmap into a sum of requests, holding commitments without freezing a solution too early, protecting the team's capacity without ignoring market urgency. The boundary with the Business Analyst lies in that responsibility: the Business Analyst investigates and formalises, the Product Owner decides and lives with the consequences.
Market benchmarks
The French market groups very different realities under the Product Owner title. Some roles are mainly backlog coordination or functional specification. Others carry genuine responsibility for discovery, prioritisation and measuring value.
A candidate may have perfect command of agile ceremonies without ever having had the authority to refuse a request or stop a feature. The hiring difficulty concerns above all people who can combine user understanding, reading the data, and holding a decision in front of influential stakeholders.
Context
In an IT services firm, the Product Owner often works within a contractual frame, with several stakeholders, on an application estate that is already constrained. Decisions have to work with the scope sold, the split of responsibilities between client and supplier, and the fixed-price or time-and-materials commitments.
Level 1
Junior
A Junior can organise a backlog, sharpen a request and follow a delivery once priorities have already been clarified. They lean heavily on process and on their manager's decisions. Faced with contradictory requests, they tend to seek approval up the line rather than build a trade-off.
Click to read
Level 2
Mid-level
A Mid-level Product Owner holds their scope autonomously. They check the facts, compare several options, identify the users affected, and can propose a reasoned prioritisation. They start measuring value after delivery. Their limit usually lies in politically or economically uncomfortable decisions: they can recommend, but do not always own a refusal or a stop on their own.
Click to read
Level 3
Senior
A Senior Product Owner does not take requests, data or commitments as given. They separate contradictory signals, state the hypotheses, tell a real constraint from a manufactured urgency, and make the consequences of each option visible. They can refuse, stop or shrink a piece of work when the available evidence no longer justifies the investment.
Click to read
Level 4
Expert
An Expert is not distinguished only by knowing the product better. They decide in situations where no option is free, and name explicitly what they agree to give up: a commitment, a feature already funded, part of the scope, or a stakeholder's support. Their role goes beyond the backlog: they improve the way the organisation decides about the product.
Click to read
A Product Owner who misreads the problem builds the wrong thing efficiently. This category assesses hypothesis validation and the ability to determine, after delivery, whether the expected value actually materialised.
Prioritisation carries the same weight as discovery, because understanding without choosing is not enough. This category assesses what goes into the backlog, and above all what does not.
A product decision only really exists once it is understood and carried. This weighting reflects the need to manage sponsors and to say no without hiding behind a methodology.
The Product Owner has to commit to a direction without full certainty. This category measures how they hold the roadmap and use experimentation to reduce risk.
This category checks that the product decision stays compatible with the team's capacity, rhythm and trust. Winning commitments by continually disorganising the team damages its ability to deliver.
The method in action
The scorecard at a glance — hover an axis
Management, delivery & client relations