Agile Product Management with Scrum : Chapter 1 : Understanding the Product Owner Role
In which I summarize the first chapter in Roman Pichler’s Agile Product Management with Scrum, on understanding the product owner role.
Chapter 1 Summarized
Here’s what I took from the first chapter of the book. (A previous post treated the preface .)
Design by committee is problematic at best. Handoffs and telephone games yield a lost-in-translation effect. Multiple people sharing ownership over product vision is a lot like saying no one owns the product vision, and has that effect.
The solution is “putting one person, called the product owner, in charge of the product”.
On the authority of the product owner
Pichler quotes Schwaber’s Scrum Guide:
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. This person maintains the Product Backlog and ensures that it is visible to everyone.
And himself writes:
The product owner is a new, multifaceted role that unifies the authority and responsibility traditionally scattered across separate roles…
I think that was the one thing that most struck me in this chapter - the tremendous extent to which a product owner needs the trust, confidence, and support of the organization and of the team in order to succeed.
Characteristics of a product owner
Product owners are
- visionaries and doers
- leaders and team players
- communicators and negotiators
- empowered and committed
- available and qualified
Visionary and doer
a visionary who can envision the final product and communicate the vision
Also, a doer who
- describes requirements
- closely collaborates with the team
- accepts or rejects work results
- steers the project by tracking and forecasting its progress
Involve customers and users early and continuously. Identify and involve stakeholders.
Leader and team player
The product owner is part of the Scrum team and closely collaborates with its other members.
The Scrum team itself is self-organizing, cross-functional, and small, including all the roles needed to bring the product to life.
Change Scrum team compositions infrequently, since team composition change disrupts team building and symbiosis. Associate Scrum teams with products long-term. Ideally a single team will own a product for its entire lifespan. This fosters ownership, responsibility, and empathy, acting in the best interest of the product (rather than as a one-off fly-by effort from the perspective of just one episode in the product’s longer story arc.)
Co-locate the team. That includes the product owner and the scrum master and the whole team, of course. There’s a lot of opportunity for the team room to be conducive to awareness, collaboration, and enjoyment.
Pichler describes a dual nature to the leader and team player role, a “hard line to toe”, a nuanced role hard to get right. The product owner should at once be decisive and particularly able to shepherd the team through hard decisions about the product and yet must not be dictatorial. No one wants the badly behaved aspects of Steve Jobs, just the vision and hard tradeoffs to deliver great products.
Pichler advises making decisions collaboratively with team buy-in, requiring facilitation and patience with the team often needing to disagree and argue first before a solution is synthesized.
Communicator and negotiator
Communicates with and aligns:
- customers
- users
- development
- operations
- marketing and sales
- management
The product owner is the voice of the customer.
The ScrumMaster is the voice of the team and of the Scrum process. The product owner is primarily responsible for creating the right product. The ScrumMaster is primarily responsible for creating it in the right way.
One individual should never fill both the product owner and ScrumMaster roles (for one thing, it’s hard to negotiate effectively with and provide an appropriate check and foil for oneself!)
Empowered and committed
The product owner must have enough authority and the right level of management sponsorship to lead the development effort and align stakeholders.
There’s something to senior management picking and supporting product owners, so that senior management is invested in their success.
Available and qualified
Being the product owner is usually a full-time job.
Product owner availability as essential, with negative consequences to the product if the product owner is insufficiently available.
Product owners should spend at least an hour a day with the team in the team room.
Scaling the product owner role
Pichler has some thoughts on scaling the product owner role. I do not think I currently have this scale problem so I am leaving off on summarizing those thoughts.
Common mistakes
My favorite feature of Pichler’s book is his highlighting common pitfalls or anti-patterns related to the topic of each chapter.
Anti-pattern: Underpowered product owner
In this anti-pattern, the product owner lacks empowerment due to
- not enough management attention
- no or wrong level or wrong person management sponsorship
- management failure to delegate decision-making authority due to lack of trust or otherwise
Consequently, the product owner is ineffective, unable to make decisions, has his or her decisions continually second-guessed or countermanded by management, and is in general undermined.
The team can tell when the product owner lacks the support to make decisions and cannot follow through on the fundamental social contract of Scrum (that the Product Owner is responsible for and will defend the value in what he or she asks the team to do, so the team can focus on how to best deliver on the vision). Scrum is about trust and empowerment. If the product owner is not empowered, then the team cannot trust the product owner and so cannot be empowered to own their delivery of the product.
Anti-pattern: Product owner committee
In this anti-pattern two or more people serve as a group product owner with no one actually in charge of the product.
This makes every decision of the product owner a meeting or second-guessed or at least revisited confirmed at a subsequent meeting. No one person is empowered and responsible.
Anti-pattern: Partial product owner
In this anti-pattern, the product owner role is split across several people, which turns out to be a lot like saying no one is product owner and has that effect.
One way to make this mistake is to split responsibilities between a “product manager” who is outward-facing and a “product owner” who is inward-facing and works with the team. (This is immediately broken in that the inward-facing “product owner” is not fully empowered to own the product vision and the outward-facing “product manager” does not work sufficiently with the team.) This results in a “product owner” who is little more than a secretary responsible for the tedium of writing the product backlog entries as proper stories, say.
Instead of splitting the product owner role, organizations should face the challenge of applying the role properly. One person should be in charge of the strategic and tactical product management aspects.
Anti-pattern: Over-worked product owner
In this anti-pattern, an overworked product owner becomes a bottleneck, limits the project’s success, or simply doesn’t fulfill the responsibilities of the product owner role.
The product backlog isn’t well groomed and prioritized, the product owner doesn’t make it to Scrum team meetings, and clarifications are not available quickly. Consequently, the team builds the wrong product less efficiently.
Agile is about sustainable pace. Over-worked-ness is definitionally unsustainable.
Pichler identifies two main causes of over-worked-product-owner anti-pattern.
Not enough time to perform the role
The person in the product owner role may not have enough time to do the job if he or she expects or is expected to fulfill other jobs at the same time or is expected to be product owner across multiple teams.
This may stem from the organization or product owner not getting it that product owner is a full-time role.
When symptoms of over-worked product owner anti-pattern arise, the product owner should (again?) be freed from all other responsibilities.
Start with the assumption that being a product owner is a full-time job, and that one product owner can look after only one product and one team.
Not enough support from the team
The product owner is responsible for and owns the product owner role, but product ownership work should be carried out collaboratively and with team support. The team and the ScrumMaster should support the product owner.
Anti-pattern: distant product owner
In this anti-pattern, the product owner works separately from the team, is seldom present face-to-face, is entirely consumed with meetings, etc.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Co-locate the product owner with the rest of the team and ensure continual face time, at the least an hour a day.
Anti-pattern: proxy product owner
In this anti-pattern, a proxy product owner acts as a placeholder for the actual product owner, which is a lot like saying no one is product owner (the proxy isn’t empowered; the actual isn’t present.)
Don’t do this. It increases conflicts and miscommuncation, slows decision-making, and decreases productivity.
Instead, face down the underlying issues. Either make your real product owner really a product owner, or admit that he or she is not the product owner and find someone available to do the job.
——
This post is part of a series
This post is part of a series of posts about chapters in Roman Pichler’s Agile Product Management with Scrum.
-
Chapter 1 : the product owner role (this post)
Read the book
This is a great book; you should read it.
I hope my summary is helpful, but it does not do justice to the nuance and detail in the book.
Acknowledgements
Cover photo: Andrew Becraft's Steve Jobs via CC-BY-NC-SA-2.0.