The Product Owner Role Revisited
Posted on Wed, Dec 12, 2012
by Dan Williams
The role of the product owner is understood as critical to fulfilling the goal of delivering products of value to the customer. Since the official beginnings of Agile, this role has also been one of the major pain points in actually providing that value.
To explain, the product owner is one of the three original roles identified in Scrum, along with the team and the ScrumMaster. The role is analogous to that of customer in eXtreme Programing (XP). But what is the purpose of the product owner role? What problem is the introduction of this role, identified as a critical part of both Scrum and XP, trying to solve? [1]
The role of product owner was put forward as a solution to the problem of poor and changing requirements from multiple stakeholders, which sometimes makes the production of quality software next to impossible. The product owner would become the representative of the stakeholder community. He or she would gather and communicate requirements to the team, representing the stakeholder community with a ‘single voice’. This would remove ambiguity and foster improved communication between the business and the developers. Great idea – but what happened?
The role has generally not materialized in businesses attempting to implement Agile software development techniques. The role of product owner ideally combines a development team-facing perspective and a stakeholder/customer-facing perspective. Attempting to combine these two perspectives has been shown to present herculean issues for the person trying to actually perform the role – namely empowerment and representing the voice of the customer.
The first issue is that of empowerment. When describing the role in the first book on Scrum, Ken Schwaber and Mike Beedle state that the product owner is fully empowered to select and prioritize the features making up the product backlog. [2] It turns out that this proposal, which on the surface sounds like a good idea, often doesn’t work out well.
Empowerment sounds good because it reduces the number of communication channels and invests one person with the authority to make decisions quickly. This increased simplicity in communication and speed of decision-making is welcome news to development teams, which need quick turnaround on questions of prioritization and details concerning work in progress.
But it doesn’t work out well due to the number and complexity of stakeholders needing to provide input to the development team and due to conflicts over feature prioritization and design. This short explanation will be expanded in another blog article, but the facts are that, with few exceptions, the empowerment of the product owner is sadly lacking and so the development team is still, often, receiving mixed messages regarding design and priorities.
The reality is that the product owner, or customer proxy, as the role is sometimes called, must still meet with and coordinate multiple internal stakeholders as well as attempt to understand the marketplace and the external customer if applicable.
In the next post, I will discuss the second issue concerning the product owner role: representing the voice of the customer.