Refactoring the Product Owner

 

In theory, the agile Product Owner is a simple yet compelling solution to a tough problem: the development team needs, and often does not get, clear direction from the business. The ability to eliminate the confusion caused by the cacophony of voices of multiple stakeholders, and the ability to have continuous engagement with the business, certainly make the Product Owner attractive to the development team. And the business benefits, too: they, in theory, get continuous visibility into project health and status. Buried in that last sentence is the phrase that often sinks good ideas: "in theory", and therein lies a problem.
 
When we are developing software and find components that have responsibilities too broad for one component to encompass, we "refactor" it, breaking it down into a set of components with more manageable and cohesive sets of responsibilities.  We have an analogous problem with the Product Owner, whose responsibilities are so broad as to be nearly impossible for one person to fulfill.  In brief, the Product Owner is expected to:
 
  • Understand the needs and desired outcomes of the business
  • Negotiate consensus among stakeholders
  • Represent the interests of all stakeholders to the development team
  • Define the characteristics of solutions that meet the desired outcomes
  • Be a change agent in the organization to support the solution
  • Communicate and promote the vision to all interested parties
  • Define and prioritize items on the Product Backlog
  • Drive iteration and release plans
Read more