Organizational Insights and Comments on the Agile Product Owner Role

Mike Cottmeyer ( recently added some insightful comments on this prickly topic that I thought were worth highlighting.

I am coming to the conclusion that the Agile PO is actually three roles combined: the traditional Product Manager, the Project Manager, and the Business Analyst.…. how do we decide who is the single accountable person for the team, even when the team is small.   It seems that the Agile PO is collaboration between Product Manager, BA, and Project Manager… with maybe someone playing multiple roles. That is on a small team…. what about now at scale?  Your  PO is really a collaborative effort between a PO (and PM) structure that is likely multilevel, with each level having some combination of the three roles and maybe an enterprise architect.

This comment crisply highlights the challenge and opportunity implied by the critical and yet overloaded role of the PO in agile/Scrum. To wit:

  1. The PO role is an important new construct which provides a single point of focus to the team that defines “what it is we will be building”. Eliminating the problem of conflicting inputs from multiple sources provides a) efficiency leverage for the team, b) enhanced empowerment via team-based control of  product conceptual integrity and c) a clear and unambiguous set of priorities
  2. However, it also creates many problems in the process. After all, how would we expect architects, project managers, business analysts, product managers, etc. to respond to the new rule: “you no longer tell the team what to build or the details of how to implement it, that all must go through the Product owner from now on”.

Wouldn’t we expect this to cause some serious problems? Especially in the larger enterprise context where the roles (and titles) are well established, empowered, likely quite capable, and are codified in the existing HR/career development ladder? No wonder the PO challenge is so great!

However, having said all that, we should make no mistake about the fact that implementing the PO role (largely as defined in Scrum) it is the right challenge for the agile enterprise and it must be addressed for agile success.

You can see more of Mike’s thoughts on this topic at I’ve added his blog to my blog roll as well.


Agile Journal Article Series: The Product Owner in the Agile Enterprise

For those following this blog series, some of this content has been repurposed for a three part series in the Agile Journal. Part I- On Agile Product Managers and Product Owners: A Scalable, Nuanced Approach, has just been published. The content mostly follows what is being published here, but its’ stitched together for a little easier reading and better digestibility. And it’s more portable, too, as you can download it in PDF form.

For those who hadn’t been following the Agile Journal, I’d strongly recommend it as it has diverse and refreshing content in every edition.

My Agile Journal series and this blog series on this topic will continue in parallel, as they serve slightly different purposes. I’ll keep you posted on upcoming journal articles based on this series. In the meantime, this blog series will continue and the next post here will be “Responsibilities of the Product Owner in the Agile Enterprise.” This post is deeper and more specific than the prior posts in this series, and will hopefully be more actionable for the enterprise Product Owner too. It’s out for comments right now so I should have it posted sometime next week.

Agile Product Owner and Agile Product Manager in the Enterprise Part 3: Skills and Attributes of the Product Owner

Note: This is a part 3 of continuing series on the critical Product Owner’s role within the agile software enterprise. My primary collaborators on this series are Mauricio Zamora of CSG Systems, and Jennifer Fawcett of This series, in turn, is in part an elaboration of the broader Agile Enterprise Big Picture series.

Recap of the Dual Roles

In Part 1 & Part 2, we described the critical nature of the role in achieving enterprise agility. We also described how, in the enterprise at least, the responsibilities of the agile Product Owner (as originally and primarily defined by Scrum) is more likely a set of responsibilities that are shared between a significant number of agile Product Owners (APO) and a smaller number of agile Product Managers (APM). Specifically, we described a dual set of roles as follows:

Agile Product Manager

Agile Product Owner

Market/ customer facing Product/technology facing
Collocated & reports to marketing/business (typically) Collocated & reports to development/technology (typically)
Focuses on market segments, portfolio, positioning and ROI Focuses on product and implementation technology
Collaborates with Product Owners Collaborates with Product Managers
Owns the Vision Owns the implementation
Drives the Release Drives the Iteration

This conclusion isn’t particularly startling when you look at some basic enterprise facts:

  1. It can take a substantial number of agile teams (3-5-10 or more) to deliver meaningful end user value, for even a single new feature in a large application
  2. It can take an even larger number of teams (10-20-100 or more) to deliver a release to the market

