The Product Owner decides what a development team builds next and answers for whether that was worth building. The role is often reduced to maintaining a list of tasks, which is roughly like describing an editor as someone who keeps a folder of articles — accurate about the artefact, silent about the judgement.
Quick Overview
What you’ll learn:
- What the Scrum Guide actually makes the Product Owner accountable for
- How product vision and the backlog function as instruments rather than documents
- Which prioritisation technique fits which situation, and what each one costs
- Which hard and soft competencies the role genuinely depends on
- Where the role gets difficult: conflicting stakeholders, overloaded backlogs, decisions without complete information
- How the effectiveness of the role is measured, and how people grow into it
Who this article is for:
- People moving into the role from business analysis, project management or development
- Product Owners who hold the title and suspect they are being used as a message relay
- Managers deciding how the role should be staffed and what it should be accountable for
Reading time: 13 minutes
What the Role Is Accountable For
The Scrum Guide defines the Product Owner as the person accountable for maximising the value of the product resulting from the work of the Scrum Team, and as the single person responsible for managing the Product Backlog. Both halves of that sentence carry weight. “Maximising value” makes the accountability an outcome rather than an activity, and “single person” removes the committee that most organisations instinctively assemble around product decisions.
The role requires a deep understanding of customer and market needs, of the product vision, and of the organisation’s business objectives. It is not a project manager under a different name and not the development team’s manager; the closest useful comparison is an entrepreneur operating on behalf of a product, deciding what gets built and in what order so the available capacity produces as much value as it can.
In practice, the accountability breaks into a set of things that have to be done by someone and that the framework assigns here:
- Defining and communicating the product vision and the product goal, so the team understands what it is aiming at
- Creating and maintaining backlog items — user stories, requirements, defects — in a form the team can act on
- Ordering the backlog so that value delivered in each iteration is as high as it can be
- Keeping the backlog transparent, visible and understood by everyone who depends on it
- Working with developers during the iteration, answering questions and resolving ambiguity as it appears
- Accepting or rejecting what was produced, at the review
- Working with stakeholders to gather requirements and feedback, and to manage what they expect
Delegation is possible for most of these; accountability is not. When the Product Owner delegates the ordering of the backlog, ordering stops being a product decision and becomes an average of everybody’s preferences.
Product Vision, and Why It Has to Be Said Out Loud
Defining and communicating a clear product vision is among the most fundamental parts of the work. The vision answers why the product is being built at all, and it gives both the team and the stakeholders a direction against which individual decisions can be checked. Without it, prioritisation degenerates into responding to whoever asked most recently.
The vision is built from market need, company strategy and the problems the product is meant to solve, then communicated in a form people can repeat: a short framing statement, a roadmap, a visual model. The test is not whether the document exists but whether a developer, asked why a feature matters, can answer without looking anything up. A vision is also not permanent — it is reviewed against changing conditions and adjusted deliberately, which is different from letting it erode through unexamined exceptions.
The Backlog as an Instrument
The Product Owner is the single person accountable for the Product Backlog — the ordered list of everything that might be needed in the product. Managing it is continuous work rather than administration: adding items that emerge from the vision, user needs and stakeholder feedback; describing them so the team can act on them, usually as user stories with acceptance criteria; estimating effort with the team rather than for it; ordering by business value, risk, dependency and cost; and refining the list so it is always ready for the next iteration.
The refinement habit is what separates a backlog from a wish archive. Items near the top are detailed enough to be picked up; items far down carry only enough description to be recognised later. Detailing low-priority items is one of the most common and least visible wastes in the role, because the work looks productive and is usually discarded.
Ordering Work: Which Technique Fits Which Situation
Ordering the backlog is where value is actually created or lost, and the Product Owner has to weigh business value, urgency, technical risk, dependencies, implementation cost and product strategy against each other. Several techniques support that, and they are not interchangeable.
MoSCoW sorts requirements into Must have, Should have, Could have and Won’t have this time. The Agile Business Consortium, which maintains it within the DSDM framework, is explicit about the discipline that makes it work: Must Have items are held to a minority of the total effort, with the remainder available as contingency. Without that constraint the technique produces a list where everything is a Must Have, which is not a priority order but a relabelled backlog.
A value against effort comparison places items on two axes to expose the quick wins and the expensive marginal work. It is fast, visual and easy to communicate — and entirely dependent on the quality of the two estimates behind it.
The Kano approach classifies features by how they affect customer satisfaction, separating what customers assume from what delights them. It is the right instrument when the question is which features actually differentiate the product, and it requires real user research to answer.
Weighted Shortest Job First divides the cost of delay by the duration of the job, ordering work by economic flow rather than by preference. Scaled Agile, which defines it, is direct about where the difficulty lies: the ordering is only as good as the cost-of-delay estimate, which requires business analysis most organisations are not used to doing.
| Technique | Best fit | What it gives the Product Owner | What it costs |
|---|---|---|---|
| MoSCoW | Fixed time or budget, defining a minimum viable release | Fast, intuitive categorisation that stakeholders understand immediately | Discipline to keep the Must Have set genuinely small |
| Value against effort | Early stages, when the high-return work has to be found quickly | A visual case for what to do first and what to defer | Both axes are estimates, and both are contested |
| Kano | Customer-facing products where differentiation matters | Focus on what delights rather than what merely satisfies | User research, and the skill to interpret it |
| Weighted Shortest Job First | Large programmes and portfolios where delay has a price | Economic ordering that holds up across teams | Cost of delay has to be estimated credibly |
Whichever is used, the process has to be transparent to stakeholders. A prioritisation nobody can reconstruct is indistinguishable from favouritism, and it will be treated as such the first time somebody’s request is deferred.
The Technical Ground the Role Stands On
Although the role is oriented towards business and communication, some hard competencies are load-bearing. Knowledge of the business domain and the market comes first, because every prioritisation decision is a judgement about that domain. An understanding of the technologies involved — not the ability to write the code, but enough to hold a real conversation about feasibility — keeps the Product Owner from being told things that are not true. The ability to work with data, familiarity with requirements techniques, and a working knowledge of agile practice complete the set.
The technical understanding threshold is worth stating precisely, because it is usually stated badly. The Product Owner does not need to be able to build the thing. They need to be able to tell the difference between “that is difficult” and “that is difficult for us, this quarter, given what we have already committed to” — because those two statements lead to different decisions.
The Competencies That Decide Whether It Works
Success in the role depends heavily on the softer half. Communication is first among them, in both directions: with business stakeholders and with a technical team, in language each of them uses. Building relationships and earning trust follows from it, and negotiation matters because the role exists at the point where interests genuinely conflict.
Empathy — the capacity to hold the user’s and the stakeholder’s perspective rather than only one’s own — is what turns requirements into products people use. Decisiveness under incomplete information is unavoidable, since complete information arrives after the decision was needed. Assertiveness in defence of the vision and the priority order is what keeps empathy from turning into compliance. Leadership without authority, and resilience under sustained pressure, round the set out.
None of these is decorative. A Product Owner who is technically competent and cannot say no to a senior stakeholder produces a backlog that reflects the organisational hierarchy rather than the product’s value.
Working With Stakeholders Who Disagree
Stakeholders — customers, users, executives, marketing, sales, support — hold frequently incompatible views of what the product should do next, and the Product Owner sits at the junction between them and the development team. The work is to gather requirements and feedback actively, understand what each group needs behind what they asked for, manage expectations, explain technical and budget constraints in terms they can weigh, and communicate the resulting decisions.
Reconciling conflicting expectations is among the hardest recurring parts of the role. What works is transparent communication and a consensus built rather than imposed: listen to every side, understand the motivation underneath each position, then decide on the basis of the product vision, the business objectives and whatever data exists — and say why. Stakeholders can accept a decision that went against them if they were heard and the reasoning was visible. They rarely accept a decision that simply appeared.
Regular demonstrations and shared workshops build the common understanding that makes those conversations shorter over time.
Product Owner and Product Manager: Where the Line Falls
The two roles are frequently conflated, and the boundary genuinely moves between organisations. The distinction that holds most often is one of scope and horizon. A Product Manager typically carries a broader, more strategic responsibility across the whole product life cycle — market research, strategy, development, launch, marketing and profitability. The Product Owner in Scrum is the more tactical of the two, focused on maximising value through backlog management and close collaboration with the development team within the framework’s rhythm.
In some organisations one person holds both. In others the roles are separated and work in close partnership. Neither arrangement is wrong; what is wrong is leaving the boundary unstated, because the gap between them is where product decisions quietly stop being made.
Inside the Scrum Team
The Product Owner is part of the Scrum Team, not a client of it. With the developers, the work is primarily clarifying what backlog items mean, answering questions and making sure the purpose of each item is understood. The Product Owner participates in planning, helping the team select what to take on; stays available through the iteration; and at the review assesses the increment and gathers feedback. The relationship rests on trust and open communication, and its defining rule is that the Product Owner defines what and why while the team decides how.
Effective communication with developers is a practised skill rather than a personality trait. Availability matters most — questions answered quickly keep an iteration moving, and questions left unanswered turn into assumptions that surface as defects. Clarity comes next, supported by diagrams, mock-ups and backlog items with unambiguous acceptance criteria. Listening to the team’s technical judgement, and acting on it, is what makes the relationship reciprocal.
| Communication trap | What goes wrong | What to do instead |
|---|---|---|
| Vague or incomplete user stories | The team does not fully understand the requirement, which produces defects, delay and rework | Before planning, run a short session with a developer and a tester on the key stories to settle detail and acceptance criteria together |
| Acting as a relay for requirements | Requests are passed through without being understood, prioritised or given business context | Engage directly with stakeholders and keep asking why until the business need behind the request is clear |
| No regular feedback to the team | The team cannot tell whether it is on course; problems surface at the review, generating frustration and waste | Attend enough of the team’s daily rhythm to give feedback and correct course inside the iteration |
| Communicating only through the tracker | Nuance is lost and the working relationship weakens | Keep short, regular question-and-answer time with the team outside the formal events |
The other half of the team relationship is the Scrum Master, whose accountability is the effectiveness of the team rather than the value of the product. The two roles pull in the same direction from different ends: the Scrum Master helps the Product Owner with backlog technique, prioritisation practice and stakeholder communication, while the Product Owner supplies the feedback about impediments and team performance that the Scrum Master acts on. Understanding where the Scrum Master role actually creates value is worth the Product Owner’s time, because the most common failure between the two is each assuming the other owns something neither does.
Where the Role Gets Hard
The difficulties are consistent across organisations: managing contradictory expectations from multiple stakeholders; the constant need to prioritise and to refuse good ideas because better ones exist, which is harder than it sounds precisely because the ideas are good; balancing business need against what the team can technically sustain; absorbing changing requirements; communicating vision clearly and repeatedly; finding enough time for the team, the stakeholders and the market when all three want more; and sustaining focus over a horizon measured in years.
Backlog overload deserves separate treatment because it is the most preventable. A backlog stuffed with stale, unclear or low-value items becomes unmanageable and obscures what matters. The defences are refinement as a habit rather than an event, removing what has lost relevance; a willingness to refuse items that do not serve the vision; consistent use of a prioritisation technique; and restraint about detailing items that may never be built.
Deciding Without Complete Information
The Product Owner is the decision-maker for the product within Scrum, deciding on the vision and business goals, user and stakeholder feedback, market data, the technical constraints the developers report, and the current order of the backlog. Good decisions here are argued rather than felt: they rest on data and reasoning, not preference, and they are explained.
Transparency about how a decision was reached matters as much as the decision. It is what allows the team and the stakeholders to disagree productively, and it is what makes the next decision easier, because the reasoning is already shared.
Tooling
The instruments are unremarkable and worth choosing deliberately. Backlog management and iteration tracking run in the team’s issue tracker; roadmapping tools help where the horizon is long enough to need one; prototyping and design tools support visualising ideas for the team and stakeholders; analytics supply the behavioural data that turns opinion about users into evidence. The rule is the usual one: pick what matches how the team works rather than adopting tools because they exist.
Measuring Whether the Role Is Working
Measuring a Product Owner’s effectiveness should concentrate on the value the product delivers, not on throughput. Useful indicators include the business value delivered each iteration, assessed against agreed objectives; customer and user satisfaction, from surveys and direct feedback; the return the product generates; the speed at which new capability reaches the market; the quality of the backlog itself, judged by clarity, ordering and readiness; and the effectiveness of the collaboration with the team and the stakeholders.
What should not be used is the count of completed stories. It measures the team’s throughput and the Product Owner’s willingness to slice work finely, and it is entirely compatible with building the wrong thing efficiently.
Maximising Value, in Practice
The overriding objective is value maximisation, reached through a few things done consistently: understanding market and user needs well enough to translate them into a clear vision; holding the highest-value items in a defensible order; working with developers continuously so they have the context to make good implementation decisions; collecting feedback and responding quickly; and deciding on scope and direction in a way that balances the short term against the long.
Certain dispositions help: curiosity about both market and technology; willingness to decide and to own the decision; the courage to say no and to take a calculated risk; persistence; empathy; strategic thinking; and resilience. Most of them can be developed deliberately, which is the useful part.
Growing Into the Role
Product Owners improve the same way products do — through feedback and iteration. Reading and industry material provide the base; training and workshops, whether certification-oriented or focused on communication and negotiation, supply techniques that would otherwise be learned by trial on a live product; practice in real projects is irreplaceable. Regular feedback from the team, the Scrum Master and stakeholders identifies where development actually needs to happen, and exchange with other Product Owners supplies the perspective a single organisation cannot.
For people entering the role, it helps to see the competency map as a whole before specialising — the overview of the skills a Product Owner is expected to have is a reasonable starting point for planning that development. For those already in the role, the fastest route to depth is formal grounding in the framework itself: the Professional Scrum Product Owner accredited training covers the accountability and its mechanics with the assessment attached, which is a more honest test of understanding than experience alone provides.
Build Your Skills
The role rewards technique. Backlog structure, prioritisation under real constraints, stakeholder negotiation and value measurement are all learnable, and learning them away from a live product is considerably cheaper than the alternative.
➡️ Scrum Product Owner Toolbox — a practical approach — EITT training
Frequently Asked Questions (FAQ)
Does a Product Owner need a technical background?
Not formally, and the requirement is often overstated. What the role needs is enough technical understanding to communicate with developers and to assess whether a requirement is feasible in the current context. Deep knowledge of the business domain and of user needs matters more than the ability to write code.
How much time should the Product Owner spend with the team?
Enough that the team never waits on an answer. In practice that means treating availability to the developers as a first-order commitment rather than something that happens after the stakeholder meetings, and being present through the iteration rather than only at its boundaries.
Can one person be Product Owner for several teams?
It is possible and it degrades quickly. Effectiveness falls as attention fragments, because the parts of the role that matter — understanding the domain, ordering deliberately, being available — all consume attention. Beyond a small number of teams, the better answer is a separate Product Owner per product, or delegated responsibility with the accountability still clearly placed.
How does a Product Owner handle pressure for immediate changes?
By using the backlog as the instrument of the conversation. A transparent order and stated prioritisation criteria turn “we need this now” into a discussion about what moves down to make room, which is a discussion the stakeholder can participate in. The decisive move is showing the consequence of the change rather than arguing about the request.
What separates a Product Owner from a business analyst who owns a backlog?
Accountability for value. A business analyst can describe requirements precisely and completely; a Product Owner decides which of them are worth building and answers for that judgement. Where the role is staffed as analysis without decision rights, the backlog gets better written and the product does not get better.