How much technical knowledge should a Product Owner possess?

 

In an earlier article I'd written about the pros and cons of a Scrum Master or agile lead having deep technical expertise in the solution space but what about a Product Owner (PO)?

In their 2003 book, Balancing Agility and Discipline: A Guide for the Perplexed, Barry Boehm and Richard Turner coined the well known acronym C.R.A.C.K. to describe the attributes of an effective PO and the K in that acronym stands for Knowledge. Normally, we consider that this is business or product knowledge, but couldn't it also extend to technical acumen?

Technical expertise is likely to help the PO prioritize the product backlog such that there is a healthy balance between business and technical drivers. In the absence of this knowledge, team members might find themselves spending greater effort in helping the PO understand why certain technical work items are time sensitive from either a risk management, dependency or technical debt reduction perspective.

While there is some benefit in a PO having such knowledge, it comes at the cost of greater vigilance. The PO will need to be disciplined to ensure that he or she is maximizing product value by focusing on the "what" and "why" of the product and letting the team own the "how" and "when". Without that mindfulness, such knowledge could result in a PO who:

• Responds to technical inquiries from stakeholders without confirming the answers with the team
• Places higher priority on technical work items in the product backlog and neglects the true business needs of stakeholders
• Turns a blind eye or even encourages technical gold plating
• Provides the team with system requirements or design guidance thus reducing the team's ability to be creative or innovative
• Unreasonably challenges the team's sizing of work items or how much they are able to complete within a given amount of time

With great knowledge comes greater responsibility.