Note: This is part of a new and continuing series which is collected under the Product Owner/Product Manager category.
In the last post, Agile Product Owner and Agile Product Manager in the Enterprise: Part 1- On Product Owners AND Product Managers , I described how both of these roles and titles are likely to exist in the agile enterprise. In an attempt to avoid this apparent complexity, I described two alternate, but ineffective plans A and B.
- Plan A) – The Product Manager will assume the role of the Product Owner and add Responsibility 2) (i.e. The Scrum Product Owner is a member of the team and works daily with developers and testers to help the team meet its Sprint objectives) to their existing responsibilities.
- Plan B) – The Product Owners on the new agile teams will now assume some or all of the prior role and responsibilities of the Product Managers.
Experience has shown that neither of these paths is particularly effective and a more nuanced, Plan C approach, is required.
Plan C – The Dual Role Approach
With Plan C), a number of enterprises have taken a more refined approach which supports dual roles of Agile Product Manager and Agile Product Owner as follows:
- The more market(/customer) facing Product Managers continue in their role, keeping most of their existing responsibilities. However, they also evolve a far more agile set of practices, including taking on a tighter relationship with the development team (in large part via a “fat dotted line relationship” to the Agile Product Owner) and engaging more directly in release planning content and validation.
- The product (/technology) facing Product Owner role is assumed by either; a) more technically inclined Product Managers; and b) development team members and/or others who are interested and best suited for Responsibility 2. (Note: Since, in the enterprise, there can be a number of them (10-20-50) required; where these people come from is the subject of an upcoming post). The team members in this new role assume the fairly well defined agile PO responsibilities but also take on a tighter relationship with Product Management (the fat dotted line we described above). A side benefit of this approach is that it empowers the development team to take additional control of their destiny. It can also provide a new career path for those team members who would like to “grab hold of the steering wheel” in the increasingly agile enterprise.
The Name Game – Experimenting with Roles and Titles
In the prospective agile enterprise, it doesn’t usually take very long for the loaded role/title and implied responsibilities of a new “Product Owner” to portent a major crisis. Indeed, it can even be such a sensitive matter that the agile adoption can be seriously endangered by the potential conflict in role, title and responsibilities, so serious caution is warranted!
One way to address this problem is by changing the title of the Product Owner role. In a couple of instances, for example, the role of agile Product Owner was assumed by the existing role and title of the business analyst, who already had most of those responsibilities and had even already been relocated to be collocated with the newly formed agile teams. In other cases, the historical title of requirements analyst was assigned to the role. In yet another example, (see BMC Case study), a new title/role of requirements architect was invented, which helped clarify the role and helped avoid conflict with existing titles role and responsibilities. Of course, none of these titles fit every context perfectly and in changing the title of Product Owner is likely to be more trouble than it’s worth, since it isn’t reflected in agile literature or in the standard trainings available.
Even then, some confusion can result. For example, Keith Black, who as VP Product Development at TradeStation Technologies is driving a comprehensive agile initiative, recently described the problem to me this way:
“we’ve clearly found that the role of PO is NOT a PM. In fact, this has led to difficulty in us even describing the position in help wanted ads. If you run an ad for Product Owner you get responses from people that want to be a Business Owner. If you run the ad for PM’s you get traditional PM’s that are not technical. We could call the role “Analyst” or “Requirements Analyst”, but that attracts more of a Systems Analyst profile. And given the fact that there’s a void in the PO role in the Scrum world, it creates a situation where no-one is out there who understands what the title means.”
So for many enterprises, the role/title of Product Manager continues and the new role of agile Product Owner is adopted, but each has a refined set of responsibilities as we have described here.
Dual Roles in the Big Picture
The dual role approach isn’t that new to this blog and has already been indicated and described in the Agile Enterprise Big Picture series and graphic as this figure indicates.
While the details of the Big Picture are outside the scope of this post, (for this, see Big Picture category) a few relevant highlights include:
- Product Managers tend to operate at the Program Level, providing vision that drives a significant number (5-10-20 and more) of agile teams. Their “currency” of system behavioral description is most typically Features.
- Product Owners live at work with the teams at the Project level. They work with only one (two is also fairly common) teams typically. Their “currency “of system behavioral description is User Stories.
Dual Roles: Differentiated Responsibilities
Within the enterprise context, we often see the two roles align as follows:
Agile Product Manager
Agile Product Owner
|Market/Customer Facing||Product/Technology Facing|
|Collocated & Reports to Marketing/Business||Collocated and Reports to Development/Technology|
|Focuses on market segments, portfolio, positioning, ROI||Focuses on Product and Implementation Technology|
|Collaborates with Product Owner||Collaborates with Product Manager|
|Owns the Vision||Owns the Implementation|
|Drives the Release||Drives the Iteration|
In these first two posts in this series, I’ve describe a more nuanced, dual role approach to the agile Product Owner/Product Manager functions in the enterprise setting. In the next few posts, I intend to describe:
- The key attributes and day to day responsibilities of the Agile Product Owner
- Some tips for building a successful collaboration across this new APO and APM team of teams.
- How and where real agile enterprises go about finding the right people to fill these roles
And then eventually,
- How the Product Manager’s responsibilities also need to evolve in the agile enterprise
And probably some more stuff by the time I get there.