Search This Blog


14 May 2015

Product Owner, Updated

How would I describe a Product Owner?

I am writing this description in response to the below Mkie Cohn description of a Product Owner. Mike's description isn't wrong per se, but it is almost ten years old and maybe can do with a refresh. I'll qualify this description by saying that there are actually many incarnations of the role, and my view is locking things down to one model is useful for recruiters and beginners, but should quickly fall away in deference to the context and strengths of the people in play on any particular team.

Mike Cohn's description of a Product Owner is here. You might like to evaluate the differences between that description and this one - and comment on your opinions here.

I have italicized paragraphs where I have copied from Mike's description verbatim. The way I put this together was by pasting his description in and writing over the top, deleting the old stuff as I went, so there are often similar phrases, as well as the same pattern or shape of the description.

Product Owner description

The Scrum product owner is member of a development team with a particular set of responsibilities or focus areas. Part of the product owner responsibilities is to ensure the team have a vision of what he or she wishes to build, and convey that vision to the customers and user community perhaps with the help of sales and marketing people.

This shared vision is key to successfully starting any agile software development project. The agile product owner does this in part through managing the product backlog, which is a prioritized features list for the product. The product owner may take an autocratic or facilitative style of management, depending on the context the team is working in.

The product owner is commonly a lead user of the system or someone from marketing, product management or anyone with a solid understanding of users, the market place, the competition and of future trends for the domain or type of system being developed.

This, of course, varies tremendously based on whether the team is developing commercial software, software for internal use, hardware or some other type of product. The key is that the person in the product owner role needs to be able to articulate a vision for what is to be built, both to the team and to stakeholders to the development work.

The PO will come prepared to sprint plans with a view on what should be top of the priority list, but be ready to negotiate with the team on the actual choices of what is to be done based on both his or her insights about customer demand and the advice and knowledge the development team bring based on capabilities, opportunity and data that feeds directly to the team. Product owners will bring ‘voice of customer’ but will also facilitate and perhaps arbitrate on the choices of what is to be done with the team.

Product Owners should participate in sizing backlog items and should share their views on whether a job should be hard, easy, complex or simple. Their contributions in this discussion will help inform a development team of the rough value of the work, and help understand appropriate limits to investment in jobs.

Product owners should have skin in the game and so, if they publish forecasts about when the work will be done they should be accountable for those outcomes. As far as the admin of creating and publishing forecasts - it makes sense that the PO does it rather than the engineering team, as the PO knows (or should know) the audience and the way they best hear messages. One person is also better able to manage external relationships that a group, as one on one discussions are more intimate than group ones.

A good product owner works with the team on establishing reliable forecasting capability. If the work is inherently risky that should be managed as part of the conversation. Great teams share accountability for results to stakeholders and customer, and to each other.

A good product owner understands that delivery of work is not always linear. Forty stories will not be evenly delivered over four weeks. There is inherent variation in work. Good product owners study variation and account for it in planning and managing expectations.

Motivation is intrinsic, so a Product Owner can’t fundamentally motivate team members, but a Product Owner has a unique opportunity to inspire the team with feedback and insights from the market. Broadly, Autonomy, Mastery and Purpose are what motivates people, so Product Owners should be thinking about how to max out these attributes for the team, and for themselves.

One good practice Product Owners can share with teams is helping elevate sprints by highlighting the big goal the work is contributing to, and how the work will solve real customer problems.

Product Owners know the importance of a stable set of goals, and understand the cost of changing plans and context switching too frequently. Product Owners will do their best to give the development team a stable set of goals for a planning horizon that is appropriate to the team. This can be played out at the daily, sprint, release and project level. Despite the importance of stable contexts, Product Owners also understand that effectiveness trumps efficiency and so will work with the team on addressing urgent and important new information appropriately.

Product Owners need to come with decision making authority and expertise in the work they do. That expertise can be either built around market and customer experience and insight or the techniques and practices and processes of customer discovery, analysis and design, or ideally both. Great product owners understand the need to bring an approach that balances data, systematic approaches and the emotional appeal of customer stories.

From a development team’s point of view a good product owner is one that works full time with a team. Some product owners manage a portfolio of products and work with several teams. Access to information and decisions quickly and high context communication are what is most important. Product Owners will work with the team to optimize the balance of outward facing activities and team facing activities for the greatest good.

Finally, a great Product Owner takes time to share and promote the good work a team is doing across the home organisation and market place as well as bring voice of customer to the team. A great product owner wants to have the broader community at work to appreciate the great contributions their team is making.