Product Owner: The Complete Guide to the Role, Skills and Certification

The Product Owner is one of the three accountabilities in a Scrum Team, alongside the Scrum Master and the Developers. It is also the role most directly responsible for whether a product delivers real value. A Product Owner is not a requirements clerk, a project manager or a committee. This guide explains what the role involves according to the Scrum Guide, how Product Owners work day to day, the skills they need, the mistakes to avoid and how to become a certified Product Owner.

Key takeaways

• The Product Owner is accountable for maximising the value of the product resulting from the work of the Scrum Team.
• They are accountable for effective Product Backlog management, including the Product Goal and the order of items.
• The Product Owner is one person, not a committee, although they represent the needs of many stakeholders.
• For a Product Owner to succeed, the whole organisation must respect their decisions.
• Only the Product Owner has the authority to cancel a Sprint.

What is a Product Owner?

Scrum is a lightweight framework for delivering value in complex work. It is defined in the Scrum Guide, written by Ken Schwaber and Jeff Sutherland and last updated in November 2020. The guide describes three accountabilities in a Scrum Team: the Scrum Master, the Product Owner and the Developers.

According to the Scrum Guide, the Product Owner is accountable for maximising the value of the product resulting from the work of the Scrum Team. The guide adds that how this is done may vary widely across organisations, Scrum Teams and individuals. In other words, Scrum defines what the Product Owner is accountable for, not a fixed list of tasks.

The word "value" matters. A Product Owner is not measured by how many features the team delivers, but by whether the product becomes more useful for its customers and more valuable for the organisation. Sometimes the most valuable decision is to build less.

New to Scrum? Our complete Scrum Master guide gives an overview of the framework, and Agile vs Scrum explains how Scrum fits into Agile.

The Product Owner's responsibilities

For a practical, day-to-day view of the role, see what does a Product Owner do?

The Scrum Guide states that the Product Owner is accountable for effective Product Backlog management, which includes four things:

1. Developing and explicitly communicating the Product Goal

The Product Goal describes a future state of the product that the Scrum Team can plan against. It is the team's long-term objective. The Product Owner develops it, usually with input from stakeholders, and makes sure everyone understands it. The team works toward one Product Goal at a time and must fulfil or abandon it before taking on the next.

Our guide to the Product Goal and Sprint Goal shows how to write both, with examples.

2. Creating and clearly communicating Product Backlog items

Product Backlog items describe what is needed to improve the product. The Product Owner makes sure they are clear enough for the team to understand, discuss and eventually plan with. Clear does not mean long: the conversation between the Product Owner and the Developers matters more than a detailed document.

3. Ordering Product Backlog items

The Product Backlog is an ordered list, and the Product Owner decides the order. Many Product Owners weigh factors such as customer value, risk, dependencies and what the team could learn from an item. The order tells the team what matters most right now.

4. Ensuring the Product Backlog is transparent, visible and understood

Everyone who needs to see the Product Backlog should be able to, and should understand what it says. A transparent backlog lets stakeholders see where the product is heading and gives the team a reliable basis for planning.

The Scrum Guide notes that the Product Owner may do this work personally or delegate the responsibility to others, but the Product Owner remains accountable either way. Our article on Scrum artifacts explains the Product Backlog and Product Goal in more detail.

For a step-by-step approach, see how to manage a Product Backlog.

One person, not a committee

The Scrum Guide is clear that the Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog, but decisions come from one accountable person. Anyone who wants to change the Product Backlog can do so by trying to convince the Product Owner.

This matters because committees are slow and tend to avoid difficult trade-offs. When every stakeholder can add their own top priority, the backlog stops being ordered at all. A single accountable Product Owner can listen to everyone and still make a clear decision.

The Product Owner's authority

According to the Scrum Guide, for Product Owners to succeed, the entire organisation must respect their decisions. These decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review.

The Product Owner also has a specific power no one else in Scrum has: only the Product Owner can cancel a Sprint, and only if the Sprint Goal becomes obsolete. Cancelling a Sprint should be rare.

