Who should be your (Scrum) Product Owner?
I’ve had a number of these conversations recently with small, boutique software development agencies and even design companies with UX expertise. Typically, the conversation goes something like this:
- The business stakeholder or client is the owner of the product, so they should be the Product Owner
- We’ve got a Product Manager, so they should be the Product Owner?
- The Development Team is supposed to self-manage, so they can just share the Product Owner role
- Decisions about the scope and what the Development Team should work on is far too important for just one person, so we should have a committee make the decision.
The Scrum Guide (2013) is pretty specific about what the role of Product Owner is and what it does:
“The Product Owner is responsible for maximising the value of the product and the work of the
Development Team. How this is done may vary widely across organisations, Scrum Teams, and
individuals.
“The Product Owner is the sole person responsible for managing the Product Backlog… [the role requires] is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner [1].”
The implications are significant. Ultimately, it means managing the Product Backlog in such a way so as to achieve balance between optimisation at the delivery (Team) level and the vision of the product.
Different Product Owners
Client as Product Owner
In my experience, when push comes to shove, and the end of funds is near or the project is running out of time, a client won’t throw Scrum aside and push for more features. I’ve often heard them say, “you’re agile, so that means you just have to learn to adapt”.
- Advantage: Clear view of the vision
- Disadvantage: Doesn’t care about your Scrum process. Won’t truly understand balancing technical features and technical debt over features and functionality.
- Result: Features! Features! Features!
Business Analyst as Product Owner
A senior B.A. is a whiz at managing scope and interpreting clients’ needs. Unfortunately, they are often too low down the pecking order to be given responsibility for delivering an outcome.
- Advantage: Product Backlog Lumberjack!
- Disadvantage: Often not empowered.
- Result: Wait until I go ask someone and then I can tell you the decision.
Scrum doesn’t say where that vision needs to come from, though. It could come from the client, a Product Manager, a Program Manager or the executive leadership team in a large enterprise.
Project Manager as Product Owner
A Project Manager’s focus is not too dissimilar from a Product Owner’s. He maximises the ROI of a project, manage stakeholders and communication, its finances and changes to its scope.
- Advantage: Often have the power to make decisions
- Disadvantage: May not be technical enough to create balance between the technical needs of a product and the needs of the requirements of clients. May tend to blur the line between the “what” and the “how” and micromanage the Development Team to deliver an outcome. Scrum key meetings may fall by the wayside as a result to make more time to code.
- Result: You should be coding not being in meetings so much!
UX Designer/Architect as the Product Owners
I came from a UX background. It influences my Scrum practice quite heavily in terms of optimising the Product Backlog so that it delivers value to end-users. As such, when I perform the role of Product Owner, I’m always conscious of building a product with a user-centred vision, and balancing good UX with technical features and the “nice to haves” that clients ask for.
- Advantage: User centred perspective.
- Disadvantage: Like a BA, may be too low level to be empowered. May “gold plate” the UI and not care how long it takes the Development Team to deliver.
- Result: This would be good for users, but the Project/Product Manager/Client has overridden me and wants more features.
Product Managers as Product Owners
I find that Product Managers, like Program Managers, are just too high level and too concerned with larger things to get their hands dirty at a local, Development Team level. Their responsibilities often mean there is little time to spend in key meetings relating User Story level details to a Development Team.
- Advantage: Have the vision and are empowered to achieve it
- Disadvantage: May not know how to translate that vision into items for the Product Backlog. May not have the time to dedicate to collaborating with the Development Team to deliver the outcome because they are spending more of their time with senior stakeholders.
- Result: Here is the big picture, now just do it!
Line Managers as Product Owners
In an organisational context, Managers can be quite effective Product Owners. They already have experience telling their teams what to do. Empowerment is an important key aspect of being a good Product Owner, and in environments with an existing hierarchical structure, this is one of my favourite patterns.
- Advantage: They are empowered to make decisions.
- Disadvantage: May be too used to micromanaging their team.
- Result: Agile aside, what do you need to deliver?
So, who could be the Product Owner
My favourite Product Owners are senior BAs with enough referent power on the client side to help shepherd them to good decisions regarding the vision, enough expertise to manage the scope of the Product Backlog themselves to deliver a high-value product, and with experience with Scrum so that they respect the process.
Ultimately, there is no best person for the role other than someone who is empowered to make decisions, balance the short and longer term vision of delivery, and has experience with Scrum sufficient not to throw it away when things get tough.
Hierarchy and Product Owners
But sometimes one Product Owner is not enough. And when there is a whole program of work and many teams, what happens to the Product Owner? Can he make the same decisions independent of other Product Owners?
Program Management and Product Owners
In SAFe, the high-level vision comes from the Program Manager who collaborates with a number of Team-level Product Owners.
This model is quite logical in an enterprise with an existing management hierarchy, particularly where the vision of the product is made at a level higher than the Team.
Chief Product Owners and Local Product Owners
In LeSS, that superordinate view of the direction of the product as a whole comes from a (Chief) Product Owner who then engages Area Product Owners.
In more decentralised Team environments, an Area Product Owner (APO) specialises in a customer-centric area and acts as Product Owner in relation to one or more teams for that area. An Area Product Owner does the same work as a Product Owner but with a more limited, yet still customer-centric, perspective.
Understanding the governance between the strategic, tactical and delivery aspects of a program of work is key to understanding who is the best person to be the Product Owner. Ultimately, it can be anyone, so long as “the entire organisation must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog [1]”.
Conclusions
The Development’s Team’s focus is often to build the product right, making sure it works and the code is of good quality. The Product Manager’s focus is on achieving the vision, but not necessarily on the detail to make it work. The clients’ focus is all about features features features!
Ultimately, the role of the Scrum’s Product Owner is the focus point of all these conversations. It has to be one person, not many, otherwise decisions may take too long, the focus might lean too much toward the higher (product management) or lower perspective (team’s delivery), or the governance watered down so that no one is the “go to gaol” person when things go poorly.
Who ever you decide on making your Product Owner, ensure they are:
- Empowered to make decisions.
- Can be pragmatic in creating a balanced outcome between the vision and delivery.
- Know and respect Scrum, so they make it all work through collaboration with the Development Team, the Scrum Master and the customer (who ever that might be).
M
[1] Schwaber, K. & Sutherland, J. 2013. The Scrum Guide™ The Definitive Guide to Scrum: The Rules of the Game. p5.
