Or phrased differently: Why is the role called Product Owner?

I spent some hours researching the term's etymology, but I haven't been particularly successful, which is why this question came to be.

I am explicitly not asking about the definition of the role here. There are plenty of articles explaining that e.g. in the context of Scrum.

In particular, I am interested in the historical reasoning that has led to denoting it as an "owner".

It might also make sense to share some context with you to explain why this question came up in the first place: My experience is that teams unfamiliar with agile methodologies tend to replace the term "owner" in their minds with some variation of a role they already know from traditional hierarchies. This often leads to an interpretation that puts the Product Owner into some kind of principal or even boss position, which may be in stark contrast to what one wants to achieve when implementing agile processes. To be specific, what people intuitively interpret might yield views contrary to servant leadership, self-organizing teams and evolving situational hierarchies. That is why it might be necessary to better explain the context in which e.g. the Scrum definition of the "Product Owner" role should be seen with respect to the goals of the company where it is being implemented. Getting an idea about the intentions of naming it "owner" in the first place might help with that.

  • 2
    I'm not sure to what degree this question can be answered by someone other than Ken Schwaber or Jeff Sutherland.
    – Daniel
    Commented Sep 6, 2018 at 14:56
  • I am not sure either. Still wanted to give it a try in case I have missed something obvious. I am still kind of surprised that there is literally nothing about that on the internet apparently. It's a pretty valid question in my opinion.
    – starbugs
    Commented Sep 6, 2018 at 14:59

7 Answers 7


I've always interpreted it as being because the Product Owner (PO)... owns the product. S/he is the stand-in representative for the end-customers whom will be the ones literally owning the product in the future. As such, his/her responsibilities are somewhat similar to what the on-site customer's would be in eXtreme Programming.

And while the Customer is Always Right™, the Customer is Not Your Boss. Your boss is your boss. Hypothetically one individual could fulfill both roles of PO and manager, but I would personally advise against it - they are distinct roles with distinct responsibilities and goals. Just as the customer and the boss would be.

From the Scrum Guide, the PO is responsible for:

  • Clearly expressing Product Backlog items;
  • Ordering the items in the Product Backlog to best achieve goals and missions;
  • Optimizing the value of the work the Development Team performs;
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  • Ensuring the Development Team understands items in the Product Backlog to the level needed.

There's nothing in there even about servant-leadership, let alone 'normal' leadership. The Scrum Master is the servant-leader of the Scrum Team. The PO is just another member with different responsibilities.

Their responsibility is to pretend as if they own the product.

  • Thanks for your comprehensive answer. That makes sense, however, I have issues with the second part. There is something about leadership and management in the article: "The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable." and "For the Product Owner to succeed, the entire organization must respect his or her decisions." Accountability and decisions are aspects of ownership and they overlap with leadership and management inevitably.
    – starbugs
    Commented Sep 6, 2018 at 14:22
  • @starbugs How do you get leadership and management from that? The developers remain accountable for the code they write. The entire organization must respect how they choose to organize themselves. Does that mean that all of the developers are leaders and managers? Having accountability and authority is not the same as having leadership. It is necessary but not sufficient.
    – Sarov
    Commented Sep 6, 2018 at 14:26
  • "The Product Owner remains accountable". "[...] the entire organization must respect his or her decisions." Accountability and ownership cannot be spread among people and that is — in my understanding — the main aspect of why the PO has to be one person. He cannot delegate accountability to the team. In order to succeed and be accountable, he must be able to make decisions and set a vision. That is all about leadership. How he carries out these tasks is the management part.
    – starbugs
    Commented Sep 6, 2018 at 14:47
  • Accountability and ownership for the product should not be spread. The developers are accountable and responsible for other things. My point was that accountability and responsibility, while necessary for leadership, are not sufficient - otherwise every member of the Scrum Team should be considered a leader. The PO makes decisions and sets a vision for the product. The Dev Team makes decisions and sets a vision for the process and the standards and the implementation details, etc. This is not management. Management requires managing people, which neither the PO nor Dev Team do.
    – Sarov
    Commented Sep 6, 2018 at 15:13
  • Yes, my question is aimed solely at the PO, hence I was talking about his and only his leadership role — not about the dev team. In your prior comment you said that you see no leadership in what the Scrum Guide states. Do you agree now with my point about the PO role carrying leadership aspects through accountability and respect for decisions? In a perfect world, I'd agree that there shouldn't be a people management aspect associated with the PO role. In reality, as he is accountable for the product, he also may need to do that (or delegate it) if required or otherwise he might not succeed.
    – starbugs
    Commented Sep 6, 2018 at 16:01


