Last week’s post entitled “The Scrum Title ‘Product Owner’ must die!” on changes to the Scrum “Product Owner” title and responsibilities drew a lot of comments and feedback. 
Some agreed, some disagreed, but clearly there is much room for improvement in how that role is defined and implemented.
And thus the genesis of this post. It’s time to provide a better, more applicable and less convoluted description of the “Product Owner” role so that companies who are implementing Scrum can do so with far less confusion and tumult in their organizations.
One reader, Rohan, left a great comment that is worth repeating and discussing.
Given that the role of Product Owner is a requirement in Scrum, and given that the name “Product Owner” is well established there, I think that “must die” is admirable but futile. I think we have a much better chance of success if we focus on educating people that Product Owner is a role, not a job title, to be filled by someone with a real job title like (in many/most cases) Technical Product Manager. Then the existence of the term “Product Owner” can be limited to members of the Scrum team, and the rest of the world can be spared. That is, I don’t think we can kill the term, but we can quarantine it.
Well said Rohan. I must say that the “must die!” title of the previous post had a lot to do with having a provocative title to draw readers. I think it worked. 🙂 And while it’s true that it would be difficult to displace the name “Product Owner”, it doesn’t hurt to get people thinking about it. But I have to agree that quarantining it is much more likely to happen. So, let’s get started.
The problems with the current definition
To review, I saw two problems with the “Product Owner” title and description. In short they were the title and the description. But seriously…
- The name “Product Owner” and particularly the word “Owner” causes confusion when Scrum in implemented. Does anyone actually “own” the product? And if so, is that person (most likely someone very senior) going to spend time with the Scrum team, in daily standups etc.? No.The name derives from the Engineering-out view of the company. i.e. Engineers want “one throat to choke” when it comes to business requirements and ensuring their work aligned with “the business” side of the house. i.e. from their perspective, that person is the owner of the product, regardless of whether that is the case in the company at large.
- The responsibilities of the “Product Owner” (as defined by Scrum and it’s advocates) are a convolution of business and technical, strategic and tactical responsibilities, that in reality are never seen in a single individual role. There needs to be a distinction made between what the “Product Owner” actually does and what he/she represents.
BTW, in researching what others had written on this topic, I came across this series of posts by Luke Hohmann on why prioritizing backlog by ROI doesn’t make sense. Luke is no outsider when it comes to Agile and Scrum and this series of articles is worth reading.
Constraints for a new defintion
So, back to the topic at hand. Given the issues with the Product Owner definition, how can it be changed to be better and more clearly defined and applied within environments? Let’s look at some of the constraints that the definition must fit into.
- It must cover both internal IT projects and commercial products, and also be relevant to applications built for specific customers by consultants.
- It must focus on the need for ongoing business input into the development process
- It doesn’t define a new role that duplicates existing roles.
- It must adhere to the Scrum requirement of a “single throat to choke”
- It must be a job that can actually be done by one person. No superheroes required
The new (and better) defintion
Given these criteria, here’s a proposed NEW and (IMHO) better definition of Product Owner. To compare and contrast, read the Jeff Sutherland definition in my previous article.
1. It’s a Role not a Title
The “Product Owner” is a role (and not a title) aimed at addressing a key problem that has historically plagued software development projects: that being the gap between business priorities and the work executed by software development teams. The result of this problem is a long history of projects and products that did not meet customer or market needs and that were either delayed or required extensive additional work to meet requirements.2. Primary interface to the Scrum Team
The “Product Owner” is the primary interface of the business with the Scrum Team, and is responsible for ensuring a prioritized backlog is maintained so that each successive Sprint can be planned clearly and efficiently.3. Actively addresses ambiguity and change
Given that requirements can be open to interpretation, and business priorities can change over the course of a project, it is imperative that a representative of the business be actively engaged — ideally on a daily basis — with the Scrum team to ensure development decisions stay aligned with business needs, and any issues that arise are addressed as quickly as possible.4. Different titles can be “Product Owner”
For internal IT projects, the “Product Owner” may be represented by a Business or IT Analyst or even a direct End-User representative. For products targeted at wider markets, the “Product Owner” may be part of the Product Management team – e.g. a Product Manager or Technical Product Manager. And for consulting projects, it’s likely that the “Product Owner” is a direct representative of the end customer and not a proxy for them.5. Is most likely NOT the sole business decision maker
It is understood that the “Product Owner” represents the business needs to the Scrum team but may not be the sole decision maker in the business priorities. i.e. While they interface with the Scrum team on one side, they will be interfacing with other parts of the business, or in fact directly with the end customer.6. Must be technical enough to deal directly with the Scrum team
Given the technical nature of software development, the “Product Owner” should have a sufficient technical background to engage with the Scrum team when technical issues arise that impact delivery of business requirements. This does not mean the “Product Owner” has to be as technical as a Developer, but sufficiently knowledgeable to fulfill the bridging role between the business and technical sides of the project.7. Not necessarily the ” single throat to choke” from a Scrum team viewpoint
While the Scrum team views the “Product Owner” as THE representative of the “customer” — singular or multiple — and their requirements, this cannot be universally true. While it *may* work for a given project for a particular (singular) customer, when it comes to software products targeted at market segments, the “Product Owner” may not have full authority for all decisions needed to be made and thus the Scrum team must be aware that some issues will need to be escalated up the chain to more senior people in the Product Management or Executive team.
So there you have it. While not as short as I would have liked, the above definition meets the constraints set out earlier in the post. It’s clear to me. What do you think? Does it address the “traditional” problems with the “Product Owner” role? Does it create any new ones?
Saeed
Tweet this: A new (and better) definition of Product Owner http://wp.me/pXBON-2y8 #scrum #agile #prodmgmt