{{announcement.body}}
{{announcement.title}}

Do We Really Need a Product Owner?

DZone 's Guide to

Do We Really Need a Product Owner?

TLDR: If you want to maximize value for your customers, yes.

· Agile Zone ·
Free Resource

This guy could totally be a product owner.

This product owner is quite confident that your team can't, in fact, live without him.

As regular readers might know, I'm working on a book called The Art of Product Ownership to be published by Apress later this year. One of the chapters is entitled "Why have a Product Owner," and a few days ago a bunch of ideas crystallised into what follows...

The aim of the Product Owner is to increase, even maximize, the business value delivered by the team as a whole. The Product Owner does not so much create value themselves as increase the value created by others.

Think of it like this: If the team randomly selected work to do and delivered it to customers, then some value would be created. (For the moment, I'll ignore the scenario where that work detracts from the existing value.) The aim of the PO, though, is to ensure the work done creates more value than a simple random selection. The greater the difference, or delta to use a mathematical term, between random selection and an informed selection the better.

The general hypothesis is that intelligent selection of work by a skilled Product Owner will result in both more value being delivered and an increasing delta between intelligent PO selected work and randomly selected work.

This difference is the value added by a Product Owner, which I like to call the Product Owner Delta.

Now, in real life, work is seldom randomly chosen, so Product Owners are not really competing against random selection. And in some cases, the alternative to a designated Product Owner is someone else: a senior developer, an architect, a manager, or someone else. In such cases, this person is taking on the Product Owner role. They may not have the title, the aptitude, the skills, or official position, but when work is selected by one person they are de facto the Product Owner.

In other cases, the alternative to the PO might be selection by consensus on the team, or a sub-set of the team. Now, it is entirely possible that such a group could outperform a single Product Owner in selecting work, especially is they have market and customer knowledge, some analysis skills, time to do the background research, and so on. And in some cases this works; for example, think of a small start-up staffed by software developers creating software development tools.

However, in some cases, selection by committee might actually be inferior to a random selection. Imagine a team that has never met a customer, argues about what to do, ducks key decisions, and never says No to any request. Its easy to image a dysfunctional selection committee.

There is more to increasing the Product Owner Delta than simply selecting the highest value items. Timely selection can help too. If decisions are not being made, or committees are spending a long time making decisions, then having one person simply make those decisions in an efficient, timely manner can increase the delta.

Time also has another role. Because of cost-of-delay, simply selecting the highest value items at any one point in time does not maximize the value delivered. Time Value Profiles (see Little Book of User Stories or my presentations on value "How much? When?") expose this and need to be another tool in the Product Owner's repertoire.

And of course, the Product Owner Delta is not the only reason to have a Product Owner in the team, but it is probably the main reason.

Further reading

How to Be a Great Product Owner

Saying No: Tips for the Product Owners

Topics:
agile ,product owner ,product owner delta ,increased value ,leadership ,team

Published at DZone with permission of Allan Kelly , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}