A Product Owner arguably, is one of the most demanding roles in Scrum. Product Owner is, single handedly responsible for the success of the project and is expected to lead the development effort by conveying the vision to the team. He is expected to help the team produce maximum business value. Is this expecting a lot from a single role?
Maroko Taipale suggests various reasons to justify that the single product owner model is broken. According to Maroko, following the product owner role by definition would lead to various inefficiencies.
He suggested that instead of having a single neck on the line, the teams should have a concept of customer development and product development in parallel. Customer development is a process of defining and understanding the user so that the right product can be built. Product development then kicks off with the feedback received from customer development and this process goes on.
There should be two teams who lead the above processes. The 'problem team', which is all about 'what' and the 'solution team' which figures out the best way to solve the problem. The problem team consists of sales, marketing, executives, technology, usability, quality folks and the solution team consists of cross functional development team and the same people from quality, usability and technology who are on the problem team.
According to Maroko, this collaboration works with various advantages,
Both teams try together to maximize the value. Problem team is trying to achieve this by figuring out who is the customer and what is a problem that is worth of solving. Solution team is providing transparency to the market feedback .. usually in form of solution based statistics.
The benefits include
- Improved information and knowledge sharing
- Better alignment towards the goal
- Multiple views on customer's needs
- Channel for constructive feedback
- Multiple communication points
- Shared team vision
Likewise, Roman Pichler suggested that as soon as a project grows from the realms of a simple project, there is need for more than one product owner. He suggested the use of a product owner hierarchy with a chief product owner.
Product owner hierarchies vary from a small team of product owners with a chief product owner to a complex structure with several levels of collaborating product owners.
Mike Cottmeyer acknowledged that the Product owner role is too complex to be filled by a single person in many circumstances and needs a team to deliver. According to Mike, instead of one person who fills in all these roles, it could instead be a Product Owner Team where multiple people coordinate together. The team could include
- Product Manager- Works with stakeholders, identifies requirements and sets priority.
- Project Manager- Maintains a view of the overall objectives. Manages resources, capital expenditures, external dependencies etc.
- Business Analyst- Responsible for documenting acceptance criteria and documenting the conversations around the user story. Primary point of contact for requirements clarification during the sprint.
- Designer- Prepares some screen shots, wireframes, etc.
The Product Owner Team must be relatively small and empowered, but have all the people necessary to serve the role of Product Owner for the team. This group must be able to decompose the product backlog according to the INVEST principles. This is a big job and usually implies that the Product Owner team has representation from at least: Product Management, Project Management, Architecture, Development, Quality, and Business Analysis.
Thus, there seems to be a general consensus that apart from relatively simpler projects, the single product owner model might not work in many situations.
What has been your experience?
Community comments
I could be wrong but...
by Mr Magoo,
Re: I could be wrong but...
by Matt Block,
Re: I could be wrong but...
by Charles Bradley, Scrum Trainer...,
Re: I could be wrong but...
by Marko Taipale,
Re: I could be wrong but...
by Marko Taipale,
Split into tactical and strategic decisions
by Thomas Karlsson,
I could be wrong but...
by Mr Magoo,
Your message is awaiting moderation. Thank you for participating in the discussion.
I am crying straw man here. It is not that I disagree just that this discussion assumes a premise that was never true AFAIK.
Isn't the concept of a product owner that they have the final say rather than the only say? Is not the concept of a "PO's team" already embedded in agile? I mean are we seriously suggesting that all agile teams working on complex projects are supposed to do away with BAs and designers etc? That all that work is reduced to one person's responsibility?? I think not. This would not scale.
The above breakup of responsibilities and roles is pretty much in line with what should happen because of the line:
"Product Manager- Works with stakeholders, identifies requirements and sets priority."
As long as this is maintained the PO (obfuscated here by changing the name slightly) is fulfilling their own role and delegation is part of what they do.
I think these people have been following the instructions for tiny teams working on small apps rather than major products and assuming this is the rule for all.
Re: I could be wrong but...
by Matt Block,
Your message is awaiting moderation. Thank you for participating in the discussion.
I have to agree with Mr. Magoo. I don't think anyone has ever said that a single person does all of those things, just that a single person represents that on the team and has final say. The problem with expanding this to a team without having a clear single person with final say is that you end up with a lot more people involved in the process which hinders communication, which, in turn, hinders collaboration which is at the heart of agile development. If your team isn't collaborating you probably aren't getting very effective results from agile. I've seen this first hand working with a single development team that worked on a product suite. We had a "product owner" for each product within the suite, and it was very confusing for the team to know who to talk to when. Communication was very low and so was collaboration. We changed the model so there was one Product Owner for the team who has the final say and communication and collaboration have greatly improved. The new product owner works very closely with the individuals that were playing that role for each product before as well as with a designer, but the new product owner has the final say and is the single source for questions from the rest of the agile team.
Re: I could be wrong but...
by Charles Bradley, Scrum Trainer...,
Your message is awaiting moderation. Thank you for participating in the discussion.
+1
Re: I could be wrong but...
by Marko Taipale,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi Mr Magoo,
"Isn't the concept of a product owner that they have the final say rather than the only say?" I'd think yes.
"Is not the concept of a "PO's team" already embedded in agile?"
Practitioners have implemented different kinds of "PO teams" but the Scrum Guide (that I refer as the definition) does not mention such.
According to my experience PO teams usually are just "collection of POs from various product areas" as demonstrated by Roman rather than what I suggest (problem team). I think there is a real difference since the problem team has more diverse skillset which leads to better products.
You state your assumption that "these people have been following the instructions for tiny teams working on small apps".
I do not know what's your "big" and "small", but here is two examples what I've done:
I have been transitioning an organization into 10+ Scrum teams (maintaining over 60 products on top of two different product platforms) having PO groups and Chief PO (product owners with CPO only - which I think is was not an optimal solution), 140 people in company wide synced sprint plannings, 6 week company wide sprints with full scale company wide CI.
I have also implemented scrumban for a startup which naturally is totally different beast.
That said I think I get the difference of "tiny teams" and "major products" and I am NOT assuming there is a rule for all. In my post I am rather criticizing the "naive" implementations of Single Product Owner model (that I still see in coaching gigs) and offering one real life example to think about. I am also challenging the PO role itself as I think it can (and many times is) just a function - this is especially true in Kanban initiatives where no new roles are established.
I think we should share real life implementations (withing a context) more in order to learn from each other instead referring to ambigious "PO group".
Also feel free to comment the blog post :)
Re: I could be wrong but...
by Marko Taipale,
Your message is awaiting moderation. Thank you for participating in the discussion.
"The problem with expanding this to a team without having a clear single person with final say is that you end up with a lot more people involved in the process which hinders communication, which, in turn, hinders collaboration which is at the heart of agile development."
I think you are confusing having "single person" with "having a lead". I think it is perfectly ok to have single person to have final say (that I also have stated in the comments of my blog post). However I disagree that one person makes the communication MORE effective or the process more collaborative.
Practically speaking I think great products needs more than product vision and BL items to be communicated over to the "team" - for instance the user experience vision and acrhitecture vision. Single PO as the "communicator" of these elements is a bottleneck and often does not have the skillset nor the knowledge to communicate these elements properly. Naturally "single PO" can facilitate the communication / delegate but then again PO becomes bottleneck due to lack of time to "do it all" (customer development, stakeholder engagement, BL management, communication facilitiation, team support...).
If the model you describe here has worked for you then I am happy for you and encourage you to continue that track.
Split into tactical and strategic decisions
by Thomas Karlsson,
Your message is awaiting moderation. Thank you for participating in the discussion.
I agree that there are some real issues with the one Product Owner.
In some settings it just won't work to have a single person being responsible for all decisions.
I believe sometimes it is necessary to distinguish between tactical and strategic decisions. Tactical decisions should always be taken by one single person. Strategic decisions might be taken in a larger group.
This should fit both with CPO / PO hierarchy and with business-facing / team-facing solutions advocated by some.
Here are my thoughts on the topic:
agile-management.com/wordpress/product-owner-is...