Applying the product owner role can be challenging. The role has diverse responsibilities, and its application is context-sensitive: it varies depending on the type of product, the product lifecycle stage, and the people involved. This post will help you recognise some of the most common product owner challenges.
The Underpowered Product Owner
A product 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 authority. 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.
If you feel that you should increase your product owner power, then take a look at my article Boost Your Product Leadership Power.
The Overworked Product Owner
Being overworked is not just unhealthy and unsustainable on a personal level; overworked product owners can become bottlenecks and limit the progress their products make. Symptoms of an overworked product owner include neglecting product discovery and strategy work, and product backlog refinement, missing sprint planning or sprint review meetings, and not being available for questions.
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 performed collaboratively. The team and Scrum Master must support the product owner. Scrum allocates up to 10% of the team’s availability in the sprint to work with the product owner, for instance, to break down and refine product backlog items together.
The Partial Product Owner
Some organisations 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 strategic 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.
The Distant Product Owner
A distant product owner works separately from the team. This can range from working on the same site in different rooms to 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,” as the Agile Manifesto for Software Development states.
You should hence aim to collocate product owner, Scrum Master and team. This can give you a significant productivity and morale increase. If that’s not an option, then try to partially collocate people make, for example, by spending the first few sprints together and then working in the same office at least once every three months. Additionally, make sure that you effective use remote working tools like video calls.
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. For instance, a business analyst who does most of the product backlog grooming work and answers questions from the team on a daily basis is a proxy for the actual product owner who decides the product backlog prioritisation and accepts or rejects work results at the en of the sprint. Using a proxy product owner is an attempt to superficially treat a systemic issue. Rather than employing a quick fix, you should address the underlying issues.
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.”
Always ensure that there is one person in charge of the product who guides the other product owners and facilitates decision making, including product backlog prioritisation and release planning, as my post Scaling the Product Owner explains.