One of the primary lessons we have learned from the agile movement, is that in order to rethink the development process from an organizational perspective, it is sometimes easier to start with a blank slate than it it is to “edit down” or “refactor” the existing organization. Scrum does this implicitly with a basic postulate that there are only three primary roles in a development team, the Product Owner, the Scrum Master and the Team. Of these, the Product Owner and Scrum Master are new and unique roles in Scrum/agile and most of us agilists have come to appreciate the power of this over-simplified paradigm.
And yet when we reach enterprise scale, the world tends to look a little different and things are a little more complex. Indeed, when developing software at scale, EVERYTHING is a little more complex and ignoring that complexity may be a recipe for real trouble. My friend and coworker, Jennifer Fawcett has been my collaborator on one particular agile project (see and try the product at www.proquo.com), and she has come to the conclusion that the the traditional product manager role in an enterprise is not particularly well suited to assuming the product owner role. This mirrors my experience in larger scale organizations as well, where we typically find a relatively small team of dedicated product managers who spend their time with the marketing, sales, and customer teams and may have little time or even inclination to assume the dedicated, team-based responsibilities of the product owner role. Recently, Jennifer described her perspective in a blog posting at http://agileproductowner.com. I repeat some of her conclusions here:
“I advocate that are two product-related roles within an agile enterprise:
- The Enterprise Product Manager, who typically reports into marketing, and who owns the RELEASE
- The Agile Product Owner, who typically reports into engineering, and who owns the ITERATION
The Product Manager’s goal is to deliver products to the customer, based on customer needs. While this is an over-simplification of what Product Managers do on a day to day basis (we know they provide the vision, prioritize the work, analyze the market, provide pricing, promotion, packaging, etc), delivering quality product to market is their primary objective.
The Product Owner’s goal is to deliver upon the Product Manager’s commitment to the release plan. The Product Manager represents the customer, and is also the customer to the Product Owner. Product Owners literally “live” with engineering and write and elaborate stories, to make sure the features of the release are met and demonstrable, on a prioritized feature by feature, story by story, and iteration by iteration basis. These two roles have direct impact on the success of a release, and both are needed within an enterprise agile organization.”
She further goes on to describe this paradigm in chicken and pig constructs, with the product owner being the pig at the iteration level, and the product manager being the pig for the release. This corresponds nicely to the two levels of planning described in Chapter 10 of SSA and provides us with further guidance as to how to facilitate and manage the release and iteration level plans and activities. With this construct it becomes clear that the product manager drives the release (all elements-vision, planning event, tracking, roadmap, etc.) , and the product owner owns the iteration (all elements-planning, elaboration, execution, acceptance, etc.).
It’s solid thinking and I suggest that you may want to spend a few minutes reading her blog posting on the topic.