Your Product Owner Is Not Enough
Organizations these days have adopted agile methodologies rather well. Unlike not so long ago, many organizations these days actually do agile instead of just pretending it. This is great and most organizations have already seen rather large benefits from it. Not everything is rosy though.
The hardest job in agile process is the role of product owner, the role of business decision maker. Product owner needs to be able to manage several things at the same time:
- Strategic needs
- Business requirements
- Take technological limitations into account
- Writing user stories
- Be there for the team and answer their questions without delay
This is big job, a job for a multi-talented person. A good product owner is an extremely valuable person in an organization.
The reality however is that most of the time our product owners are not these unicorns who can do everything. Basically in order to be a good product owner in a software project you would have to have a technical background, with extensive understanding of strategy and very deep knowledge of the business domain at hand. And on top of that you should be able to be a UX expert so you would be able to write good user stories which map correctly to the big picture of user experience.
Let’s face it, there are people who fulfill these criteria but it is highly unlikely that your product owner is one of these. In a typical scenario the product owner is someone who knows the domain well but that’s where their capabilities end. This will end up into a situation where there is practically no product owner and team needs to fill in the blanks all by themselves. This will lead to non-optimal solution.
And it gets worse when you take the larger picture into play and look at the situation over several concurrent projects with each of them having a product owner. Each of these projects have their own agenda and all of them are going towards their own goal.
This course change is a good thing, it’s what iteration in an agile process is all about. However, this is also a problem since it will inevitably lead different projects towards different goals. However, all these projects should be driven by the company strategy and all of them should strive towards that common goal.
So, we have two problems: first, it is nearly impossible to find a good product owner who can handle all the requirements needed for them. Second, even if we find these product owners they will with all likelihood end up driving their projects towards their own goals and this will lead to overlap and possibly something which will not support company strategy.
How to solve this problem? The same way we have been solving this very same problem on the development side since day one: create a team.
First of all, if you split the product owner role across several persons then you’ll find it much easier to fulfill all the required attributes of a good product owner. Need technical understanding in the PO role? Just add a person with technical background as part of the team. Need strategic understanding and alignment? Get a person who is involved in the strategic process to the team.
A team is always more effective than a single person. A well formed team is more than the sum of its parts.
But wait! This will incur huge costs since instead of having a single PO per project, we now have several! You can only do this for very large projects where the cost is justifiable!
The thing with teams is that they can do more work than a single person. A product owner team can handle several projects at the same time. A well oiled product owner team can actually handle more projects efficiently than there are people in the team since they can concentrate on the issues they know well. However, this only works if they are in close collaboration with each other all the time and there cannot be a waiting time. This team needs to be physically close to each other, sitting next to each other. They need to have drawing boards and other tooling readily available. Does this sound familiar to you? Yes, this is exactly the same mantra we’ve been hearing about the requirements of an agile development team. Same rules apply here.
But how about the availability of a PO to the development team? Doesn’t this shared responsibility cause a burden on that since if the PO team is shared across the development teams they cannot possibly sit with the teams?
This problem can be solved with wise office layout planning. It’s not about sitting among the developers, it’s about minimizing the friction they face when they need information or advice from the product owners.
If you are lucky then you might get your PO team so close to dev teams that developers do not even need to get out of their chairs in order to ask their questions. But it’s not a problem if they do have to do that. It starts to get a problem if they need to change a floor or worse a building. As a rule of thumb: if the developer team can see your PO team then they are close enough for the friction not to be there. The main reason for this is that they can easily just look if POs are free or not without first having to leave their desks. If they can’t do this they’ll easily either send an email, a Slack message or just plain do not try to solve the problem they are having.
If you go the product owner team way then please remember what is the purpose of a product owner:
- Ensure business value is produced during development
- Ensure that business value is aligned with the company strategy
- Support the development team(s) every way you can
- Being a product owner or part of such a team is a full-time job
- PO team members are not automatically “chief” something. Their technical guys are not the lead architects, let developers do that job. Their strategy member is not the CEO (most likely at least). Their job is to be the glue between these parties and get the machine running as a whole.
Also you must remember that this is about being a team. Just like with a software development team, rogue members will hurt the overall output, same applies with PO teams.
If you remember this then you and your development teams will thrive.
¹ Image By Pearson Scott Foresman [Public domain], via Wikimedia Commons
