Note: this is the sixth (and probably last) in a series of posts (agile product manager category) on the changing role of product management as the enterprise transitions to agile development methods. This series in turn, is a continuation of the series on the Role of Product Manager and Product Owner in the Agile Enterprise which can be found in the Product Manager/Product Owner series on this blog as well as a series in the Agile Journal. (See the resource page for a mapping to the Agile Journal Article Series).
In an earlier post, Agile Product Manager in the Enterprise (2): A Contemporary Framework, and in earlier works, I described a framework for product management along with a separation of roles for the Agile Product Owner and Agile Product Manager in the enterprise context. I concluded with a suggested set of agile-specific responsibilities that are different than the activities in a pre-agile world. To reiterate: they are:
1. Own the Vision and Release Backlog
2. Manage Release Content
3. Maintain the Product Roadmap
4. Build an Effective Product Manager/Product Owner Team
In prior posts, I’ve described Responsibility 1- Own the Vision and Release Backlog, Responsibility 2 – Manage Release Content, and Responsibility 3 – Maintain the Product Roadmap. In this post, I’ll describe the specifics of Responsibility 4: Build an Effective Product Manager/Product Owner Team.
————–
Building an Effective Product Manager/Product Owner Team
The Big Picture of Enterprise Agility
In the agile enterprise Big Picture, the “steering wheel” that guides the enterprise to its product outcomes is the relationship between the agile Product Owner and Agile Project Manager.
From a reporting standpoint, I’ve often described the most typical relationship between the individuals in these roles as a “fat dotted line”.
Fat Dotted Line Reporting Structure
Product Managers typically (but not always) report into marketing or business; Product Owners typically (but not always) report into development. However, to make the enterprise steering wheel actually work correctly, Product Owners are also honorary members of the Product Management organization from whence they receive overall product direction. In this role, they may also:
- Attend most relevant PM meetings, functions, and planning sessions.
- Receive input with respect to career growth and performance.
Of course, there is a natural tension in this relationship as the needs of the key constituents (development team vs. customers/market) are quite different.
- The Product Managers naturally want more features-more quickly and from a market perspective, there is no upper limit to their demands.
- Product Owners and development teams naturally want that too, but are sensitized to the inevitable technological, architectural and quality constraints endemic to every large scale software application. They will tend to naturally focus on technology, architecture, and refactoring priorities. From an engineering perspective, there may be no upper limit to their demands!
Needed – A Sense of Balance
This natural tension is a direct delegation of the larger business-versus-technology enterprise balancing act:
- If the business (Product Management) solely has its way, it’s likely that expediency of value delivery will rule and technology/product infrastructure investment will get the short stick. After all, what business owner would not want to accelerate value delivery for current customers at every opportunity? When this happens, the product becomes brittle over time, and eventually it is impossible to implement major new features without major refactoring (or worse).
- If technology (Product Owner/team) solely has its way, there can be little doubt that the product will be built on sound (and the latest!) technology without short cuts or quality compromises. But the business value delivery may get the short stick. After all, what technologist wouldn’t want to build the most extensible and reliable platform to support future customer needs? When this happens, the current pace of value delivery may lag other competitors in the marketplace and marketshare will suffer (or worse).
So the best we can do is first recognize and balance these competing interests and occasionally let the balance tip a little this way or that (refactoring vs. new value stories) based on the current business and solution context.
Needed: A Sense of Balance
Perhaps more importantly, this friction is both a necessary and productive facet of the enterprise, for it is in the heat of this natural friction and its constant resource constraints, that the sparks of true innovation and creativity are born.
Write less code-accomplish more!
Ingredients for an Effective Relationship
In earlier posts, Jennifer Fawcett (agileproductowner.com) has commented on how important it is to build an effective relationship amongst these teams. She noted that the essential ingredients for building the ultimate Agile Product Owner/Agile Product Manager team are Collaboration, Partnership and Trust. Together, we provide a few tips for building these essential ingredients:
Collaboration – An addition to the joint, enterprise release planning functions, teams must synchronize and communicate the ever-changing corporate priorities daily. POs should invite PMs to attend daily stand-ups on occasion. Politely insist on attendance at most/all demos. Have an “open door” policy for all development and product management meetings. If one party cannot attend, summarize results in minutes or email. Communicate constantly.
Partnership – Ask each other “How can I help?” Create and participate in after hour events to eliminate any us – vs. – them thinking. Prepare for release planning together. Operate under the “never surprise each other in front of others” rule.
Trust – Trust each other to make the right decisions. When (not if!) your APM/APO partner makes a decision that is opposite of yours, support that decision. Meet your commitments to each other. Teams will recognize that you are both empowered, that you will always act as a team and “cover each other’s backside” and that you can both be trusted with business decisions and authority.
Summary
This concludes this series in the the Role of the Product Manager in the Agile Enterprise. I’m not sure what I’m going to write about next, but I’ll let you know when I figure it out.
Scaling Software Agility 