The Product Owner (PO) is certainly the most neglected of the three Scrum roles. Precisely for this reason, many organizations end up finding a solution that seems to be easier than training or hiring a good PO: giving that title to the client.
Because of that, we often hear the notion that the best Product Owner is the client. The main arguments behind this claim are related to the client’s interest in the project’s success and his or her knowledge of the business and their own needs. But is this really such a good idea?
Much to the contrary. In many of the companies we visit in our everyday work as consultants, we come across projects in serious trouble as a consequence of a profound misalignment between the PO and the development team. These companies have precisely this characteristic in common: the PO is the client. But why is it that having a client-PO is a problem?
1) The client-PO thinks about functionalities, not about problems
Clients rarely know what they want. They usually struggle to understand the very problems that need to be solved. For that reason, it’s not uncommon to see clients bringing “ready” solutions to problems they still haven’t understood.
In this case, a client-PO causes the following dysfunction: instead of bringing business-related problems to solve with the team, he or she brings solutions that, at the end of the day, don’t deliver much value. The team can do exactly what the client requests, but, because the real problems are not solved, the client won’t be satisfied. Haven’t many of us seen this before?
2) Team relationship or client-supplier relationship?
The relationship between a client-PO and the team is tense. In Scrum, the Product Owner, the ScrumMaster and the Development Team make up the Scrum Team, which must work together around a project. However, when the PO is the client, the relationship shifts from team dynamics to a hierarchical relationship.
Instead of cooperating with the team, the PO takes the stance of project manager, since he or she is “paying” for the product that is being built. In such cases, it’s common to see the PO using the Daily Scrum as status report, the Retrospective to pressure the team, and the Sprint Planning to ask for “just one more story”. Besides, the client-PO is under constant and direct pressure from the stakeholders for results.
Therefore, instead of protecting and collaborating with the team to organize the work, the client-PO wants to get the most out of their “supplier”. A direct consequence of this is that for the client-PO everything is a priority, which interferes with one of Scrum’s most essential practices: prioritization.
3) Frequent absences
Client-POs are seldom available to spend time with the team to clarify doubts and to help refine the work items. In fact, when the PO is the client, s/he is probably at a different physical location, which makes communication difficult and causes various dysfunctions in the project. Allying this issue with problem number 2, life becomes very complicated for the team. Even when the project is internal, the client-PO tends to have other activities and priorities, often leaving the team to fend for itself.
If your team has a client-PO and you are certain that you’re not facing these problems, that’s excellent, but be aware that you are the exception. Generally speaking, at K21 we defend the idea that the best Product Owner is NOT the client.
It’s extremely important to choose the Product Owner carefully, in order to work with someone who understands agile product management, who is available to take the role, who is able to communicate efficiently with the client and stakeholders, and who can work with the development team through continuous collaboration. Only in this way can you form a real “Scrum Team” as defined by Jeff Sutherland and Ken Schwaber, the creators of Scrum.
