Phillip Starke
Why you need a strong product owner to build something great

Today I am writing about the role of the Product Owner (PO) and why it is so crucially important. I am doing this since I haven’t really seen it written out anywhere. You can find a lot about what the PO is supposed to do, but rarely do you find the explanation why the role is needed. (Also, I am writing this out of self interest to make sure the value of my current job is recognized😛)
The text is very much an answer to the question “Why is the Product Owner needed?” or “Why is the Product Owner important?”. However, much of what I write below is also valid for project leaders or team leads within product development – even if those teams are not working with Scrum or other agile methods.
If the team or project leader gets a similar mandate as the PO does in Scrum (essentially sole responsibility of what is developed and decision making authority) the benefits will be very similar.
The Backlog is a bi-weekly newsletter about the undervalued and overlooked in modern product development. It covers product development, self organization, and productivity. I include methods, books, and write about my own experience. The target audience are Product Owners, Scrum Masters, Developers, and project leaders. The Backlog is about getting the most out of product development.
Subscribe to get new posts straight to your inbox.
Why is the product owner role needed?
For all of the below, I am assuming the PO is empowered and has decision making power. In my experience, this not being the case is the most frequent cause for problems when working with Scrum. It is an absolute necessity to give the PO the full mandate.
In my view, a properly implemented PO role is needed for two main reasons:
- To enable effective product development
- To ensure efficient work by the development team
Surely, there are many more reasons but these are the ones that stand out to me. I will try to approach the points by explaining some issues within product development and then showing how a role like the PO solves these problems.
A Product Owner enables effective development
Oftentimes within product development, really within any type of project, various stakeholders are involved. Each and every one of those has their own agenda, their own incentives, their own things they want to achieve. Thus, it’s only natural that they all try to influence the product development so that it moves in the direction that they see fit. I am not saying that any of them are doing this in bad faith. They could all think that they are trying to maximize the benefits for the company.
Unfortunately, none of them have the full picture of what is going on. Also, they are all imperfect humans and are therefore (unknowingly) biased, likely in the direction of their own work.
Without any counter to the above, the product will likely be developed in the direction of whomever is pushing the hardest and loudest. This could be because the loudest stakeholder has the best idea. Or it could be that he or she just has – at this moment – the most time and energy to push.
Product development needs a role that can balance all those wishes and requests, that can balance technical, business, and customer requirements. A role is needed ensuring that what is being developed is done so because it fits the overall vision and goals for the product and that it is not guided by the persuasiveness or power of individual stakeholders.
A Product owner means efficient development
The other main reason why a Product Owner is needed is the efficiency of the development team. The role of PO can massively influence in a positive manner three sources of inefficiency: distractions for the dev team, slow decision making, and bad requirements or work package definition.
One of the main ways to have an efficient development team is to just leave them alone and let them do their work. A role is needed to shield the team from constant requests. If this is not available the developers are constantly distracted, they try to multitask, and this doesn´t work. This is true on an individual level but also for the entire team.
Frequently, without this shield, if no one is there to make sure things are finished before the next “important” feature is started, you never really get anything done at all. The team is pulled from one thing to the next, all involved are frustrated and exhausted.
Closely related to the above is the need within development to enable fast decision making. If this doesn’t happen, in case e.g. some committee is needed that meets once every two weeks or if many people have to sign off on a decision, the effects are very similar to distracting the team. While they wait for the decision the team starts something else, it has to switch focus, and then come back to the initial task later on. Due to this constant switching, efficiency significantly suffers.
In my view the main goal in product development is to have the ones that are creating value, the developers, actually creating value and not waiting on any sort of decision. Thus someone (who is accessible – this is very important!) is needed to quickly answer questions that the team may have, to make decisions in regards to requirements that may be unclear.
Related to the last sentence, the final and often underestimated way to significantly impact efficiency of the team is the way requirements, user stories, or work packages are defined. The amount of impact on efficiency in implementation that can be generated by simply changing a few words in the wording of requirements is astounding. If done correctly, if sliced correctly, if refined correctly, it’s smooth sailing. If not, it’s questions, disruptions, and frustration all around. Thus, a role is needed that is focused on making sure requirements or work packages are defined in such a way that the team will be able to quickly complete them and deliver value fast.
The Product owner needs to be empowered
As I wrote in the beginning, I assume for the above that the PO has the full decision making power and mandate to really shape the development. This is how the PO role is defined in theory.
It’s important to note that we are living in the real world and not in theory. Not all people have the same skill set. Understandably, a company might be hesitant to fully hand over the reins for a product, whose commercial success could significantly impact the company’s future, right away. However, this must be the goal. The (leadership of the) company has to want this. Otherwise, it won’t work.
Additionally, if you are a PO you have to demand the mandate to make the decisions as you see fit. This is, of course, related to the trust that might need to be earned. If this is there, you need to make it clear that only a fully empowered PO can ensure that the right things are being developed rapidly, that the product development is effective and efficient.