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.