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):
- Elaborate stories and define acceptance criteria
- Prioritize the backlog
- Accept stories as ‘done’
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:
- Change the Product Owner to a Production Assistant role
- Dissolve the ‘single voice of truth’ accountabilities into the agile team
- Extend the team’s accountability boundaries so that team becomes the owner of development, operations and now, outcomes too
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:
- Backlog Management - The team, including the Production Assistant, own their backlog. These group of individuals need to meet regularly to decide the order of work, take into account each other’s views and inputs, and agree on story acceptance criteria
- Story Acceptance and Sign Off - Signing off that a story meets acceptance criteria is just a quick check that the team can and should perform as part of their workflow. What is most important to know is whether or not the changes made have had the desired impact and delivered the desired value, bringing us to the next point -
- Business Value Realization (i.e. outcomes) - Business value is best interpreted as a set of hypotheses, which are created in order to achieve a goal. The team, therefore, needs to measure the outcome of changes to assess and conclude on the results. Clearly and wholeheartedly moving this accountability to the team enables this end-to-end ownership. The team may need access to certain management information tools, or may need to create their own, but they must own the accountability. The assessment might take an instant, a day, or even longer, but it is in their own interests to find this out so that they can show if a hypothesis is true or not, thereby delivering against a goal, or adjusting course as required.
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.
