The Product Owner Role
Who is suited to the needs of the role?
6 October 2015
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
An ideal product owner is one who can play the dual roles of strategic decision maker and tactical decision maker. A strategic decision maker is one who is empowered to make market-facing decisions that affect the next set of products and functionality being developed. These decisions could be based on a number of factors, such as long-term vision, budget, and enterprise-wide budget constraints. Senior executives usually are the ones who fit into this role. The tactical decision maker is one who gives the delivery team direction and feedback at a more granular level during the product's life cycle.
It is not at all practical to have a senior executive guide the team daily. Moreover, when multiple teams (using small Scrum teams) are required to build a product, it would not serve well to share a product owner across multiple teams. One of the most effective solutions is to define a hierarchy of product owners: tactical, team-level product owners who work with both the teams and business users to implement the decisions of the strategic product owner. The norm is that whenever we discuss the role of the product owner, we are really talking about the tactical product owner.
Organizations adopting Scrum have business analysts, business systems analysts, systems analysts, and architects who usually assume the role of the tactical product owner. Who among these is best suited for the product owner role of a delivery team?
A shared understanding between the business users and the development team is a key factor for the success of any product development. If business requirements are user stories, and their implementations are working software codes, then the interface between them could be flow charts, flow diagrams, algorithms, mock-ups, or other aids. These supporting artifacts are necessary because it is not always possible to directly write and test code from user stories through ensuing conversations.
Following this logic, it is only expected that a business analyst would lean more toward producing a business requirement artifact, as a systems analyst would lean toward producing a technical design artifact. Having teams communicate and understand their goals through two different artifacts is high risk and a recipe for failure. Based on this reasoning, a business systems analyst would be the ideal role that could fill the shoes of the tactical product owner. The skills of a business systems analyst are better able to serve both the business teams and the development teams. I have experienced this firsthand. Having a business systems analyst has provided the much-needed cushion for smooth product development, without too many surprises.
Current rating: 3 (1 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.