A Product Owner decides what a Scrum Team should work on next, and why. That sounds simple, but in practice the role involves a wide range of work: shaping a product direction, writing and ordering backlog items, talking with customers, negotiating with stakeholders and making quick decisions for the team. This article explains what a Product Owner actually does, based on the Scrum Guide, with practical examples of how the responsibilities look in everyday work.
Key takeaways
- The Product Owner is accountable for maximising the value of the product resulting from the work of the Scrum Team.
- The core of the job is managing the Product Backlog: the Product Goal, clear items, a clear order and full transparency.
- Much of a Product Owner's time goes on stakeholders and customers, not just the backlog.
- A Product Owner can delegate work, but not accountability.
- Product Owners decide what and why; the Developers decide how.
The short answer
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. They are also accountable for effective Product Backlog management, which includes developing and communicating the Product Goal, creating and communicating Product Backlog items, ordering those items, and making sure the Product Backlog is transparent, visible and understood.
Everything else a Product Owner does serves those goals. For a full introduction to the role, see our complete Product Owner guide.
Where a Product Owner's time goes
The Scrum Guide does not prescribe a schedule, and every product is different. In practice, most Product Owners divide their time between five areas:
- Direction: developing and explaining the Product Goal.
- The Product Backlog: creating, refining and ordering items.
- Customers and stakeholders: understanding needs, gathering feedback and managing expectations.
- The Scrum Team: answering questions, clarifying scope and taking part in Scrum events.
- Evidence: checking whether what the team delivered actually created value.
New Product Owners often spend too much time on the backlog and too little with customers. The backlog is only as good as the understanding behind it.
Responsibility 1: Set and explain the Product Goal
The Product Goal describes a future state of the product that the team can plan against. It sits in the Product Backlog and gives every Sprint a direction. The Scrum Team works toward one Product Goal at a time, fulfilling or abandoning it before moving to the next.
In practice, the Product Owner usually develops the Product Goal with input from stakeholders, customers and the team, then keeps returning to it. When someone asks "why are we doing this?", the answer should connect back to the Product Goal.
For example, the Product Owner of a hotel booking app might set a Product Goal such as "Guests can manage their whole stay, from booking to check-out, without calling the hotel." That goal immediately helps decide what belongs near the top of the backlog and what can wait. Our article on Scrum artifacts explains how the Product Goal relates to the Product Backlog.
Responsibility 2: Create and communicate Product Backlog items
Product Backlog items describe what could be done to improve the product. The Product Owner makes sure they are clear and understood. That rarely means writing long specifications. More often it means a short description of the need, followed by conversation with the Developers.
Compare two items:
- Vague: "Improve notifications."
- Clearer: "Guests receive a reminder the day before check-in with the hotel address and check-in time."
The second one tells the team who benefits and what "done" might look like, which makes it far easier to discuss, size and plan.
Responsibility 3: Order the Product Backlog
The Product Backlog is ordered, and the Product Owner decides the order. This is where most of the difficult decisions happen, because ordering one item higher means another moves lower.
The Scrum Guide does not prescribe a technique for ordering. Many Product Owners use common approaches such as:
- Value versus effort: favouring items that deliver a lot of value for relatively little work.
- Risk first: doing items early that reduce the biggest uncertainties or technical risks.
- Learning first: doing small experiments that answer important questions before investing heavily.
- Dependencies: ordering items so that work others depend on happens in time.
- MoSCoW: sorting items into must have, should have, could have and won't have for now.
Whatever technique is used, the final order is the Product Owner's decision, and it should be explainable in terms of value and the Product Goal.
Our guide to managing a Product Backlog explains these techniques in more depth.
Responsibility 4: Keep the Product Backlog transparent
A Product Backlog only helps if people can see it and understand it. The Product Owner makes sure the backlog is visible to the team and stakeholders, reflects current priorities, and does not hide important work. Removing items that are no longer useful is part of this. A backlog of hundreds of forgotten items is not transparent, even if everyone can technically open it.
Responsibility 5: Work with customers and stakeholders
A Product Owner represents the needs of many stakeholders in the Product Backlog. That requires regular contact with them. Typical activities include:
- Talking with customers and users to understand their problems
- Meeting internal stakeholders such as sales, support, operations and management
- Explaining current priorities and the reasons behind them
- Saying no, or not yet, to requests that do not serve the Product Goal
- Inviting the right people to the Sprint Review to see working results
The Scrum Guide notes that anyone who wants to change the Product Backlog can do so by trying to convince the Product Owner. That makes the Product Owner the single point where competing requests are weighed.
Responsibility 6: Support the Developers during the Sprint
Once a Sprint starts, the Developers need quick answers. Is this edge case in scope? Which of two approaches better serves the customer? According to the Scrum Guide, scope may be clarified and renegotiated with the Product Owner as more is learned, as long as the Sprint Goal is not endangered.
A Product Owner who is available to answer questions within hours, not days, often makes a bigger difference to the team's results than a perfectly written backlog. Product Owners also take part in refinement, helping the Developers understand upcoming items. The Developers who will do the work are responsible for sizing it; the Product Owner may influence them by helping them understand and select trade-offs.
Responsibility 7: Check that value was delivered
Delivering an Increment is not the end of the job. A Product Owner looks at whether the change actually helped: are customers using the new feature, did the problem go away, did the numbers move? This evidence feeds back into the Product Backlog. Sometimes it shows that a planned follow-up is no longer needed; sometimes it reveals a better opportunity.
An Increment can be delivered to stakeholders before the end of the Sprint, and in many organisations the Product Owner has a strong say in when to release. The Sprint Review is not a gate for releasing value.
The Product Owner in each Scrum event
| Event | What the Product Owner does |
|---|---|
| Sprint Planning | Makes sure attendees are ready to discuss the most important items and how they relate to the Product Goal; proposes how the product could increase its value this Sprint; helps define the Sprint Goal |
| Daily Scrum | The event is for the Developers; the Product Owner takes part as a Developer only if actively working on Sprint Backlog items |
| During the Sprint | Clarifies and renegotiates scope with the Developers without endangering the Sprint Goal |
| Sprint Review | Works with stakeholders and the team to inspect results, discuss progress toward the Product Goal and decide what to do next |
| Sprint Retrospective | Takes part as a member of the Scrum Team, helping improve how the team works together |
See the five Scrum events explained for more on each event.
A typical week, as an example
As an illustration only, a Product Owner working with one team on two-week Sprints might spend a week like this:
- Two customer calls to understand how guests use the booking app
- A meeting with the support team to review the most common complaints
- A refinement session with the Developers on items for the next Sprint
- Several short conversations answering the Developers' questions
- Reviewing usage data for a feature released last Sprint
- Updating the order of the Product Backlog based on what was learned
- Explaining to a senior manager why their request is ordered below a customer-facing fix
What a Product Owner can delegate, and what they cannot
The Scrum Guide states that the Product Owner may do the backlog work personally or delegate the responsibility to others, but remains accountable. In practice, Product Owners often delegate tasks such as:
- Writing the first draft of detailed backlog items
- Researching customer needs or market data
- Preparing analysis for a decision
What cannot be delegated is the accountability itself: the final decisions about order and value, and answering for the result.
What a Product Owner does not do
- Tell the Developers how to build. How to turn Product Backlog items into a usable Increment is up to the Developers.
- Assign tasks. The Developers are self-managing and plan their own work.
- Run the Daily Scrum. It belongs to the Developers.
- Act as a messenger. Passing stakeholder requests straight to the team without judging their value is not product ownership.
- Share the role with a committee. The Product Owner is one person.
Signs a Product Owner is doing the job well
- The team and stakeholders can explain the Product Goal in their own words.
- The top of the Product Backlog is clear, and its order makes sense to others.
- The Developers get answers quickly and rarely wait for decisions.
- Stakeholders attend the Sprint Review and their feedback visibly shapes the backlog.
- Decisions are based on evidence about customers, not only on opinions.
Common challenges and how to handle them
Too many stakeholders, all with "top priorities"
Bring requests back to the Product Goal and make trade-offs visible. Showing what would move down if an item moved up often ends circular arguments.
Having the title but not the authority
The Scrum Guide says the whole organisation must respect the Product Owner's decisions. If decisions are routinely overruled, raise it openly, often with the Scrum Master's help, as an impediment to the team's effectiveness.
Not enough time for the team
Product Owners with many other duties can become a bottleneck. Delegating preparation work and setting regular times for the team helps, but sometimes the organisation needs to free up more of the Product Owner's time.
Balancing new features with technical work
Technical improvements rarely have a vocal stakeholder. Listen to the Developers about the risks of neglecting them, and treat that work as part of the product's long-term value.
How the role changes across the product's life
What a Product Owner spends time on shifts as a product matures. The accountability stays the same, but the focus moves.
A new product
Early on, much is unknown. The Product Owner spends a lot of time with potential customers, testing assumptions with small experiments and keeping the Product Backlog short and flexible. The Product Goal may be about proving that the product solves a real problem at all.
A growing product
Once the product has users, there is more evidence and more demand. The Product Owner balances new features with improvements to what already exists, handles more stakeholder requests and uses data to decide what matters most. Ordering the backlog becomes harder because there are more good options.
A mature product
For an established product, the work often shifts towards reliability, efficiency and keeping customers happy. The Product Owner may spend more time on technical improvements, cost and long-term direction, and on deciding when parts of the product should be simplified or retired.
Working with the Scrum Master
The Product Owner and the Scrum Master work closely, but their focus is different: the Product Owner on what the team builds and why, the Scrum Master on how effectively the team works. According to the Scrum Guide, the Scrum Master serves the Product Owner by helping find techniques for defining the Product Goal and managing the Product Backlog, helping the team understand the need for clear and concise backlog items, helping establish empirical product planning in a complex environment, and facilitating stakeholder collaboration when requested or needed.
A good partnership often shows in small things: the Scrum Master helping a busy Product Owner run a focused refinement session, or raising an organisational impediment when the Product Owner's decisions are being overruled. Read what does a Scrum Master do? for the other side of the relationship.
Tools Product Owners commonly use
Scrum does not require any particular tool, and it does not require a roadmap. Many Product Owners still find these helpful:
- A backlog tool or board to keep the Product Backlog visible and ordered
- A simple roadmap that shows direction and themes rather than fixed dates for every feature
- Customer notes from interviews, support tickets and feedback sessions
- Usage data to see how people actually use the product
- A shared place for the Product Goal so it stays visible to everyone
The tool matters less than the habit of keeping information current and visible.
Questions a good Product Owner asks every week
- Does everyone still understand the Product Goal, and is it still the right one?
- Is the top of the Product Backlog ready for the next Sprint Planning?
- Which items no longer matter and can be removed?
- What did we learn from customers this week, and does it change the order?
- Did the last Increment deliver the value we expected?
- Is anyone on the team waiting for a decision from me?
- Which stakeholder have I not spoken to recently?
A Product Owner with several teams
When several Scrum Teams work on the same product, the Scrum Guide says they share the same Product Goal, Product Backlog and Product Owner. The Product Owner's job then includes making sure the teams understand how their work fits together, and that the backlog order makes sense across all of them.
Build Product Owner skills
If you want to move into the role, Product Owner Plus (Associate) focuses on product vision, backlog management and stakeholder alignment. The exam is taken online on ExamVault by CertExpert with three attempts included, and the certificate and digital badge are valid for two years. See the certification page for current learning paths and prices. Our CSPO guide explains another widely known option.
Frequently asked questions
What are the main responsibilities of a Product Owner?
Maximising the value of the product, and managing the Product Backlog: developing the Product Goal, creating clear items, ordering them and keeping the backlog transparent.
Does a Product Owner write user stories?
Often, but not necessarily. The Scrum Guide does not require user stories. A Product Owner may write backlog items personally or delegate the writing, while remaining accountable for them.
Who decides the order of the Product Backlog?
The Product Owner. They take input from stakeholders and the team, but the order is their decision.
Does the Product Owner decide how the work is done?
No. The Developers decide how to turn Product Backlog items into a usable Increment.
Can a Product Owner change the Sprint Backlog during a Sprint?
Scope can be clarified and renegotiated between the Product Owner and the Developers as more is learned, as long as the Sprint Goal is not endangered. The Sprint Backlog itself is the Developers' plan.
How much of a Product Owner's time goes to stakeholders?
It varies by product and organisation, but it is usually a large share. Understanding customers and stakeholders is what makes good backlog decisions possible.
Can a Product Owner delegate their work?
Yes, they can delegate backlog work to others, but they remain accountable for it.
Is the Product Owner a full-time role?
The Scrum Guide does not say. It depends on the product and organisation, but a Product Owner who is rarely available will slow the team down.