It is more important to build the right thing than build the thing right. That's why this is important.
This post is based on personal experiences and the feedback that I've gotten from hundreds of individuals I've been working with:
"Product owner (PO) model seems to be broken",
"PO is a superman, nobody can do that", "single PO is bad idea" etc.
The motivations to write this is are: 1) find better models 2) provoke you to share about your experiences 3) provoke the community to challenge existing models 4) Books and courses about product ownership seem to concentrate on backlog management and scrum. I find that secondary to figuring out what should be done and when 5) .. finally describe the problem to some people asking me about "why do you think single product owner model is broken" in twitter. (@rowanb @hkokko @romanpichler @toolsforagile ...) :o)
What is a product owner by definition and how it is broken:
1. "the Product Owner, who is responsible for maximizing the value of the work that the Scrum Team does"We together as organization are here to max value. It should not be only PO's responsibility though it might be a good idea to have one person looking after that value constantly. Team should challenge the value proposition that PO is stating in order to improve it. Team should be driven by the goal(s) to maximize the value instead of externalizing it to PO role.
2. ".. The Team consists of developers with all the skills to turn the Product Owner’s requirements into a potentially releasable piece ..."This underlines the PO bottleneck problem. They are not truly POs requirements but stakeholders'/customer's requirements that are flowing trough a PO proxy. It is a bad idea to form such a bottleneck for information flow. In addition I would not like to have "one hearsay" talking about what the customer wants.
The guide and CSM courses have notion that ScrumMaster can teach PO. That's just naive - Most of the certified scrum masters/practitioners that I know have zero knowledge how to study the demand from the customer to understand how the value could be maximized. They often do know how to do backlog management.. but that is typing exercise once you know what needs to be build. Very few ScrumMasters know anything about customer development, business model generation, feature injection, defining MVP etc.
What makes this even worse is that organizations "promote" their POs from "ex-QA guy" or "ex-project manager" who has not been working with these kind of tools. CSPO (certified product owner) does not help here either - you get to hear about storymaps/product visioning, but it is not a product management/business analysis training (I am not saying it even should be).
3. "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." Yes, we need one being eventually accountable might be the PO or might not.
Ensuring value is just a joke. Customer and your market will tell if you are producing value and you should not give that as "responsibility" to single person in your organization. I rather have transparency to the
realized value all the time and want my people to think how to improve on it. For most of the organization
"definition of done" ends to
"stuff released" and they might be happy about their velocity (
"we are so productive") but that
all is meaningless as long as you do not measure the realized value and act on it (for instance by removing not used/invaluable features).
For project organization that works on subcontracting "stuff released" though might be "good enough" - if your contracts are not aligned with customer's goals (realized value).
4. "For commercial development, the Product Owner may be the product manager." Not such a good idea. Here is a
slide deck explaining the difference of there roles. One practical issue is that product managers are so busy on figuring out the problem to be solved that they won't be there to support the team (as PO role is defined)
5. "Committees may exist that advise or influence this person, but people who want to change an item’s priority have to convince the Product Owner." So there we have it, we should have a team to help the PO.
PO is a collaborator for the team ... which is good ... but shouldn't he be studying and developing customers? Smell of contradicting priorities - who to serve and when. I do not want to have this bottleneck.
6. "The Product Owner identifies what has been done and what hasn’t been done." Why? Why don't we have agree definitions and better transparency - we should all know when it is done and we all are working for the same goal.
On practical side of the things: we do not demonstrate the results of our work for our CEO (who could be the product owner) as we found that to be bottleneck for getting the stuff out. This of course requires that we have very good understanding of the goals and we have evolved our "Definition of Ready and Done" into something that our CEO can trust.
If you are subcontractor you might want to have the "demo acceptance" by "a customer representative". Context.
7. "The Product Owner is responsible for the Product Backlog, its contents, its availability, and its prioritization."This leads to waiting as items are not available / good enough to be developed. The people doing the work are best to estimate when something is good enough to be developed - POs usually do not have that skill and if they are more than "backlog management PO proxies" they wont have the time to do this.
8. "The Product Owner keeps an updated Product Backlog list Release Backlog Burndown posted at all times."Anyone can do this, it is about .. big word .. trust.
Context
You might find my angle weird. Take a look at
this slide and ask yourself which product owner role you have in your organization. I am talking about big Ps preferably in
goal driven context.
Alternative: Problem and Solution team
"All models are broken, but some are useful". Some are even more useful than others so here is model that I think works better than single PO model. Some might find this model familiar since it is mentioned several times in various #leanstartup sessions.
I start by sharing two diagrams: 1) customer development as a parallel process to product development. You might not be doing customer development but you are doing "something to figure out what should be done" - consider that as your parallel process.
Second diagram to demonstrate how the problem and solution teams are working on these processes:
The teams are working simultaneously, exchanging hypotheses, findings, problems and solutions.
Problem teamThe goal of the problem team is to find out and define the problem to be solved. This team is all about "what".
Members:
- Sales
- Marketing
- Executive(s) (accountability)
- Technology
- Usability
- Quality (testing, QA/QC whatnot)
- Support
Solution teamThe goal of the solution team is to figure out best possible way to solve the defined problem. This team is all about "how".
Members:
- Cross-functional development team including:
- Same technology representative who is in Problem team
- Same quality representative who is in Problem team
- Same usability representative who is in Problem team
Collaboration (overlapping)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.
.. within a contextStartup
In startup the teams may overlap heavily - it may be that the team members for both teams are the same.
Enterprise
In enterprise the teams may exist for each product line / project and the overlap might be restricted to only few team members.
Benefits compared to single product owner modelAccording to my experience problem-solution team model (compared to single product owner model) provides:
- Improved information and knowledge sharing about the problem and the solution
- Better alignment towards the goal and shared responsibility about value creation
- Multiple views on customer's needs (for instance not only product vision but also architecture and usability vision)
- Channel for constructive feedback (in a form of feedback loop from the solution team)
- Multiple communication points avoiding the issue of "PO knows it all as he is only one talking to the customer"
- Focus on shared team vision and discipline instead of "individuals and interactions"
Things to consider - If you are in a context where you just "execute the big-upfront-planned-requirements" .. you just need "requirements management"
- If you need firewall for the team from several stakeholders then you might prefer single product owner model (or proxy between solution/problem teams)
- Contracting model (in subcontracting) may prefer single product owner model
- Maybe you do not need either models. You might have working model and your product managers in place with their MBAs - beware dogma - product ownership is a function to be carried out not a role :o)
Real life examplesEnergized work product streamHuitale's problem-solution teamPhoto credit: Darwin Bell @ flickr
