What is the origin of the term "Product Owner" in Scrum?

Question

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.

Answer 1

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.

Answer 2

TL;DR

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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

Answer 7

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/