The Jenga Effect: Why Clients Don't Make Good Product Owners

I recently met with a team where the client was the Product Owner. The team kept saying that their product backlog didn’t make sense. They didn’t understand the product they were trying to build, and they had never seen a vision or strategy. Despite all this, their PO was focused on more features, faster, now, please.

Their product looked like a Jenga tower just before it was about to topple. This impacted quality, usability and, worse, the team was on the verge of burnout. They were getting whiplash from the number of misunderstandings the client had about how products get built.

Let’s think about the Product Owner role and how things could go sideways…

Product Owner Responsibilities

• The Product Owner owns the vision - why are we building this product? Clients are the initial source for the vision information, but so, too, are ends users. Relying solely on the client’s vision can easily lead to cognitive bias and have a team building the wrong thing at the wrong time.
• The PO owns the strategy - how we are getting there? Unless the client is fully experienced and informed, not only in the technology but also in the team, then they have no idea of the how and shouldn’t be weighing in on it.
• And the PO also owns prioritization - what do we work on next, and how can I justify it? Clients typically want everything now, or as soon as inhumanly possible, with no experience in matching priority to the team’s capacity.
• Along with the product itself, Product Owners also need to understand the regulatory environment, usability, accessibility and security. Clients typically just want to know that it works.
• POs collaborate with developers to agree on what a feature or user story is. (Sometimes with pencil sketches or discussions around acceptance criteria.) Clients would struggle to understand both the terminology and the techniques.
• POs balance stakeholder needs. If the client is acting as product owner, how unbiased do you think they would be able to be about multiple stakeholder requests?

The PO needs to be empowered to make product decisions. A great Product Owner understands the big picture of product management, and they help Developers (i.e. team members) to understand all of the above.

POs also need to have ability to interview a variety of end users, digest the information, design and run experiments. And they need to develop a relationship with, and understanding of, the team so they can find a rhythm together (e.g. How much detail does the team need? What decisions can they handle independently?) Clients don’t have the time, experience, or relationships to be able to do these.

This only scratches the surface of a good PO’s role. Many people, on discovering the work involved in being a PO, run away after a few months. In government, some people rotate out of their jobs every 6-12 months. That’s not conducive to acting as product owner.

What happens when someone without expertise steps into the product owner role?

Client as a Product Owner

People from the client side understand the business problem well, but not the product build.

Weaknesses

• Don’t understand how product development works
• Don’t have experience working with a team
• Limited experience with all of the responsibilities mentioned above
• Not prepared to make it a full-time role
• … they’re missing almost all the skills and responsibilities mentioned above

The main issue is that most clients lack the background in product work to play the role effectively. Instead of the client as PO, we’re better off with the client as a stakeholder. The Product Owner ensures the product solves their problem, but they do it while considering the big picture, not just the next feature.

Conclusion

Effective Product Owners have a background in product management. In areas where they’re weak, they take time to learn, as it is their trade craft. Your client makes a good stakeholder, not a good Product Owner.