Enterprise Agility–The Big Picture (3): Role of the Product Owner

Note: In the post Enterprise Agility: The Big Picture, we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In prior posts, we’ve discussed teams and iterations. To see the full series, select the “Big Picture” blog post category.

In this post, we’ll describe the Agile Product Owner [callout (3)].


Big Picture 3 - Product Owner

One of the nice things about blogs is that the usage statistics show where peoples interests (at least those who read your blog) lie. In this blog, there is typically a high degree of interest in the Product Owner and Product Manager posts and they appear as the most frequent search terms as well. So as I endeavor to put my summary thoughts down here, I promise myself to return to this topic for some future, more in-depth, posts on this critical topic. For my other current posts on this topic, check here.

For now, however, since this series is about the Big Picture and the Product Owner is just one element, we’ll have to be content with the highlights. Relative to the Big Picture, I’ll describe three facets of the product owner role here- responsibilities, attributes and organization.


Manage the Iteration Backlog – The primary responsibility of the product owner is the development and maintenance of the iteration backlog. The iteration backlog is the repository for all user stories that are currently envisioned to address the user’s needs. The Product Owner owns this key artifact. That means they can add, delete or update as necessary to control the scope and content of the implementation. At the end of each iteration, the product owner reprioritizes the backlog for the next iteration and this continues for as long as the product (or application) serves its marketplace. (The iteration backlog itself is the topic of the next post).

Own the Iteration – In the Big Picture graphic, the Product Owner is located next to the iteration backlog. This illustrates the “near total immersion” of the product owner in the day-by-day, week-by-week delivery of core functionality via iterations. In addition, the product owner is typically the customer and Q/A proxy at iteration demos and is empowered to accept individual stories and the iteration as whole. So the product owner owns the iteration.

Collaborate with Product Management– As implied in the Big Picture, the strategic direction for the product line is typically driven by the enterprises Product Managers, who are aligned most closely with the customers and the market. So in addition to the team-based responsibilities, the Product Owner engages in a continuous collaboration with the Product Managers, determining priorities and tradeoffs. In many organizations this creates a “bold dotted line” of management reporting and this larger team steers the enterprise to its destination. In other organizations, the Product Owners are the Product Managers or report into the same organization. (see below).

Attributes of the Product Owner

Ability to communicate– the product owner is the glue chip that seamlessly binds the product management function and the development team. Doing so requires the best possible communication skills as the product owner translates, via the user story metaphor, user and business objectives into the technical terms the teams understand. Moreover, the product owner will almost certainly be involved in customer demos, sales support and the like, so a bit of polish and some customer friendly skills go a long way to enhanced performance in this role.

Technical Skills – effective scope triage requires the constant evaluation of technical, functional, performance and user-value tradeoffs. This in turn, requires a reasonable degree of technical competence as the language of discussion and the foundation for effective decision making is driven by the technology of the implementation. In addition, continuous refactoring is integral to agile, and since the product owner owns the backlog, prioritizing refactors vs. value stories is a critical skill that requires a technical foundation.

Trust – in many enterprises, the product owner is a new role, as the company discovers that the high velocity of elaboration and the need to be bound to the team for story and iteration acceptance outstrips the product management organization’s ability to keep up. Given the nature of this pivotal role, most agile enterprises end up promoting people from the development teams to fulfill this role. Since the primary responsibility for prioritizing and managing the backlog (i.e. what will and will not be done) falls to this role, the most essential quality is trust. The teams have to trust the product owner to make the hard calls on scope triage and to defend their interest in quality and functionality; the product managers have to trust the product owner to faithfully represent their feature priorities to the team.


This one is easy. In order the prevent the organizational schism (read: dysfunction) that can be so easily created in translating market requirements into technical requirements and, even more importantly, to assure that the accountability for timely delivery rests with the team, the primary “binding” of the product owner in the organization is to the development team. This means that the APO should be 1) collocated with the team and 2) held to the same performance measures as the team. In most enterprises that mean that the product owners also 3) reports into the same line management as the team. However, in my experience 1) and 2) are mandatory, 3) is only convenient. In any case, I intend to leave no ambiguity to my opinion that the agile product owner is part of the development team.

In the next post, we’ll discuss the Iteration Backlog in more detail.

8 thoughts on “Enterprise Agility–The Big Picture (3): Role of the Product Owner

  1. “This in turn, requires a reasonable degree of technical competence as the language of discussion and the foundation for effective decision making is driven by the technology of the implementation. In addition, continuous refactoring is integral to agile, and since the product owner owns the backlog, prioritizing refactors vs. value stories is a critical skill that requires a technical foundation.”

    Sorry to disagree, but you seem to be espousing a separation between PM and PO, and your definition above of a “Product Owner” sounds like nothing more than a renamed Tech manager.

    Perhaps having the PO report directly to the PM as malamo suggests above would help somewhat, but overall this sounds very contrary to the idea of self-managing Scrums.

  2. I want to expand a bit on the concept of trust. Agile forces a very interesting and powerful change with the Product Mgt and Development relationship. For years, it’s always been the same story – PM asks for too much and Development delivers too little. It’s been a conflict since the beginning of time and it’s always the other person’s fault.

    For the context of this post, I am going to declare one big assumption: that the product owner is properly skilled and has all the leadership characteristics listed above. The one I will add is that they should be a natural leader – more than anyone else, I believe the product is the person most responsible for keeping the team focused, motivated and engaged.

    A good product owner changes the conflict mentioned above – completely. Their alliance is with the team and as a result, the conflict switches from PM vs. Development to PM vs. PO. The PO is the person responsible for ensuring product management is happy with the results. I have seen numerous situations where the PO has passionately defended the team’s performance. It’s a wonderful thing…

    The product owner is also responsible for fostering and maintaining a solid relationship with the PM. If this doesn’t happen, it will create significant issues because ultimately the true stakeholders will start to question the ability for agile to deliver better results. The PO becomes the bridge between PM and Development. The PO understands with specificity what it takes to develop SW.

    As a result of this shift in conflict, I personally believe all POs should report under the Product Management organization and NOT under development. Nothing changes from what Dean posts above – it’s all still critical. The PO should be collocated. The PO’s alliance is with the team. However, the dotted line (or direct line) relationship to the PM creates a needed balance of power.
    We are not structured in this manner and we are seeing issues with decisions on priorities, etc. In most cases, it’s been a situation where the PO doesn’t report to the PM.

Leave a Reply to malomo Cancel 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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s