Product Owner — A Stepping Stone
Congratulations on getting the basics of Scrum down, but I’ve got some bad news. Scrum is a developmental milestone on a longer journey. It’s the training wheels on the Agile bike (stabilisers to my U.K. friends). You may need them to get going, but eventually they limit your speed and handling.
The Product Owner role was important at the start. You probably needed to elevate the “voice of the customer” in decision-making. An in-house customer proxy was a great start. Product Ownership was also useful to articulate a leadership role that wasn’t a people manager.
However, now that you’ve been doing it for a while, you’ve probably noticed that it’s
a) impossible and
b) introduces a single point of failure
When I say it’s impossible, this isn’t to downplay the achievements of many amazing Product Owners. You folks rock. Somehow you keep on top of all customer research, own the vision, advocate within the organization, run meetings, lead improvements, keep stakeholders warm. (Here’s a really good list of responsibilities from Hannah Kane)
If someone is doing all this really well, though, there might be a couple of worrying signs. What happens when she goes on vacation? Quits? When there’s stuff nobody else on the team wants to do, does she normally pick it up? The team may love her, even while she’s at risk of a nervous breakdown.
In classic Scrum, the flow of information is funnelled to a dev team through one person. She’s meant to give clarity so they can operate effectively. It is literally part of the intent of the role to create a bottleneck. This ensures coherent priorities are fed through to a team at a sane rate.
If your org has a problem with competing business priorities pulling dev all over the place, then the PO role can help fix that. If that is not your biggest problem, and if you’re seeing signs of drifting or strain, it’s worth revisiting.
The answer for many companies is now to shift Product Owner responsibilities into development teams. There’s a big movement right now, to end project teams and create long-running “product” teams instead — yes, even when the system isn’t technically a product. In Sriram Narayan’s comprehensive post Products over Projects, he writes that in this new mode,
Teams are funded to work on a particular business problem or offering over a period of time; with the nature work being defined by a business problem to address rather than a set of functions to deliver.
With Project Teams and Product Owners, the model is very well designed to keep software developers in a tech box and out of bigger product-level questions. It keeps them as interchangeable guns-for-hire, and it ensures that their big brains are contained in code, not solving user problems. It ensures they can’t feel ownership of their service, and it caps their personal development.
The old project model is rooted in assumptions about coders like, “they’re not good with people.” Now that the myth of the socially inept developer is officially dead, we should at least ask about bigger challenges. Overall, while some still consider this “inefficient” on developer time, I’d argue the result is a stronger organization.
If team, rather than a single person, can take on more responsibility, it makes the system more resilient. Except for those rare cases where whole teams are hired away, a team generally maintains more continuity than a sequence of individuals ever could. They become a reservoir of user knowledge, and technical choices get made with the context of a long group memory. It adds a stability, depth, and frankly loyalty that project teams rarely develop.
Don’t get me wrong. Product Owner is a great transitional step. I haven’t personally seen any org make it to product teams without it. Unfortunately, like many things in modern software development, continuous improvement doesn’t stop just because the situation is no longer a train wreck.
If you’re seeing any of the following, you should consider empowering your product teams further:
- Product Owner experiences stress
- Important things are blocked on Product Owner time or attention
- Product Owner is forced to give poorly-thought-out guidance
- Team overpolishes features before releasing
- Detailed technical planning happens for a horizon longer than the product horizon.
- Shipping is seen as the team’s goal, not a means to an outcome
- Team actively avoids topics because they belong to “the business”
- Team is unclear on the intent of their work
- Work magically appears, so teams have poor understanding of intent or tradeoffs
- Teams have intent to iterate with no actual iteration
- Features, not outcomes, are the currency between business and dev team
These are some signals that the team would benefit from taking a wider, more business-oriented view.
Similarly, even without problems, if you’re seeing some good signs, the team may be ready and waiting to take more on:
- Team members spontaneously check metrics
- Team’s dashboard contains business-level outcomes (voluntarily)
- Team celebrates milestones about their impact, like usage or retention, not just the work
- Team is loyal to goals of product, rather than to codebase
- Team challenges itself on size of stories, good acceptance criteria, etc.
- Team has hunger for user contact
- Team asks questions, wants a say, or otherwise “oversteps”
- Team asks a lot of “why” (and doesn’t always believe the answers!)
- Team members are explicitly looking for development opportunities
- Team proposes new work based on user feedback or usage data
- Team checks that proposed work is aligned with their purpose and objectives
This doesn’t have to be all team members, even a couple and that’s a promising situation.
It’s not trivial to develop an empowered product team. I’ve spoken elsewhere about this, and to be honest, it takes some mad coaching skills to grow such a team or an outstanding outward-focused team to bootstrap it.
Comment or tweet me (@ElizAyer) if you want to hear more about that.
Thanks to @cj_smithy for some of the ideas — especially around signs and signals — in this post.
