Avoiding Common Product Owner Mistakes

Posted on Monday 1st February 2010

Summary

Applying the product owner role is challenging, and the path to effective product ownership is littered with pitfalls and traps. This post will help you avoid some of the most common product owner mistakes.

27 Flares Filament.io 27 Flares ×

Applying the product owner role can be challenging. The role is multi-faceted, has a wide range of responsibilities, and its application is context-sensitive: It varies depending on the type of product, the product lifecycle stage, and the project size, the domain knowledge of the team amongst other factors. It’s not surprising that the path to effective product ownership is littered with pitfalls and traps. This post will help you recognise and avoid some of the most common product owner challenges.

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 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.

Underpowered Product Owner

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. 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 ScrumMaster 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 decompose and refine product backlog items together.

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 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.

Partial Product Owner

The Distant Product Owner

A distant product owner works separately from the team. This can range form 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 colocate product owner, ScrumMaster and team. This can give you a significant productivity and morale increase. 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.

Distant Product Owner

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.

Proxy 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.” Always ensure that there is one person in charge of the product, a chief product owner who guides the other product owners and facilitates decision making, including product backlog prioritization and release planning as my post “Scaling the Product Owner” explains.

Product Owner Committee

If you enjoyed reading this post, you will love my book Agile Product Management with Scrum: Creating Products that Customers Love. The book discusses common product owner mistakes in more detail and provides advice on how to rectify them.

22 comments on “Avoiding Common Product Owner Mistakes

  1. Fantastic post Roman. I’ve seen in many larger organizations where they have a number of business analysts that each takes over the PO role for a portion of the overall application, depending on the size of the app. Have you encountered that, and has it worked well?

    • Hi Robert, Thanks for the feedback. Glad you liked the post. I’ve seen business analysts taking on the product owner role and looking after a product part work very well — as long as they form part of a hierarchy of collaborating product owners headed by a chief product owner and as long as they are empowered to do their job well.

  2. [...] the article here: Avoiding Common Product Owner Mistakes « All Things Product Owner … Share and [...]

  3. product life cycle…

    Last Sunday I visit your Avoiding Common Product Owner Mistakes ” All Things Product … site ,I have a special experience after reading your product life cycle site/blog….

  4. [...] and appropriately empowered. And watch out that as a business analyst, you do not morph into a proxy product owner. Be either a team member or the product owner, but not a halfway [...]

  5. [...] and appropriately empowered. And watch out that as a business analyst, you do not morph into a proxy product owner. Be either a team member or the product owner, but not a halfway [...]

  6. [...] is important to give product owners enough time to sustainably carry out their responsibilities. If the individual is overworked, the project’s progress suffers and the resulting product may be suboptimal. Being adequately [...]

  7. [...] is important to give product owners enough time to sustainably carry out their responsibilities. If the individual is overworked, the project’s progress suffers and the resulting product may be suboptimal. Being adequately [...]

  8. [...] Apply the product owner role pragmatically: Spilt the role across several people or work with a product owner committee. [...]

  9. [...] the product owner role Scaling the product owner Avoiding common product owner mistakes Desirable characteristics of a product owner Product owner = product manager? This entry is filed [...]

  10. Mark S. says:

    This post has pointed out several methods that we have used to unsuccessfully develop product owners. The issue we have is primarily Product Owner participation. The Department Managers have taken on this role yet cannot fulfill the time commitment to the team, yet they will not empower others with the authority that the Product Owner needs to perform their role effectively. How do you approach this situation?

    • Hi Mark, I recommend you employ a retrospective to discuss and analyse your challenges – together with the product owner. Help the product owner understand why it is problematic that an individual plays the role who does not have enough time, and search together for a solution.

  11. Change Rob says:

    These are great, and here’s another…Product Owners whose business line managers disincentivise the Product Owner role/responsibilities.

  12. Andreas P says:

    Regarding the distant PO, there is still some gain in not beeing too close, as tends to hamper the team independence a bit (just a bit) and their own innovativeness and reponsiblility go down some.

    Otherwise I agree, these are the basic no-can-do’s

    /Andreas

    • Thanks for the feedback, Andreas. I favour a close collaboration between product owner and team, and I often recommend to product owners to hot desk in the team room or to even collocate with the team. But I agree: The team must be empowered to decide how much work is pulled into the sprint, how the product increment is created, and who does what.

  13. [...] http://www.romanpichler.com/blog/avoiding-common-product-owner-mistake/ Share this:TwitterFacebookVind ik leuk:LikeWees de eerste om post te waarderen. [...]

  14. Amit Joshi says:

    In a scrum methodology, having both roles available i.e. Product Owner & Business Analyst for a project.

    How the roles are different to each other in the project?

    Who is responsible to do impact analysis of the requirements those are raised by Product owner as user stories? Is it product owner or business analyst in the project?

    Thanks.

  15. Amit Joshi says:

    Roman, thank you for the response.

    I am still looking for answer of a specific query.

    Product owner gathers a requirement and share it as an user story with the scrum team.

    My question is that who shoudl be responsible to do impact analysis on the User story. Is it product owner or business analyst, if both are available in the team?

  16. Amit Lohia says:

    Good one . . . . really interesting as i also played one of the role . . . . keep it up and want more . . . thanks :)

Leave a Reply

Your email address will not be published. Required fields are marked *

* Copy This Password *

* Type Or Paste Password Here *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>