So with respect to Owning the Vision you obviously can’t have 3-5-10 Product Owners each trying to deliver their individual view of the vision of the feature to the market. Therefore the overall vision for the feature must rest in the hands of someone who has the skills, knowledge time and inclination to work directly with customers to define and validate the feature vision. In most independent software vendors (ISV), this typically rests in the hands of the Product Manager. (Note: In the IT shop, this role is often fulfilled by someone with the title of “Business Owner” or “Project Manager”. In the embedded systems world, the role may often be fulfilled by someone with the title of Product Manager, or Project or Program Manager).

With respect to Drives the Release, the problem is compounded because it can take the collaborative efforts of 10-20-100 agile project teams to deliver a release. Each Product Owner/Project Team contributes their feature, sub-feature or component, but the release itself must be under the vision and governance of a broader authority, most typically the Product Managers/Business owners who are, in turn, working with those who have responsibility for the enterprise portfolio.

So we have concluded that this separation of concerns can bring additional focus to both the vision and the implementation, and the role separation (APO and APM) can be a fairly natural fit for the larger enterprise.

Skills and Attributes of the Enterprise Product Owner

As we have said, this is a critical role in achieving enterprise agility, so the transitioning enterprise will need to find people to fill this role. In the larger enterprise, this can involve the repurposing or placement of as many as 10-20-100 individuals (one PO for every one or 2 agile teams). The primary responsibility of the PO role is to work daily with the team to define the specifics of the intended behaviors of the system and further, to help the team deliver on those expectations. In order to be effective in their role, the enterprise should look for people with four key skills and attributes:

  1. Ability to communicate—the Product Owner is the “glue chip” that binds the Product Management function tightly to 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 details suitable for implementation. Moreover, the Product Owner will almost certainly be involved in customer demos, sales support and the like, so some customer-friendly skills will enhance performance in this role.
  2. Good business sense—Agile’s insane focus on value delivery also demands that Product Owners should have working knowledge of the business domain. In this way, the PO can better understand and define user stories that deliver real value to the end users and establish priorities and tradeoffs for system functionality and performance. If that is not practical, the PO must at least be inclined towards the user and business domain and in general, be a quick study who has demonstrated people skills and general business knowledge.
  3. Technical foundation—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 well as an understanding of how it is that software is actually developed and tested. In addition, as continuous refactoring is integral to agile, prioritizing refactors and defects is important and the PO must be able to work closely with the team to assess quality and schedule impact.
  4. Trust—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 attribute of the Product Owner is trust. The teams have to trust the Product Owner to help them build the right thing; 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 features and feature priorities to the development community.

Looking Ahead

Finding people with these skills and interests and providing them with sufficient mentoring or training is the responsibility of the management team driving the enterprise transition. To further assist in this challenge, I’ll describe the specific responsibilities and activities of the agile Product Owner in the next post. In a later post, I’ll describe some case study vignettes of how some real world enterprises successfully addressed the challenge of finding the right number and right kinds of people to successfully implement this role.

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


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.

Agile Product Owner and Agile Product Manager in the Enterprise: Part 1- On Product Owners AND Product Managers

This post starts a new series on the role of the Agile Product Owner and Agile Product Manager in the Enterprise context. While I, and others, have certainly opined on this topic in this series in the past, the continuing interest, enterprise challenge and controversy (this topic gets more blog hits than any other category on this blog) around these role descriptions in the increasingly agile, larger enterprise compels me to put my thoughts forward in a more structured manner. To this end, I’m starting this new series of posts to elaborate on my experiences in the context of some of the largest software enterprises transitioning to agile methods. Unless I get distracted for some reason, I also intend to turn this series into a more readable whitepaper form longer term. In the meantime, I’ll be spewing it out in post-size chunks. This is the first chunk.


Recently, I’ve had the opportunity to assess progress in a number of large scale agile transformations, touching hundreds and in some cases, thousands, of new agile practitioners. Most typically, these involve comprehensive Scrum training for team members along with training for some number (10-100s) of ScrumMasters. Less typically, they include training for agile product owners, some XP-like technical practices (peer review , pair programming experimentation, TDD pilots, etc) and such enterprise extensions (lean requirements, agile release train, etc.) as have been brought to these companies by enterprise agilists such as myself.

