Agile Product Responsibility in the Enterprise, Part 4: Building an Effective Product Manager/Product Owner Team

• By Dean Leffingwell
• Feb 24, 2010

From the author of

Scaling Software Agility: Best Practices for Large Enterprises

My article "A Contemporary Framework for Agile Product Management in the Enterprise" discussed a framework for Agile in the modern enterprise. In the first three parts of this series, I discussed the first three of four Agile-specific responsibilities for the product manager:

• Own the vision and release backlog.
• Manage release content.
• Maintain the product roadmap.
• Build an effective product manager/product owner team.

This article concludes this series by describing the specifics of the fourth responsibility, building an effective product manager/product owner team.

An Off-Balance Relationship

In the Agile enterprise Big Picture, shown in Figure 1, the "steering wheel" that guides the enterprise to its product outcomes is the relationship between the Agile product owner and the Agile product manager.

Figure 1 The "Big Picture" of enterprise agility.

From a reporting standpoint, I've often described the most typical relationship between the individuals in these roles as a "fat dotted line" (see Figure 2).

Figure 2 "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 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 do the following:

• Attend most relevant product management meetings, functions, and planning sessions.
• Receive input with respect to career growth and performance.

There's a natural tension in this relationship, because the needs of the key constituents (development team vs. customers/market) are quite different:

• Product managers naturally want more features, more quickly. From a market perspective, there's no upper limit to their demands.
• Product owners and development teams naturally want the same thing (more features, more quickly), but are sensitized to the inevitable technological, architectural, and quality constraints that are endemic to every large-scale software application. They'll tend to focus on technology, architecture, and refactoring priorities. From an engineering perspective, there may be no upper limit to their demands!