Increasingly, I see the difficulty organizations have in finding suitable people to take up a Product Owner (PO) role when adopting agile working practices. Even when the role is filled, the tasks of empowering the individual to a suitable level and giving them the knowledge of how to calculate true business value, are rarely accomplished.
I’ve always struggled with the PO role in agile. Firstly, there’s the question of where they fit – are they in the team or do they work beside the team? If they’re in the team, is there a core delivery group within the team that the PO is definitely not a part of? Do they even want to be part of the team?
Secondly, and perhaps more importantly, what do they do? In some cases, they provide an overall vision or direction for the product. The most common descriptions of the role, from its origin in Scrum, have the following specific accountabilities against the individual (or close variants):
So the PO tells the team what to do, what order to do it in, and then signs off on the results. However, does this sound very command-and-control? In a seemingly agile world that favors servant leadership, we have created a role that supports a dictator, where there is a risk that it is their way or the highway!
Many of us have been ok with this, because it deflects some accountability from the team; that is, everyone but the PO. The PO has the power to accept or reject the team’s work. If they accept it and it turns out to be wrong, bad, or not what we expected, then who is to blame? Most people would point the finger at the PO.
My final issue with the PO role as we know it is that there are unrealistic expectations on the individual. Sure, some people can navigate this path and are successful in the role, but there’s a reason organizations struggle to find great POs most of the time. Not only do they need to be passionate about the product, but also have a solid knowledge of concepts and practices like user value, business value, cost/benefit analysis, business accounting, operating costs, market and competitor analysis, stakeholder management etc. They also need to have the product vision firmly engrained in their minds, and balance that against the above demands.
That’s a tough gig.
I think it’s time for a change. It’s time we accepted that the PO role, as we know it today, is far from ideal, and that we can do better.
My proposal is simple:
Now, it’s the team that is fully accountable for the outcomes they produce in order to meet the goals they’re aiming for, not a single person. When empowered to this level, it is now the team’s call to decide on what to do next. By adopting a true build-measure-learn cycle, they need to get changes out into production and then measure their impact. If it’s positive, then the team has succeeded together. If not, there’s valuable learning to use going forward. Either way, the team owns the outcomes.
The Production Assistant is essentially your PO of today - stripped of their unreasonable accountabilities, but adding value to the team with their deep domain knowledge. They’re a dedicated and full time member of the team, and they’re much needed in this capacity – every team needs this knowledge to tap on. They work closely with the Business Analysts, Experience Designers, and provide a clear link to a Product Manager and the wider product ecosystem. They work closely with the Product Manager to understand the overall visions and goals that the team is working towards, and bring the 'bigger picture' into the team’s view.
So how do decisions get made within the team? Well, agile teams already make important decisions themselves. They decide on coding standards, definitions of 'done' and frameworks to utilize. The decisions that our traditional POs make, and their assumed responsibilities can simply follow this approach of group ownership and make decisions by consensus.
Let’s look at some examples:
Of course, to truly work in such a manner, the team needs to exist within an ecosystem tailored for lean product development, with principles of trust and empowerment, where a product evolves through a build-measure-learn loop.
The PO role of yesterday is not a good fit for agile as it is used today. In the spirit of continuous improvement, we need to evolve the role. It turns out this change isn’t hard to implement. By following the changes outlined above, we can truly empower teams to deliver business value by discovering for themselves what outcomes and results they produce.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.