Get certified - Transform your world of work today

Has Anyone Seen My Product Owner?

The Importance of Strong Product Ownership

08/07/2013 by Warren Jones

As the key stakeholder within the Scrum framework, the product owner is an essential player in ensuring that a relevant and quality solution is delivered. Typically, the product owner role is performed by the product manager, who has the vision and understanding of the end-user requirements to be able to effectively direct the team. If you find yourself working on a project with an "absent" product owner, or with a weak or ineffective product owner, then it is time to speak up.
Having previously been a product manager for several years, I understand the myriad of activities that serve as a constant distraction. There are the obvious -- and relevant -- tasks of defining road maps and strategies, but also secondary tasks, such as attending sales calls and working conference floors. It may also be that the product manager has ownership of multiple products and therefore has competing product responsibilities. It becomes easy to see why you may not be seeing your product owner as often as you would prefer.
Is this acceptable? Should we simply learn to live with this situation?
Let's consider this approach.
Often I'll hear developers talk about the need for others to simply get out of the way and let them write code. Maybe this scenario presents the perfect opportunity for this to happen? Unfortunately, while the team may have expert knowledge of the technology or product, this doesn't necessarily translate to understanding what the user, or customer, requires. I would argue that this knowledge is counterproductive to delivering a meaningful solution, as it limits their thinking to within the confines of the existing product. Frankly, this is a danger for the product owner and user as well. As a product manager reviewing countless product enhancement requests, it was common to see requests telling me how to modify the existing product to achieve some almost unnatural goal, as opposed to stating what the challenge was that they were trying to address.
A differentiator of Scrum from other methods, such as Waterfall, is the constant review of the backlog and the iterative review and acceptance of what has been delivered. While a team could happily continue along its way, closing out stories and picking up new ones, we ultimately revert back to a method that delivers functionality determined at the commencement of the project, without any validation from a customer or customer representative. I'm reluctant to admit it, but I have actually been on an Agile-run project for which, when we finally delivered a solution, the product owner's response was, "Oh, I thought I was going to get something different." Where does the blame lie in this situation? The blame lies firmly at everyone's feet: the product owner for not fulfilling his responsibilities, the ScrumMaster for not addressing this issue on behalf of the team, and the team for going along with it.
So, can someone other than the product manager fulfill the role of product owner?
Of course -- but the danger is not in getting someone else but rather in getting the wrong someone else. The characteristics of strong product owners are that they:

  • Understand the vision and strategy for the product.
  • Have a user-oriented perspective.
  • Are able to effectively communicate to direct and guide the team.
  • Don't have competing responsibilities.
  • Have accountability for the end result.

These aren't attributes that are necessarily easily found outside of the product management area. Trying to shoehorn others into this role, without considering the suitability of the individuals, will not deliver the desired result.
The Scrum method encourages a self-regulating project entity. Having a strong product owner is an essential component of a successful project. Should you find yourself with an absent or ineffective product owner, you are empowered to voice this concern. The alternative is to be a part of a project that is destined to deliver something well short of what would otherwise be possible.