In practice, many Product Owners struggle because they are given the title without the authority. If a senior manager overrules every decision, or if priorities are set elsewhere and simply handed to the Product Owner, the role cannot work as intended. Making that visible is part of the Scrum Master's job with the wider organisation.

The Product Owner in each Scrum event

Sprint Planning

The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they relate to the Product Goal. During the event, the Product Owner proposes how the product could increase its value and usefulness in the current Sprint, and the whole Scrum Team collaborates to define the Sprint Goal. The Developers then select items and plan the work, in discussion with the Product Owner.

During the Sprint

Scope may be clarified and renegotiated with the Product Owner as more is learned. If the work turns out different from what the Developers expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog, without affecting the Sprint Goal. Being available to answer questions quickly is one of the most valuable things a Product Owner can do.

Daily Scrum

The Daily Scrum is for the Developers. If the Product Owner is actively working on items in the Sprint Backlog, they take part as a Developer.

Sprint Review

The Scrum Team presents the results of its work to key stakeholders, and progress toward the Product Goal is discussed. The Product Owner uses this working session to gather feedback and, together with stakeholders and the team, decide what to do next. The Product Backlog may be adjusted to meet new opportunities.

Sprint Retrospective

The Product Owner is a member of the Scrum Team and takes part in the Retrospective, helping the team improve how it works, including how it collaborates with the Product Owner. See the five Scrum events explained for the full picture.

Working with the Developers and the Scrum Master

The Product Owner decides what should be built next and why. The Developers decide how to build it. The Scrum Guide states that the Developers who will be doing the work are responsible for sizing it; the Product Owner may influence them by helping them understand and select trade-offs. A healthy relationship is a partnership: the Product Owner brings knowledge of customers and value, and the Developers bring knowledge of what is possible and what it will take.

The Scrum Master supports the Product Owner in several ways described by the Scrum Guide: helping find techniques for defining the Product Goal and managing the Product Backlog, helping the team understand the need for clear and concise Product Backlog items, helping establish empirical product planning, and facilitating collaboration with stakeholders when needed. Read what does a Scrum Master do? for more on that relationship.

A Sprint in the life of a Product Owner

Every organisation is different, and the Scrum Guide does not prescribe a schedule. As an illustration, a Product Owner's Sprint often includes:

• Before Sprint Planning: reviewing the top of the Product Backlog, checking it reflects the latest feedback, and preparing a proposal for what would make the next Sprint valuable.
• During the Sprint: answering the Developers' questions, clarifying scope, and taking part in refinement to prepare upcoming items.
• With stakeholders: meeting customers, users and internal teams to understand their needs and explain current priorities.
• With data: looking at how customers use the product and whether recent changes delivered the expected value.
• At the Sprint Review: inviting the right stakeholders, gathering honest feedback and updating the Product Backlog.
• At the Retrospective: helping the team improve how it works together.

Skills every Product Owner needs

• Decision-making: ordering the backlog means choosing what not to do, often under pressure from several stakeholders.
• Customer understanding: knowing who uses the product, what problems they have and what they value.
• Communication: explaining the Product Goal and priorities clearly to the team and stakeholders.
• Stakeholder management: listening to different needs, managing expectations and saying no respectfully.
• Business awareness: understanding how the product creates value for the organisation.
• Working with evidence: using feedback and data to test assumptions rather than relying on opinion.
• Collaboration: working closely with the Developers and the Scrum Master as one team.

Common mistakes and anti-patterns

• The order-taker: a Product Owner who simply collects requests from stakeholders and passes them to the team, without making real decisions about value.
• The proxy Product Owner: someone with the title but no authority, who has to check every decision with a manager.
• The committee: several people sharing the role, which slows decisions and blurs accountability.
• The absent Product Owner: rarely available to the team, so questions go unanswered and work stalls.
• The unordered backlog: hundreds of items with no clear order, which makes planning unreliable.
• Focusing on output instead of outcomes: measuring success by features delivered rather than by value created.
• Telling the Developers how to build: the "how" belongs to the Developers.

How to measure a Product Owner's success

