Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼

Allen Holub

Dr. Dobb's Bloggers

Scrum's Flawed Notion of Product Owner

January 06, 2014

One of the many things about Scrum that makes me uncomfortable is the notion of a Product Owner (PO), or more precisely, the lack of an on-site customer. The PO job typically mixes the role of customer surrogate with that of marketing-department or product-development representative. The PO "owns" the product in the sense that he or she makes decisions about content, the value of a story to the business, and so on.

Given that XP, from which most of Scrum derives, calls for an actual flesh-and-blood customer on the team, I both wonder where the PO notion comes from and am dismayed by the damage it can do. My guess about the former is that Scrum waters down agile to make it more palatable to large corporations, and most large corporations make it very difficult for an actual customer to enter the building, much less hire one. If a customer were required, the organization just wouldn't do Scrum.

The damage is another issue, since it can render the entire process ineffective.

The first problem is developing a product that somebody actually wants. To do that, you need to design. (Contrary to popular belief, design is integral to agile — it's one of XP's four core activities, in fact.) In a waterfall world, you develop your design from up-front customer interviews. The problem — and the raison d'être of agile — is that you never get it right up front. You miss important things, and customers often give you incorrect information, not because they're evil, but because they can't know what to ask for until they have working software in front of them. So they guess. The designers diligently record (and implement) that guess. The product fails.

Agile processes use incremental design, done bit by bit as the product evolves. There is no up-front requirements gathering, but you still need the answers you would have gleaned in that up-front process. The question comes up as you're working. The customer sitting next to you gives you the answers. Same questions, same answers, different time.

Put simply, agile processes replace up-front interviews with ongoing interviews. Without an on-site customer, there are no interviews, and you end up with no design.

But what about the PO? Since the PO is not an actual end user of your product, he or she probably won't know the answers to your design questions. You're now building on guesswork rather than facts. When the PO guesses, you implement the wrong thing. When the PO spends a day or more getting the answer, you lose a day's work (more if you had proceeded on a wrong guess and then had to undo whatever you did yesterday). You don't have time not to have a customer on the team. When the PO is a surrogate customer, the odds of building the wrong product are much higher, and that's a bring-the-company-down failure.

Of course, if the PO is just the mouthpiece of a separate product-development group (or a CEO) who thinks that they know more about what the customer wants than the actual customer, you're in even worse shape. That way lies Windows 8.

Finally, people complain that they can't afford the expense of an on-site customer. But if you can't afford to get the product right, then why are you building the product at all? In any event, the cost argument is specious. What's the cost of an 8-person team loosing a two-week iteration because of an incorrect answer from the PO? Assuming an average salary of $120K and 46 useful weeks in the year, you'll loose $41,000.00 in salary. Add benefits, taxes, the cost of the workplace, and you're up to about $82K. Double that because of the opportunity cost of being two weeks behind. We're at $160K. This is not chump change.

More to the point, what's the value of delivering a product that's useful to your customers? As MasterCard says, priceless.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.