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 Sep 6 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 Sep 6 at 14:59
up vote 3 down vote accepted

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 Sep 6 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 Sep 6 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 Sep 6 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 Sep 6 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 Sep 6 at 16:01

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.

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.

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

  • 1
    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 Nov 1 at 12:23
  • 2
    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 Nov 1 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 Nov 1 at 17:21
  • @starbugs yes, Scaled Agile came later but has a lot of good insight into best practices and has some of the clearest guidance. I started developing in the 80's and remember when the agile manifesto was created in the 90's and saw how teams struggled, learned and adapted its use. It appears you're struggling through some anti-patterns and I offered SAFE as a good resource for you to help your team move beyond personal control to servant leadership. Some of the diagrams in SAFE really provide good clarity at least for me when I'm explaining to other people. – eAndy Nov 1 at 17:33
  • @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 Nov 1 at 21:33

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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