Because the Product Owner is accountable for value, the best measures look at outcomes rather than output. Delivering many features is not success if customers do not use them. Useful questions include:

• Are customers getting more value? For example, are more people completing the task the product exists for, or are support requests falling?
• Is the team moving toward the Product Goal? Each Sprint should be a visible step toward it.
• Is the Product Backlog trusted? Stakeholders and Developers should be able to rely on its order.
• Are decisions made quickly? A team waiting days for answers loses momentum.
• Is feedback acted on? What stakeholders say at the Sprint Review should shape the backlog.

The right measures depend on the product. A Product Owner should agree with stakeholders what value means for their product, and look at it regularly.

Working with stakeholders: practical techniques

Much of a Product Owner's time is spent with stakeholders: customers, users, managers, sales, support and other teams. A few habits help:

• Make the Product Goal the reference point. When requests compete, ask how each one helps reach the Product Goal.
• Show the trade-off. Instead of a flat "no", explain what would have to move down the backlog to make room.
• Invite stakeholders to the Sprint Review. Seeing a working product leads to far more useful feedback than reading a status report.
• Keep the Product Backlog visible. When people can see the order and the reasons behind it, fewer arguments happen in private.
• Listen for the problem, not the solution. Stakeholders often ask for a specific feature; understanding the problem behind it may reveal a simpler answer.

The Product Owner in different organisations

The Scrum Guide notes that how the Product Owner maximises value can vary widely. In practice, the role often looks different depending on the setting:

• In a start-up, the Product Owner may be a founder or early product lead, close to customers and making fast decisions with limited data.
• In a large organisation, the Product Owner may spend more time aligning stakeholders, working within budgets and coordinating with other teams.
• For an internal product, such as a system used by colleagues, the "customers" are other departments, and value may mean saving time or reducing errors.

In every setting, the core stays the same: one accountable person, a clear Product Goal and an ordered Product Backlog.

Several teams, one product

When a product is too large for one Scrum Team, several teams can work on it together. The Scrum Guide says that if multiple Scrum Teams are working on the same product, they should share the same Product Goal, Product Backlog and Product Owner. This keeps one clear direction for the product and one accountable person for its value, no matter how many teams contribute.

Product Owner vs product manager

"Product Owner" is an accountability defined in Scrum. "Product manager" is a job title used in many organisations, often covering product strategy, market research and working with sales and marketing. In some companies one person does both; in others the roles are separate and work closely together. What matters in Scrum is that one person is clearly accountable for maximising the value of the product and managing the Product Backlog.

For a detailed comparison, see Product Owner vs product manager.

How to become a Product Owner

For a full step-by-step plan, see how to become a Product Owner.

1. Learn Scrum properly. Read the Scrum Guide several times and understand why each part exists.
2. Understand your customers. Product ownership starts with knowing who the product serves and what they need.
3. Get certified. A certification shows employers your knowledge has been assessed or that you have completed structured training.
4. Practise backlog work. Offer to help refine and order a backlog in your current team, or support an existing Product Owner.
5. Build your stakeholder skills. Practise explaining priorities and handling competing requests.
6. Use your background. Business analysts, project managers, developers and domain experts all bring useful experience to the role.

Product Owner certification

Several organisations offer Product Owner certifications. Our CSPO guide explains how one widely known option works.

Scrum Intelligence offers its own online certification, Product Owner Plus (Associate), focused on product vision, backlog management and stakeholder alignment. It can be taken on its own or combined with a partner certification in the same enrolment. The exam is taken online on ExamVault by CertExpert with three attempts included, and the certificate and digital badge are valid for two years. Experienced Product Owners can continue with Product Owner Plus (Professional), and Product Owner AI Plus covers using AI in product work. See the certification pages for current learning paths and prices.

The Product Owner role and AI

For practical examples, see how Product Owners can use AI.

AI tools are starting to help Product Owners with parts of the job, such as summarising customer feedback, drafting backlog items for discussion or analysing usage data. They do not replace the judgement the role depends on: deciding what is valuable, making trade-offs between stakeholders and taking accountability for the result.