Sometimes, when an organization is adopting Scrum as its development model, the following unfortunate thing happens: A decision maker with authority over the team-to-be is trying to match existing people to each of the Scrum roles, and he or she thinks, "Product owner . . . well, that's obviously the customer."
Wrong. In almost every case.
If the process formation proceeds from the premise that a client-side individual will fulfill the role of product owner, the most likely outcomes include:
- A string of flailing, low-value product deliveries
- Programmatic black eyes for both customer and vendor
- Increasingly loud calls from leadership to regress to whatever development method was in place before the attempt at Scrum
Why? Because it doesn't matter how well you build software if you build the wrong things. Figuring out what to build (and what to build first) is the core job of the product 0wner. It's difficult. It's probably a full-time job. And your client already has one of those.
The product owner as core determinant of successful Scrum
To deliver value, Scrum requires an efficient, accurate mechanism for determining a product's vision and an able pipeline for distilling that vision into concrete, deliverable backlog items that can demonstrate tangible benefits and function as part of the longer-term project vision. It is for this reason that the performance of the product owner becomes the prime limiter of the team's success.
While product owners participate in each of the Scrum rituals, their core job functions run outside and parallel to the jobs of the ScrumMaster and team. Essential product owner tasks include:
- Facilitating an achievable and valuable vision for the product
- Guiding and adjusting an iterative release strategy that fits into the prevailing market tempo
- Distilling high-level requirements into deliverable user stories with complete acceptance criteria
- Enabling accurate prioritization of the product backlog
- Communicating complex issues of system architecture and technical debt back to clients
- Negotiating client-side disputes about requirements, design, and priority
In essence, then, the product owner fills two major roles: proxy client when facing the Scrum team, and product management coach when facing the customer.
Skills and commitment necessary to be a good product owner
Being a good Scrum product owner requires a wide array of skills. To list a few: business process analysis, requirements analysis, product lifecycle management, configuration management, organizational marketing, IT program management. and consensus building. In traditional Waterfall development efforts, each of these activities may be carried out as individual functions by entire departments of personnel, but Scrum requires some proficiency in all of them — and the awareness to solicit additional support when necessary.
This also means that for most efforts, being the product owner is a full-time commitment. On large projects with multiple teams, it's reasonable to portion out the role into a "strategic product owner" charged with maintaining product vision and release planning across all of the teams, and "tactical product owners" engaged on a one-to-one basis with each feature team to handle nuts-and-bolts decision-guiding with clients and to provide daily feedback in the various Scrum rituals.
These two considerations, the necessary skills and level of commitment, are what generally prohibit client-side individuals from being good Scrum product owners. If your customers don't have the ability to determine a cohesive, deliverable vision for what you're building, or if they can't commit to being accountable to the team at a level that enables rapid delivery, then they aren't suited for the product owner role.
Discouraging clients from assuming the product owner role
Educate your customers. If their organization is new to Scrum and you're "selling" the programmatic benefits of the Scrum process, highlight how difficult and time-consuming good product ownership can be. Make the idea of supplying a vendor-side product owner a core part of your value proposition: "We not only bring Certified ScrumMasters (CSMs) and Developers (CSDs) to the table, we bring Certified Scrum Product Owners (CSPOs) to make sure this effort has the greatest possibility of success." Sharpen the clients' awareness of the conflicting stakeholder and user landscapes for the chosen market, and illustrate how a good product owner will help them focus on the most important segments of those pools. Demonstrate how product owners can help bring complex initiatives in better alignment with on-the-ground mission needs. In short, help them understand that good product owners help turn busy customers into heroes, both inside and outside their own organizations.
How to cope if it's already happened
It's never too late to give your client a product owner. If your relationship is healthy enough for open critique, make a case that the project will work better with a trained, vendor-side product owner, and you'll be able to prove it almost instantly. If that pitch is not feasible, make a less obvious case. For example, state that as part of a process improvement initiative, you want a vendor-side "tactical product owner" to support the customer's "strategic product owner."
However you accomplish it, once your product owner is in place, it shouldn't take long for him or her to be seen as delivering significant value and for the performance of your Scrum team to improve. This can easily be leveraged into a competitive advantage, as customers begin to tailor follow-on vehicles to ensure that this support continues and that other efforts also require CSPOs in addition to CSMs and CSDs.