You'll have to ask Ken Schwaber or Jeff Sutherland where they coined the term from. The source of the term does not appear to be publicly documented, but they likely introduced it somewhere between 1995-2001.

A Non-Canonical Etymology

During the 90s, a number of people were examining agile practices and ideas. Scrum and XP are two of the frameworks developed during this period, with a formal definition of XP apparently predating that of Scrum by a few years.

The Scrum role of Product Owner bears a close relationship to the role of on site customer in eXtreme Programming. Arguably, XP uses terms that speak to development team members, while Scrum uses terms that try to appeal more to business stakeholders. (This type of business-oriented terminology is even more apparent in frameworks like SAFe.) It could be further argued that the on-site customer is a role that is defined largely from the team's internal perspective, whereas a Product Owner is role with delegated responsibility from the organizational perspective. Consider the following examination of "ownership" to see why this may be so.

In Scrum, the notion of "ownership" stems from the role's obligation to be solely accountable for maximizing the value of the product under development. The Scrum Guide says, in part:

The Product Owner is the sole person responsible for managing the Product Backlog...The Product Owner is one person, not a committee...For the Product Owner to succeed, the entire organization must respect his or her decisions.

Basically, I've always interpreted the "ownership" portion of the term as a way of ensuring that the Product Owner role is a singular person rather than a committee, which in turn is intended to streamline the framework and reduce the organizational burden of providing on-site customers. In governance frameworks, the roles of Application Owner or Data Owner are often structured in a similar way, in order to facilitate communications and create accountability.

This chain of reasoning provides a pragmatic explanation for the introduction of the term, and provides some explanation for its utility value over other related terms. However, only the framework's authors can canonically ascribe how the term was decided upon for Scrum.


Beyond what is the in the tactical role description, I've always looked at the role as the judge or arbitrator when the team can't come to consensus on the decision that needs to be made to keep the delivery on track, hence they are the "owner" of the decision. They need to listen and understand the engineers point of views and differences thereof, as well as that of the business stakeholders. Servant leadership and empathy play critically into this role, if the PO is to be successful in managing such complex matrixed relationships.


Here's my admittedly-informal use of the term:

The "product owner" represents The Almighty Customer, and is often the team's most direct liaison to them, usually reporting directly to them. This role is very specifically focused on what the product will do and for whom it will eventually do it, and for ensuring that the whole thing actually does meet the business goals for which it was commissioned, as seen by the business units who commissioned it, and that will properly function and integrate in the prevailing business(!) environment. In team meetings, the Product Owner is therefore a proxy for those stakeholders.

I consider the sister role of "product manager" to be subtly different, because this role is concerned with "how" the work is being done. So, if we were to carry this analogy all the way through, the "product manager's" role is to keep the "product owners" happy. Conceptually, "Managers = hands-on, Owners = hands-off," in terms of the actual day-to-day development activity.

And, to me, having the two roles clearly separated and clearly formalized is very beneficial: the owner has his eyes locked on the actual owners ... the actual business context in which the finished product will run ... while the manager has his eyes locked on the process that is being used to build and to change it. Call it "Janus management" -- the Roman two-faced god.