Happily, I can report three common and positive findings:

  • Productivity is going up
  • Time to deliver new features to the market is going down
  • Morale is higher, often times MUCH higher

Not one entity I’ve encountered has any interest in returning to their former practices. So all in all, these enterprises efforts to date are an emerging success and many are now redoubling their efforts to achieve the next level of productivity and quality possible with agile methods. To achieve this, we often assess current results and accomplishments – strengths and weaknesses – and then make specific recommendations for ongoing improvement.

During this process, it strikes me that the critical role of the agile Product Owner is often near the top of the list – though unfortunately it appears most often in the “areas we need to improve” rather than on the other side of the ledger! This finding causes me to reflect on the bigger picture of the agile movement as it “crosses the chasm” to the enterprise and to record my thoughts about the nature of the Product Owner role in the enterprise, along with some specific guidance and recommendations for improving these practices.

In this post, I’ll describe why I believe software vendors need to adopt a nuanced, rather than off-the-shelf, approach to this role; one which empowers both agile Product Managers and agile Product Owners to drive the enterprise to meet its objectives.

The Product Owner in the Enterprise Context

First, it is important to note that I write this whitepaper from my own experiences in the larger enterprise context. While I have also been involved in a number of highly agile, smaller projects, it is in the context of the really large enterprise that the challenge is greatest. It is there that some of the standard, off-the-shelf Product Owner practices and trainings break down, and the otherwise successful oversimplifications that drive agile success (“what is the simplest thing that can possible work”) simply do not scale to the enterprises challenge. The principles remain the same, but the practices must be extended.

The Product Owner in Scrum

It is to Scrum that we owe the nifty invention of the role of the Product Owner. As recently defined by Schwaber [The Enterprise and Scrum], the Scrum Product Owner

“is responsible for representing the interests of everyone with a stake in the resulting project …achieves initial and ongoing funding by creating the initial requirements, return on investment objectives and release plans.”

But the Product Owner’s responsibilities don’t end there. At the same time, the Product Owner is a resident of the ideal Scrum team as Figure 1 (adapted from a Certified Scrum Course) illustrates.

Ideal Scrum Team?

Ideal Scrum Team?

It can be implied from the figure and as follows in support of Agile Manifesto Principle #4 – (Business people and developers must work together daily throughout the project), the Product Owner is ideally collocated with the team and participates daily with the team and its activities.

We also note the “7 +/- 2 members” recommendation for the ideal team.

In an attempt to achieve theoretically better  organizational efficiencies in the enterprise, I’ve tried larger agile teams  and frankly, it simply doesn’t work! So in my experience this “7 +/- 2” number is sacrosanct and stands as a respected canon within the enterprise as well as in a smaller company setting. Of course, the impact of this rule is that one of the major challenges in the enterprise is that there can be a very large number (20-50-100 and more!) of such teams required to deliver a large, cooperative application. But such is generally the problem of scale.

Further, as taught and commonly practiced, the Scrum Product Owner has additional, tactical activities that directly contribute to the team’s success. These include:

  • Setting objectives for the Sprint (iteration)
  • Prioritizing and maintaining the backlog
  • Participating in the Iteration planning meeting
  • Elaborating stories on a just in time basis with the team
  • Accepting stories into the baseline
  • Accepting the Iteration
  • Driving release planning

Given this set of responsibilities, it is clear why the Product Owner is such a critical role in the agile project. However, the scope of the problem in the enterprise is daunting because we have just identified 20-50-100 new roles that have to be filled in order to execute agile successfully. Given this context, it should come as no surprise that “enhance capabilities in the critical Product Owner role” often makes it to near the top of the enterprises ongoing improvement recommendation list!

The Conundrum – Why the Enterprise Product Manager is Likely NOT the Agile Product Owner

In summary, there are two primary responsibilities that can be derived from the above:

Responsibility 1 – The Scrum Product Owner sets the vision, product objectives and manages to ROI

Responsibility 2 – 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.

However, when agile is introduced into a true enterprise context, (most typically through Scrum team training as we described earlier) there often occurs a role and paradigm mismatch between the Scrum teachings and the existing organizations structure. Specially, the mature software product enterprise is certain to already employ Product Managers who have the requisite skills, training, and existing responsibilities for Responsibility 1, above.

