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.



You have also made excellent points. A big problem I have encountered with the business is that the executive view is very different to the user view, and executives frequently make little effort to lead their people.


What you have written is part of the story, but it is a major part. And your final paragraph is inspired. Are you gong to be the author of the next generation Dilbert? :)


Most business leaders in companies love agile until they realise the commitment they ave to make. Most then fall back on traditional approaches. Most large IT shops want similar governance to traditional approaches, so most large corporates now are going for a hybrid of Prince 2 and similar methods combined with some form of agile. Agile projects have failed at similar rates to waterfall ones.

the key distinguishing factors between successful and unsuccessful projects is effective executive backing, effective user support and quality of people (both IT and business). After that tools and methods hardly matter.

This is why every method ever produced has had huge success and huge failure.


I agree that the PO is one of the weak spots in Scrum. But I do not agree with the blog: having an onsite customer instead of a PO gives also problems: Who decides when enough is enough? For sure not the customer/user. He wants everything since he has not to pay for. As others already have commented: Who is THE customer for larger projects with a large, not consistent user community?
It needs both of them, but the PO should not be a wall, but allow direct customer - developer interaction and watch the ROI. Product Backlog refinement is an often missing practice, see also


Alen, the ScrumGuide is updated regularely (last time this summer) and is not from the 90ies.


The main flaws in the Agile/Scrum idea underlie what this article describes:

1. The people who know the current operations are too busy to stop their work to help the software department, especially if the developers are outside contractors.

2. Non-software people of any type all too often insist "I know what I want", when they don't.

3. Quite often the people who know how the system works don't really want to be automated out of their jobs, so they drag their feet.

4. Knowing how the system works now is not the same as knowing how it ought to work when computerized.

5. The design of an information system is sometimes skewed by Machiavellian managers to screw the other managers who are their competitors. This is not mitigated by the fact that often these guys are incompetent and screw themselves as well.

Agile/Scrum are a series of intelligent responses to the problem of "I built what you said and now you don't want it?". All praise and glory for fighting this good fight. That doesn't mean you've won. Organizations resist change.


Too non-prescriptive leads to confusion. Is SCRUM the thing that's defined in the guide, or is it defined by the way that it's practiced? I contend that practice is definitive, not theory. If dangerously stupid behavior is commonplace in shops that think they're Agile/SCRUM, then something is seriously wrong with the way SCRUM is defined (or learned).


Granted, you cannot be an expert in using a system that isn't built, but the PO should have the best understanding of what the new system is supposed to do and how to relate that to the dev team. I wonder if the marketing department is the best business area to provide a PO or if at least other areas shouldn't have a SME involved, at least on an as needed basis.Thanks


See this:

I think the scrum guide deliberately avoids being prescriptive. There is no substitute for using actual intelligence and thought. Blaming SCRUM for dangerously stupid behaviours seems misplaced.


Roger, I agree completely, but it's the "it turns out that way" shops that worry me. The fact that so many shops indeed get it wrong does reflect back on, if not the concept, at least the way the concept is presented, however. The Scrum Guide is annoyingly vague about the core roles. It talks about how the Product Owner is in charge of the backlog, but that's about it. In fact, the word "customer" doesn't appear anywhere in the Guild! Admittedly, the Guide itself isn't the best way to learn the process, but many people don't go much further than that (not to mention the Scrum-but shops that arbitrarily make stuff up, but still think they're doing Scrum). Given the vagueness, it's just too easy to make assumptions that lead you in the direction of dysfunction, and there's a lot of inertia that pulls you in the wrong direction when you're transitioning to Scrum from waterfall.


A few thoughts, Allen.

First, the language you've used is subject to misinterpretation. The lack of an onsite customer doesn't entail no interviews and no design, even if in many instances it turns out that way. It's easy to read your article as a criticism of the very concept of a product owner rather than of the practices of many organizations that claim to practice Scrum.

Second, it's important to distinguish understanding customer needs and problems from designing a solution that will address them. Ongoing customer interviews - combined with iterative feedback loops - provide an excellent framework for understanding customer needs and problems. But customers are often not experts on - or even interested in - designing great products to address those needs. It's not really a responsibility of the product owner, either. The team needs an interaction designer who possesses this expertise.

Third, a product development effort differs significantly from a consulting project for an individual customer. In the first case, it's vital that someone synthesize and distill the situation and needs of a wide array of prospects throughout the market. In the latter case, the customer herself is likely to most accurately represent her needs (even if the team needs a skilled facilitator to help uncover these needs). At least for some agile thought leaders, the product owner concept arose from the idea that no single customer can accurately represent the target market for a product.


Regardless of origins, I believe that Scrum as usually practiced stems from the XP planning game. Most Scrum partitioners follow Schwaber/Sutherland's Scrum Guide, not Takeuchi and Nonaka work, and the Scrum Guide dates from the mid 90's. Schwaber's book on Scrum came out in 2000.

You're right that the Scrum Guide doesn't say that the PO should be a user surrogate (in fact, I'd guess that Schwaber and Sutherland would both argue that he/she should be a user if possible). The guide itself says only that the PO is responsible for the backlog, which is way too inadequate a job description. The implementation vs. methodology distinction is important, but ultimately, it's the implementation that counts, not the theory. I'm writing about implementation, here, not theory, and in my experience, Scrum is often implemented badly, thus the post.

You're certainly right about the cost. In fact I don't agree with my own numbers :-). I made an off-by-a-factor-of-two math error in the original article that put the cost at $80K (the article's since been corrected to show $160K).


I'd love it if the PO was an experienced user of the system. In my experience, that's not usually the case. In fact, in many large corporations who are making an Agile transition, the PO comes from the marketing department, not from the real world of day-to-day users.

I don't see how anybody can be experienced with a system that doesn't exist yet, which is where an actual user---somebody who will be using the system in their day-to-day work---comes into play. If the PO is such a person, great. I wish that were the case everywhere, but it's not.


A PO can certainly (in fact, any competent PO should always) consult with the customers. The problem is the time required for the feedback to reach the team. Consultation can take days, but somebody who's working on the code needs an answer now. I'm also wary of the customer feedback being filtered through the opinions/preconceptions of a single person. It's better for the whole team to interact with the customer(s).



I'm generally loathe to publicly criticize, but certain assumptions and factual errors in your post have spurred me here.

* Scrum did not derive from XP: (Scrum - Japan/1980s, XP - Chrysler/1990s). Simple factual errors destroy your credibility (at least in my eyes).

* Your assertion that "the PO is not an actual end user of your product" or "a surrogate customer" or "a mouthpiece" who "won't know the answers to your design questions" is also false - there is nothing in the Scrum canon to demand or suggest that this is the case. Certainly poor implementations of Scrum (or anti-methodologies masquerading as Scrum) may place an unqualified individual in the Product Owner role, but that's the implementation NOT the methodology.

* Maybe some context is appropriate - I have never encountered a complaint that "they can't afford the expense of an on-site customer." I do agree with you that the cost of a failed sprint is expensive - I would assert that the true cost is far greater than $80K in the scenario you outlined.

* Finally a personal pet peeve: loose != lose ... remedial grade school grammar please?


I assume this blog was written as a rant due to one or more less than optimal experiences with Agile. Maybe the POs are not functioning in their role properly. The PO is supposed to be a lead or experienced user of the system - even one that is not built yet. Ideally, they should be the liaison between the users and the dev team. Not all projects are equal; same with Agile teams.


Maybe I'm missing something, but I don't see why having a product owner means no customer involvement. The product owner for the project I'm currently working on consults frequently with our customers to gather feedback and requirements. I had assumed this was the norm.