Agile Product Owner and Agile Product Manager in the Enterprise: Part 2- A Dual Role Approach

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.

  

Agile Product Owner and Agile Product Manager in the Big Picture

Agile Product Owner and Agile Product Manager in the Big Picture

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

Summary

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.

One thought on “Agile Product Owner and Agile Product Manager in the Enterprise: Part 2- A Dual Role Approach

  1. Good post!

    Yeah, you need to be careful in your organization about titles, that’s true. Now when it specifically goes about software outsourcing – roles undergo even more transformation. For instance, business analyst is part of an outsourcing team and in 99% would never be making sort of a decisions POs do. PO is on customer’s side. Often that’s a serious difficulty when the team is not authorized to make decisions and at the same time PO doesn’t haul the burden either.

    It’s very important subject because agile is for 55% product owner and everything else for remaining 45%. And the role is equally important whenever this is in-house team or offshore one. You know, I noticed they don’t talk so much about agile masters as about POs. Wrong: they talk a lot but they’re not so worried about it. But there’s no certification for POs, there’s no so many trainings-mainings-brainings for POs and yet this is the most important role in the entire game.

    I think that it’s all gonna happen evolutionary here. Decades ago there was no testers per se. Nowadays testing is extremely deep discipline and the role of tester is something way too natural for the software team. I think PO is just on its way and in respect to that this is great times because we can see how the concept and the role is jelling and this post is witnessing that.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s