Agile Product Management with Scrum: Common Product Owner Traps and Pitfalls
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Product owners play a key part in creating successful products with Scrum: They are in charge of the product and lead the development effort. But this new multi-faceted role can be challenging to apply. For many organizations, the path to effective product ownership is littered with traps and pitfalls. This article helps you recognize and avoid some of the most common traps.
The Product Owner in Scrum
“The Product Owner is the one and only person responsible for managing the Product Backlog and ensuring the value of the work the team performs. This person maintains the Product Backlog and ensures that it is visible to everyone,” writes Ken Schwaber in the Scrum Guide (Feb 2010 edition, p. 7). This definition sounds rather harmless until we consider its implications. It requires the product owner to lead product discovery, to help identify and describe requirements, and to make sure that the product backlog is ready for the next sprint planning meeting. It also means that the product owner has to engage in product planning, visioning and product road mapping.
The individual decides on the content of a release, carries out release planning, reviews work results and provides feedback to the team, and manages customers, users and other stakeholders. So many diverse responsibilities make the product owner a multi-faceted and challenging role.
What’s more, the product owner duties often cut across existing roles including the product marketer, product manager, and project manager roles. It’s not surprising that organizations can find it challenging to apply this new role while encountering traps and pitfalls along the way. Let’s have a look at some of the most common ones.
The Underpowered Product Owner
A project with an underpowered product owner is much like a car with an underpowered engine: The car runs, but it struggles when the going gets tough. An underpowered product owner lacks empowerment. There may be several causes: the product owner does not have enough management attention; the sponsorship comes from the wrong level or the wrong person; management does not fully trust the product owner or finds it difficult to delegate decision-making authority.
As a consequence, the product owner struggles to do an effective job—for instance, to align the Scrum team, stakeholders, and customers or to exclude requirements from the release. A product owner of a new-product development project I worked with, for instance, had to consult his boss, the head of the line of business, for every major decision. Not surprisingly, this caused delays and eroded the team’s confidence in the product owner. Ensure that the product owner is fully empowered and receives support and trust from the right person.
The Overworked Product Owner
Being overworked is not just unhealthy and unsustainable on a personal level; overworked product owners quickly become bottlenecks and limit the project’s progress. Symptoms of an overworked product owner include neglecting product backlog grooming, missing sprint planning or review meetings, and not being available for questions or giving answers only after a long delay. Overworked product owners are at odds with the Agile Manifesto’s concept of sustainable pace: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
There are two main causes of product owner overburden: not enough time to perform the role and not enough support from the team. Availability tends to be an issue when the product owner role is just one of many jobs competing for time and attention or when the product owner looks after too many products or teams. Not enough support from the team is rooted in a wrong understanding of product ownership: Even though there is one product owner, most of the product owner work is carried out collaboratively. The team and ScrumMaster must support the product owner.
To avoid an overworked product owner, try the following:
- First, free the individual from all other responsibilities. Start with the assumption that being a product owner is a full-time job, and that one product owner can look after only one product and one team.
- Second, ensure that the team makes time in every sprint to collaborate with the product owner. Scrum allocates up to 10 percent of the team’s capacity in every sprint for supporting the product owner (Schwaber, 2007). Not only does collaboration spread the work across many shoulders, but it also leverages the team’s collective knowledge and creativity.
The Partial Product Owner
Some organizations split the product owner role and distribute its duties across several people—for instance, by employing a product manager and a “product owner.” The product manager takes care of the product marketing and product management aspects, owns the vision, is outward-facing, and keeps in touch with the market. The “product owner” is inward-facing, drives the sprints, and works with the team. In these cases, the so-called product owner is little more than a product backlog item writer. This approach reinforces old barriers, blurs responsibility and authority, and causes handoffs, delays, and other waste.
Instead of splitting the product owner role, organizations should face the challenge of applying the role properly. One person should be in charge of the strategic and the tactical product management aspects. This may well require organizational changes, including adapting job roles and career paths and developing individuals to take on a rich set of responsibilities.
The Distant Product Owner
A distant product owner works separately from the team. Distance may evoke images of a globalized world with the product owner on one continent and the team on another. But distance comes in many forms and degrees. It starts with working on the same site in different rooms, and it ends with product owner and team being separated across continents and time zones. I have found recurring issues with distant product owners, including mistrust, miscommunication, misalignment, and slow progress. There is a reason: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
Avoid distant product owners by colocating all Scrum team members. As mentioned earlier, mobile.de experienced a significant productivity and morale increase after colocating its product owner, ScrumMaster, and team. If colocation is not an option, the product owner should spend as much time as possible in the same room as the rest of the Scrum team. Remote product owners should be on-site at least for the sprint planning, the review, and the retrospective meetings. Moving from a distant to a colocated product owner often takes time. It may require hiring and training a local product owner. In some cases, it may also require rethinking the company’s product strategy, including where the company develops its products.
The Proxy Product Owner
A proxy product owner is a person acting as a placeholder for the actual product owner. I have found proxy product owners used to compensate for overworked, partial, and distant product owners. At a client of mine, the vice-president of product management was asked to take on the product owner role for a business-critical product. Even though he was ideally suited for the job, he struggled to spend enough time with the team. The business analyst on the team consequently stood in as a proxy product owner when the real product owner could not be there. The proxy did most of the product owner work without being empowered. The actual product owner ultimately decided about product backlog prioritization, release planning, and whether to accept or reject work results. What followed was an increase in conflicts and miscommunication, a slowdown in decision-making, and a decrease in productivity and morale.
Using a proxy product owner is an attempt to superficially treat a systemic issue. Rather than employing a quick fix, organizations should address the underlying issues. This might require freeing up the product owner from other obligations; colocating the product owner, ScrumMaster, and team; or even finding a new product owner.
The Product Owner Committee
A product owner committee is a group of product owners without anyone in charge of the overall product. There is no one person guiding the group, helping to create a common goal, and facilitating decision-making. A product owner committee is in danger of getting caught in endless meetings with conflicting interests and politics—something also referred to as “death by committee.” No real progress is achieved; people stop collaborating and start fighting each other.
Always ensure that there is one person in charge of the product, an overall or chief product owner who guides the other product owners and facilitates decision-making, including product backlog prioritization and release planning.
Summary
Applying the product owner role effectively is not only key to developing successful products with Scrum. It is also a learning process for the individuals playing the role and for the organization. As making mistakes is part of that process, don’t expect to apply the role perfectly from day one. But watch out for the traps discussed above. Ensure that there is always one product owner responsible for each product in your organization. (If more than one product owner is required, use a product owner hierarchy with a chief product owner in charge of the entire product.) Make sure your product owners are empowered, have a realistic workload, and can work with their teams onsite. This will allow you to apply the role effectively thereby increasing the likelihood of developing successful products.
Find out more about the product owner role and how to apply it effectively in my new book Agile Product Management: Creating Products that Customers Love, Addison-Wesley.