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
- Ensure resources outside the team are available when needed
- Ensure that the development team delivers value to the business
- Contribute to requirements definition
- Participate in design reviews and demonstrations of progress
- Escalate issues to stakeholders when needed
- . . . and the list goes on
When we look at this list, we see some very different categories: some strategic, some tactical; some requiring the ability to lead, some requiring deep subject-matter expertise. We also see a set of responsibilities that compete for the Product Owner's time: one person cannot be all places at once, and there are potentially several full-time jobs lurking in this list. Working with the development team is at least a full-time job, and coordinating with stakeholders can be another job that, on a large and complex program, can be more than full-time as well. Even on a small project, the skills required to master these responsibilities are different enough that it is rare, if not impossible, for one person to do all these things well.
Coming back to the concept of refactoring, there are at least three different sets of competencies buried in the typical Product Owner's responsibilities:
- Change Leadership, which requires communication and motivational skills, and the ability to build the coalitions and agreements necessary to drive organizational change
- Solution Vision, which requires the ability to understand the root causes to problems and desired outcomes of the business, and the ability to envision potential solutions, and
- Tactical Execution, which requires the ability to understand and communicate the details needed to realize the solution vision, and to work with the development team to make the vision a reality
Typically, Product Owners focus on the tactical execution, but without solution vision and the ability to communicate and sell that vision across the organization (or to customers), the results produced fall short. Steve Jobs had the ability to excel in all three of these areas, but how many Steve Jobs are there? If success requires an almost impossibly rare blend of abilities, we are setting ourselves up for failure.
Clearly, some refactoring is needed. I'll be exploring this topic further in an upcoming webinar. I'm also interested in hearing how you have solved these problems in your organizations. If you've come up with some useful solutions, please leave your comments here, or you can reach me at firstname.lastname@example.org.