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 www.agileproductowner.com. 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:
- 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
- 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:
- 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.
- 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.
- 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.
- 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.
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.