Role of Product Owner

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?