They work directly with customers; their responsibilities include product definition and their reward system contains an ROI element. They are trained professionals; they know what they are doing; they have extensive domain knowledge; they already work there and they have influence and authority.

This creates a conundrum which is being addressed from both the Scrum side (though standard trainings and the relatively new “Scrum Certified Product Owner Course”) and those who represent the existing professional practices of Product Management within the ISV (Independent Software Vendor) community. In one fairly pointed article, for example, Rich Mironov of Enthyosis comments:

“Product Managers are responsible for the overall market success of their products, not just delivery of software. In the Agile world, a new title is emerging—the Product Owner—which covers a small subset of the Product Management role. While this makes sense for internal IT groups that have traditionally gone without Product Management, …..agile product companies need full-fledged Product Managers to drive strategic activities and manage organizational/external participation.”

Plan A and Plan B

If we approach the enterprise in a naïve way, we might think the conundrum will be handled one of two ways:

Plan A) – The Product Manager will assume the role of the Product Owner and add responsibility 2) to their existing responsibilities. In practice, however, this plan does not work very well:

  • It doesn’t scale. There may be 30-50, or even hundreds of development teams requiring this intense tactical support and there are typically not nearly enough Product Managers to go around. (I saw one case, where, prior to agile 400 developers were supported by six Product Managers).
  • Product Managers may be ill suited, ill inclined and downright uninterested in these responsibilities. After all, if Product Managers wanted to live with development, they probably wouldn’t have picked their chosen path! (For those with a thicker skin, see the footnote (1) below from the Cranky Product Manager blog below. But Remember, it does say “cranky”)
  • Effective Product Managers often have insufficient technical depth and inclination to add significant value to the team’s highly technical language, activities and responsibilities.

Plan B) – The Product Owners on the agile teams will now assume some or all of the prior role and responsibilities of the Product Managers. This plan doesn’t work well either:

  • Why would existing Product Managers want to give up any of their influence, authority and contribution to these new agile types?
  • Where would these new Product Owners come from? Hire them from outside, where they are likely to have less domain expertise than the existing Product Managers?

Experience has shown that neither of these paths is particularly effective and a more nuanced, Plan C approach, is required. But as this post is already way too long, that will have to wait for the next post, which I hope to be able to push later this week.


Footnote 1: ” (some) argue that in Scrum the product manager is the same as the Product Owner, and therefore the Cranky Product Manager needs to be constantly available to the team in order to make on-the-spot decisions within minutes of the asking.  Ergo, you demand the Cranky Product Manager sit in that sticky-note-encrusted, windowless tomb with you all damn day. Uh, no way.  Not gonna happen. Why not? Because the Cranky Product Manager needs to be the Voice of the Customer and the Voice of the Market.  How is she to do that without actually VISITING some customers and prospects?  And VISITING means that she actually needs to leave the office, hop on airplanes, and fly far, far away. ” Cranky Product Manager blog.

More on Agile Product Managers and Product Owners

In a recent post, How to be the Ultimate Agile Product Team, Jennifer Fawcett opines on the evolving roles of agile project managers, agile product managers and agile (and traditional) product managers in a fast growing ISV/Embedded systems environment.

