If You Aren’t The Caretaker, Why Are You The Product Owner?
The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Discover how HP Agile enterprise solutions can help you achieve high predictability and quality in your development processes by knowing the status of your projects at any point in time.
Agile and Scrum has done a horrible and irreversible injustice on software culture with it’s term - Product Owner.
The definition of Product Owner straight from Mountain Goat:
The Product Owner (typically someone from a Marketing role or a key user in internal development) prioritizes the Product Backlog.
Scrrrreech. Repeat that? Don’t see the problem yet? There are really two pieces here, so let me explain.
The first flaw is in the semantics of the word - owner.
owner: to have or hold as one’s own; possess - Dictionary.com
In short, we have mislabeled this role to begin with. The person who “owns” the product (i.e. the business, a CEO, or in Mountain Goat’s definition some Marketing role) is more appropriately the person who has financially paid for and owns all legal rights to the software. I would wager that 99% of software projects are not consumed by the legal owner of the end product, but by a subordinate.
This leads me directly to my next point [that I find it ironic] the term Product Owner has become synonymous with the role of being the person who is responsible for the delivery of the product. In most cases, this is the true legal owner (or someone who is very accountable for the time and money spent).
So here is the big question: Product Owners are not responsible for the long-term care and usage of it, so why are they in charge of the delivery of it?
Contextually, it is absolutely no different than a father who test drove, purchased, and owns a car he bought for his child with only a small amount of verbal input. From a salesman perspective, I want to know what the father says, but as an engineer I want to know what the child wants! Adding salt to the wound, we now have processes centered around a social antipattern which are appropriately mislabeled.
In all reality, I know we will never be able to break the habit of the people accountable for the project budget wanting to be involved in the process. They need to receive a false sense of assurance that the software will delivered and they will get what they paid for. However, I do believe by correctly labeling the most active role to something more representative of the person we want to engage in a meaningful client relationship with, we can reverse the trend of placing so much emphasis on the “when” and more on the “what” and for “who”.