I think this common mistake comes from the word "owner". "Own" has two different meanings: 1. to have, possess; and 2. to admit or confess to. The product owner is not one who have the possession of the product; rather is who admits or denies the specifications of the product in backlog.

  • 1
    Welcome to PMSE, Mohammad. +1 for an interesting point. I understand the dictionary definition. Is this your interpretation of what Scrum means by "owner" or do you know of another source that makes the same point about "admitting" backlog items? I only ask because I like the idea and I might want to use that explanation again in future.
    – nvogel
    Commented Sep 25, 2021 at 13:28
  • Dear @nvogel thanks a lot for your challenging question. That was only what I catch from its meaning. Unfortunately, I don't have any resource supporting my opinion. Commented Sep 26, 2021 at 16:01
  • 1
    Sorry but this isn't correct. "Admit" also has multiple meanings. You're using its 'allow in' meaning, but by context that's clearly not the intended meaning. The 'admit' in 'to admit or confess to' is using the same meaning as "Yes, I'll own what I did. I admit it; I killed your dog". The 'Owner' in 'Product Owner' pretty clearly means your first listed meaning, not the second.
    – Sarov
    Commented Sep 27, 2021 at 13:40
  • Well, "welcome to the vagaries of the English language, or any human language." The word "owner" might also mean, *"person with active decision-making responsibility with regards to something that s/he has a measurable stake in." The point-of-view of the external customer and/or business stakeholder is represented by the PO, whose task is to represent their interests in a pragmatic way. Commented Sep 27, 2021 at 22:14

The origin is... Certain methods were developed at software companies and not for IT groups (companies such as Easel or Borland). Thus Turbo Pascal was a "product" that they sold -it was not a brand, Borland was the brand- thus if you lead the Turbo Pascal group you "owned" the product.

Marketing did not have a concept of product owner, they centered around the brand- brand manager

That is why it is legitimate for the "software company" product owner to work closely with the team-but not necessarily for a brand manager, or line of business person- since they are running the business


I suggest looking at the major roles in an agile team. It's critical to understand everyone's role holistically so that it all makes sense. If the team has latched onto a specific term "owner", it may be because they're seeking authority or control and not looking at everything involved. Highlight all the roles and responsibilities and let them figure out where they want to be based on their values and skills.

  • Product Manager
  • Product Owner
  • Scrum Master
  • Scrum Team

While every situation is different, having clarity for the roles, motivations and responsibilities will let you adapt your team for your size and goals.

Scaled Agile Framework has some good materials to draw out the distinctions. https://www.scaledagileframework.com/product-owner/ enter image description here

  • 2
    Thanks for your answer. If I am not mistaken, scaled agile frameworks weren't a thing when the original Scrum definition of the PO came to be.
    – starbugs
    Commented Nov 1, 2018 at 12:23
  • 5
    As-written, this Answer doesn't seem to actually attempt to answer the Question 'Why is the role called Product Owner?'. If you are suggesting that this is an XY problem, please make that more explicit.
    – Sarov
    Commented Nov 1, 2018 at 13:27
  • I'm trying to address the motivation behind the question. - Why ask where a term originated? To better understand its meaning. - How can you better understand a single role? Understand the eco-system that role participates and how it relates and interfaces to the other roles. I took a more holistic approach. Other people searching and finding the title will be motivated in a similar way. The team in question has latched onto a single word because they know what that means - to them. You need to expand their thinking and show everything that's involved in an agile product team
    – eAndy
    Commented Nov 1, 2018 at 17:21
  • 1
    @eAndy: Your contribution is very welcome. In fact, you're absolutely right. The question stands in the context of establishing agile structures in multiple teams that have never worked that way and need to get an understanding of the roles involved. Having said that, I still don't see how you answer the question. I explicitly said that the definition of a PO is not subject of the question as there's already enough information about that readily available.
    – starbugs
    Commented Nov 1, 2018 at 21:33
  • 2
    Welcome to PMSE. I downvoted because this was a well-written answer that missed the point of the original question. I'll be happy to change my vote once the etymology (or at least differentiation) of the "ownership" term is addressed more clearly.
    – Todd A. Jacobs
    Commented Nov 3, 2018 at 15:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.