Like some others, Jennifer has concluded that the Product Manager role in an agile environment continues to focus primarily on mostly traditional PM responsibilities – market analysis, business case, new products and features, product roadmaps, etc. – while the new Agile Product Owner role focuses primarily on working daily with the team in support of implementation. That’s not to say that the APO doesn’t own or drive the vision for the feature or component that the team has responsibility for, rather it’s more a matter of focus (implementation (APO) vs. market needs analysis (APM) and the level of abstraction (feature or component level (APO) vs. product or system level (APM).

She described her view of the differing responsibilities in the following table.

Agile Product Manager (APM) Responsibilities Agile Product Owner (APO) Responsibilities
Tracks industry trends Tracks internal cadence and deliveries
Defines release objectives Defines iteration objectives
Provides overall strategic direction Provides day-to-day tactical direction
Delivers business level use cases or stories Provides system level use case or story elaboration
Has a solid understanding of current solutions Has an understanding of architectural component and subsystem design
Defines external roadmaps Defines user acceptance tests
Manages release and portfolio priorities and backlogs Manages the iteration and cross project priorities
Manages the changing needs of the market and customer base Unblocks and focuses the portfolio or feature teams throughout the iteration
Manages market messaging and positioning Defect scheduling
Provides the overall vision Provides the implementation
Lives in Marketing Lives in Engineering
Communicates daily with the Product Owner (shares a brain with the PO) Communicates daily with the Product Manager (shares a brain with the PM)
Delivers The Release Delivers The Iteration

Perhaps more importantly, she goes on to note that building an effective set of relationships between these roles requires Collaboration, Partnership and Trust. For that discussion, I refer you directly to her article.

More on Product Owner vs. Product Manager – Revenue Products need Product Managers not/and Product Owners?

As I’ve noted before, the Product Owner and Product Manager category on this blog still seems to stir the most interest amongst readers.

I just noted that the folks at enthiosys recently published the following article Revenue Products need Product Managers, not Product Owners. (The title is a tad misleading, because in point of fact and as the article points out, agile enterprise ISV’s (independent Software Vendors) generally need both). This is an excellent, summary perspective of much of what is being discussed in classes, forums and blogs as agile crosses the chasm to the enterprise. It’s a short read and pretty much on the mark. Here’s a short introduction:

“Product Managers are responsible for the overall market success of their products, not just the delivery of software. In the Agile world, a new title is emerging – the Product Owner – which covers a small subset of the product management role and can lead to role confusion. Here, we’ll explain why revenue-producing products need full-fledged Agile Product Managers.”

If your organization has, or should have, Product Owners and Product Managers, you should definitely check it out.

And for more on this topic, check out the Product Owner/Product Manager category on this blog.


More on the Big Picture (3)- Product Owner vs. Product Manager

In the post Enterprise Agility–The Big Picture (3): Role of the Product Owner, I discussed the differences between the Product Owner and the Product Manager. In the past, I’ve discussed the fact that, at least in the larger enterprise, these are typically NOT the same individual and this is clear from the Big Picture Itself.


Big Picture 3- Product Owner and Product Manager

The reasons are straightforward. Simply, there are typically not enough Product Managers, nor are they necessarily inclined by training or interest to spend some/much/most of their time working directly with the product teams. The math itself is part of the problem. I’ve seen enterprises with up to 400 practitioners operating with as few as 4-6 Product Managers. It simply isn’t practical to assume that they will be able to support the Agile Manifesto Principle: Business people and developers must work together daily throughout the project. Even if they were so inclined, there simply aren’t enough hours in the day. And if they did spend most of their time with the teams, they become further removed from the customer the enterprise is required to serve. That can’t be good. (For more on this topic, check out the Product Owner/Product Manager category on this blog).

Moreover, the effective Product owner exhibits must exhibit a degree of technical competence in order to deserve and earn the respect of the team. As I noted previously,

“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.”

This blog post has raised some interesting comments which those interested in the topic may want to peruse at Enterprise Agility–The Big Picture (3): Role of the Product Owner.

One in-depth comment in particular, takes some issue with my recommendation (which I still support) that the Product Owner reports into the same line management as the team. To save you time, I’ve incorporated some of those comments from Malamo below:

“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.”

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.

Role of the Product Manager

I’ve been blogging off and on the “agile product manager vs. agile product owner” roles over the last few months. (These are categorized under Product owner/Product Manager) In one post (Responsibilities of the Agile Product Owner vs. Enterprise Product Manager) we noted that within the enterprise, it’s not always appropriate nor feasible to have product managers fill the role of the agile product owner, and we noted that organizing the roles around the release and iteration boundaries/ownership often make sense. See below.

po-vs-pm.jpgWhen this happens, while the activities of the product manager role evolve in an agile enterprise, so long as the product owner assumes the basic iteration responsibilities, many aspects of the enterprise product managers role are largely unchanged.

I just came across an article I wrote in 2002 which was my articulation at the time of the growing influence of product managers and their responsibilities within the software enterprise. I’ve posted the article below and on the resource page as well. I think it is still largely relevant to the discussion at hand.

The Role of the Product Manager in a Software Products Company