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.
Post a Comment or Ask a Question
19 Comments
I love this article. I am a Product Owner facing many of these issues, and it is great to see them here articulately realized. The problem is that everybody has an opinion of Agile product delivery and it’s normally one that suits them best not the overall team or product.
Thanks for your comment Jim. I am glad that you liked the article. I write more about agile product delivery here: Succeeding with Product Delivery and Scrum: 10 Tips for Product People Hope this helps!
The article gives me the impression that having a product owner and a product manager is bad. In big organizations or for large products, both roles are needed.
Thanks for sharing your perspective Carlos. Using a strategic product manager role and a tactical product owner one is the scaling strategy suggested by SAFe. But you can happily manage a large product without using the two roles, as I explain in my article Scaling the Product Owner Role. Hope this helps.
Hi Roman,
great article, even 7 years on it’s still hitting the nail on the head! I had a question in relation to the Proxy PO, which seems like an “anti-pattern”. But in some scenarios, when the “real” PO is a paying customer and the Scrum team is an external contract team, does it make sense?
The reason I ask is that a lot of our clients just don’t have that much interest in being involved a Scrum process nor do they want to be dealing with the developers directly; they just want their weekly or bi-weekly update. However they’re also not great at deciding entirely what they want up-front either 🙂 So we end up with a kind of semi-waterfall, semi-agile type development process. (Internally we use sprints but the customers could care less really)
In these cases we use the PO as both a proxy to *and* ambassador from the client, in the sense that their job is to be very familiar with both the customer’s business and the problem domain in general, so that if we on the dev team ask something like “hey, you asked for X but we think Y is way better” they know enough to either say “Well that’s because there is a law that requires Y for this client’s business area ” (so, the business domain), or “We have to use Y because this specific customer’s clients depend on it” (client knowledge) or maybe “Hmm, yes you know that will work just fine, go for it”
And where it’s unknown, they can go ask the “real” customer and feedback to the team, albeit not in “real-time”.
Does that sound like an effective PO role to you in the context of a contract dev team situation? If not, would you have any suggestions for what we might call this role?
Thanks!
Hi Stephen,
Thanks for your feedback and question. I generally recommend to ask the client play the product owner role or to be a stakeholder and assign ownership to the agency (supplier), as this creates clear responsibilities and ensures effective decision-making. The first option is preferred for me, and it’s the model I have been using for many years with the agency that designs and develops this website. It gives me full control over the product, but it requires me to make myself available and work with the team (which I enjoy btw).
The second option still sees the client involved in the development process, for example, by attending sprint reviews or testing early product increments, but the product decisions lie with the agency product owner and must be accepted by the client organisation. To make this work, I recommend first agreeing on a product strategy that states the value proposition, target market, key features, and business goals of the product and possibly a product roadmap. This sets a joint direction and provides the agency product owner with the context to make the right decisions.
Does this help?
I like this article and reference it regularly with leadership teams who are struggling to assign a proper Product Owner. I find it helpful to show leadership this page, and point out which “common mistake(s)” a project is currently facing, and describing the impact of the mistake(s). I’ve been able to drive changes with this method. Thanks to the author for writing and maintaining this.
Good one . . . . really interesting as i also played one of the role . . . . keep it up and want more . . . thanks 🙂
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?
Hi Amit,
Working with user stories and the product backlog is a collaborative effort. The product owner should ensure that the backlog contains helpful items, and the team members help the product owner adapt the backlog based on the latest stakeholder feedback. This includes analysing the impact of any changes. You can find out more here:
https://www.romanpichler.com/blog/grooming-the-product-backlog/
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.
Hi Amit,
Thanks for your questions. I have written about the role of business analysts in Scrum here:
https://www.romanpichler.com/blog/business-analysts-in-scrum/
Please let me know if the post doesn’t answer your questions.
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.
These are great, and here’s another…Product Owners whose business line managers disincentivise the Product Owner role/responsibilities.
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.
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.