Agile Glossary

Product Owner

What is Product Owner?

The product owner is a role on a product development team responsible for managing the product backlog in order to achieve the desired outcome that a product development team seeks to accomplish.  Key activities to accomplish this include:

  • Clearly identify and describe product backlog items in order to build a shared understanding of the problem and solution with the product development team
  • Make decisions regarding the priority of product backlog items in order to deliver maximum outcome with minimum output
  • Determine whether a product backlog item was satisfactorily delivered
  • Ensure transparency into the upcoming work of the product development team.

The product owner role was created as part of the Scrum framework in order to address challenges that product development teams had with multiple, conflicting direction or no direction at all with respect to what to build.

Many infer that a product owner is someone who can spend a considerable amount of time with the product development team providing clarification on product backlog items, and making decisions about which product backlog items to do and regarding the specifics of those particular product backlog items.


Also Known As

The role of the individual responsible for deciding what the product development team should build varies on the framework the team is using and their disposition toward Scrum terminology.  Other role names that perform basically the same function include on-site customer (XP), product champion, product director, or value manager.

The set of activities that a product owner does is often referred to as product ownership.

Existing, non-framework-specific roles such as product manager, business analyst, and functional manager (if the product supports their area of concern) are often found filling the role of the product owner.


Expected Benefits

The Scrum framework was originally created to address issues that product development teams faced. The product owner role was established in order to provide a single source of information for a product development team about the product they are trying to build.

This single point of information keeps the team focused and reduces churn resulting from waiting for answers, or conflicting priorities.

Product owners also represent a single point of responsibility, leading to the epitaph “single, wringable neck” which is a benefit for the team and those outside the team when looking to easily identify the responsible party but may not be as beneficial for the product owners specifically.


Common Pitfalls

It is usually quite difficult for one person to be able to make all the decisions regarding a product, have all the necessary detailed knowledge about the business needs of that product, and spend the amount of time with the product development team that they need and deserve.  As a result, product ownership responsibilities are often divided among multiple people.  The concept of the value team has gained traction as one way to accomplish this. If you follow this approach, ensure that there is a single decision maker for each type of decision.

The ideal product owner-to-product development team ratio is 1:1, meaning that a product owner works with only one product development team, and each product development team has only one product owner. When there are multiple teams working on the same product, this ratio is often violated, with product owners working with three or more teams at the same time. This often results in at least one team being ignored by a product owner at any given time.

If the person filling the product owner role also has other responsibilities, they may not be as present for the product development team as desirable. This leads to an absentee product owner and often results in delays in answers to questions or decision-making.

In some cases when the officially identified product owner is not available as frequently as the product development team would like, they establish a proxy product owner to provide more availability to the team.  This proxy may be someone identified by the product owner, or it may be someone on the team.  Many dislike this approach because it increases the risk that information the proxy provides and decisions the proxy makes could be overridden by the actual product owner at an inconvenient time.


Further Reading

Scrum Guide description of Product Owner

Examining the Product Owner Role

Agile Product Ownership In a Nutshell

Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks

Thank you to our Annual Partners​

Join us today!

Agile Alliance offers many online and in-person events and workshops for our members. If you’re not currently a member, you can join now to take advantage of our many members-only resources and programs.

Get the latest Agile news!

  • This field is for validation purposes and should be left unchanged.

By subscribing, you acknowledge the Agile Alliance Privacy Policy, and agree to receive our emails.

Additional Agile Glossary Terms

An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.
A product backlog is a list of the new features, changes to existing features, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific outcome.
An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.

Help us keep the definitions updated

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Not yet a member? Sign up now