The product owner role is overburdened with too many responsibilities. Therefore a product owner can become a bottle neck and knowledge silo. Both of these traits lead to a cascade of issues.
This second part focusses on the benefits of a more collaborative but unfortunately less common approach to product ownership. It will highlight the principles, advantages and risks of collaborative product ownership.
Democratising ownership
In the first part of this series on collaborative product ownership I painted a clear picture: A product owner has to wear too many hats. They should unite the visionary with the Doer. Be a team player and also a leader. Great communicator and negotiator. Readily available to answer questions and be highly knowledgable in their domain.
As I explained in the first part adding crutches to a concept which is inherently flawed might mask some of the symptoms but it can not fix the root issue. It does not matter if you call them product manager, business analysts or requirements engineers. Giving others a slice of the responsibilities of the product owner will not solve the root cause. This is not what I mean with collaborative product ownership. Each of those roles has a valid reason to exist. But none of them should be the product owner’s assistant or supervisor. Additionally these roles can be too detached from the team to make the right calls. Ultimately they might suffer the exact same issues a sole product owner faces.
But who should take the weight off the product owner’s shoulders? The ones who execute the decisions, the development team. They have accumulated great domain expertise already. Often team members feel strongly about the product they are working on. It is their baby which they are caring for day in and day out.
Rewiring your information flow
However, for this to work both the existing product knowledge and new incoming information has to be made transparent. The product owner has to transform from a decision maker to a knowledge broker and mediator.
Move from a command and control structure to self-organising teams.
None of that means that the role of the product owner should disappear. Instead the product owner should shift their focus to:
- Gathering relevant data about the product, customers and stakeholders and making it accessible for the team
- Cultivating a process in which the team is involved in every step
- Establishing shared ownership and decision making to make your process more resilient
- Fostering direct contact between customers, stakeholders and the development team
Fundamental Benefits
This sounds like a big change in both process and roles. Is this really worth all the effort and risk of failure? Here are a few aspects you might see improving with a more collaborative approach to product ownership.
Better outcomes
Collaborating on the product ownership does not mean less work. But it can mean different work with better outcomes. Giving many brains the necessary information and giving them room to share their thoughts on how to deliver the most value will ultimately lead to better decisions.
Collaborating on product decisions does not mean less work.
It means different work with better outcomes
In part one I have written about the wisdom of the crowd. Here is a quote directly from Roman Pichler‘s book Agile Product Management with Scrum which makes the same point:
No entrepreneurial genius can make all the right decisions. In fact, neuroscientific research reveals that even the best-qualified person in the right job at the right place can make wrong decisions—if that person decides alone. Finkelstein and his coauthors attribute this to the way human cognition works (2009). They recommend using at least one other person as a sounding board. A team provides plenty of sparring partners to test ideas and arrive at the right decision. Ed Catmull, president of Pixar (2008, 68), says this: … if you give a mediocre idea to a great team, they will either fix it or throw it away and come up with something that works. The wisdom of many is preferable to the brilliance of one.
Transparency and customer collaboration
A very important aspect of collaborative product ownership is the free flow of information. By distributing information and communicating decisions explicitly you create an important record of the evolution of your product.
Ideally information flows freely to the development team and the team shares information readily with their customers and stakeholders. No more alignment meetings, jour fixes or status reports. Instead you integrate your customers and stakeholders in your existing process. That means during the ideation phase, story preparation and delivery.
While a strictly hierarchical flow of information might look more streamlined too much information gets lost during transmission. Stop thinking like a factory designer. Put the humans inhibiting your process first. Direct face to face communication can solve a magnitude of issues before they even arise. Create more of those opportunities where your team can learn about their customers and the other way around.
Resilient teams
You might think that more communication channels and redundant information is waste to be erased. Centralised decision making does just that. Theoretically. If you look at it from the perspective of risk mitigation though having one person holding all the information and making all the decisions becomes a living nightmare. You reduce your team’s bus factor to 1. You definitely don’t want your product’s or organisation’s success to be so fragile!
By empowering a whole group of people to gather insights, share knowledge and make decisions you make your product development process more resilient. A disruption to that process is always around the corner.
Growing team members, growing product
If everyone keeps doing what they are doing your product will not evolve much further. Once your product stagnates your business will be gone soon.
By letting the team take part in the product ownership many challenges will pull them out of their comfort zone. They will have to learn new skills and apply them, make mistakes and learn from them. Team members can practice their communication and presentation skills, learn about the business side and see how product, business and technical decisions all influence each other.
This will ultimately lead to a product which stands a fighting chance in your market.
Erases them vs. us thinking
When all the power and all the responsibility lies in the hands of a single person everyone else feels frustrated because they are not heard or taken seriously. If everything goes smoothly nobody notices the apocalypses that were avoided. If things go wrong everyone would’ve known better.
This them vs. us thinking is all too common in disempowered teams. There is almost a sense of Schadenfreude when things go south. This hazardous environment is toxic to your business success in many ways. People do not try to give their best because their contributions are recognised. Nobody points out arising issues because they think they are not heard or rewarded. Decisions are not challenged because that’s “none of your business”.
By including people in their decision making and giving them the knowledge to do their best job you can turn “them vs. us” into we thinking. Instead of having a tug-of-war you can turn it into a game where everyone plays on the same team. People will soon realise that decisions are not always easy and obvious. They will be confronted with situations of conflicting interests where finding a win-win solution is not possible and striking a compromise is necessary.
Buy-in and motivation
By giving the team agency over their work and the product’s destiny you create a motivating environment where you can connect your effort to outcome more directly. By not treating people as mindless drones which you feed Jira tickets and they produce code you create more meaningful work for them. Meaningful work is more intrinsically motivating. You don’t have to monitor and control the team but instead focus on inspecting what matters: The business value delivered by your team and the reception of your product.
Common pitfalls
To put things into perspective I want to mention a few potential downsides and risks you should be aware of. All the before mentioned benefits are theoretical. Making them come to life takes effort and time.
- You can overwhelm your team with the abundance of new tasks and new challenges. Change has to happen at the right pace.
- Some people might not be interested in such change at all. Some are too comfortable in their current position, have no drive to learn new things or are too afraid to fail. Such attitudes have to be respected as well.
- Recklessly abandoning existing processes. Choosing collaboration tears down walls between different roles and departments to some extend. But if you don’t define the new way of collaborating it can turn into plain chaos rapidly.
Implementing collaborative product ownership
Not every team in every stage has the capabilities to share the ownership of their product. No team is alike and there are no procedures which work in all case. If you want to introduce a new collaborative way of product ownership to your team you should therefore work iteratively and adjust the process to the team’s and product’s real needs.
How a transformation to this desired state can look like its outlined in the final part of this series on collaborative product ownership.