The Product Owner (PO) is an extremely important role that includes a diverse set of responsibilities. An empowered PO can have a tremendous impact on product development, if he or she is able to handle the many jobs of a PO.
This raises the question of what skills are needed to do just that. Thus, in this third installment of the series on the PO I will focus on answering the question What are the core competencies of a Product Owner?
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.
The four core competencies
I believe there are four core competencies every PO should try to build in order to be successful.
- Decision making
Let’s start with the one that is used the most but often defined the least.
I remember sitting in various classes in university where the failure modes of projects in business were discussed. One of the reasons was always and without fail communication. I never fully understood what was meant by it besides the obvious that you should communicate with people.🤷♂️(Though, it was really nice knowing on every test about these topics that I always had one default answer when asked about why something might fail)
It took me a few years to figure out why it was mentioned so often. In my view it’s not so much about the definition itself. Communication in the PO context is indeed not much more than talking to people and in one form or another explaining. And explaining. And explaining. And more explaining.
That’s the hard part, actually doing it! Over and over again!
People – including myself – are lazy, shy, naive, busy, and I can think of a million more excuses not to communicate. The reason that communication was always a mode of failure in the university tests – and my experience has shown it to be true – was not because we don’t understand that we need to communicate. It was because for whatever reason we don’t do it (enough).
Let’s make it more concrete and see what about communication is so important for the PO.
Explaining the why
First, the PO needs to not only drive the product vision, strategy and roadmap, he or she also needs to get buy-in from the team and all other stakeholders. This cannot be achieved without explaining it first. All involved and particularly the team need to understand why we are building the product we are building.
This can be an extremely powerful tool. If you are able to explain it in an inspiring and energetic manner it can create a real boost for motivation and team spirit.
Also, stakeholders need to understand why we are not building certain things. As a PO you need to say No, a lot. There are good reasons to do so, but it is still not a lot of fun. However, it is much easier if the stakeholders accept the No. This, they are more likely to do if the PO can communicate the reasoning for the decision.
In this context, the worst thing any PO can do is simply ignore or “forget” a request. I know it’s uncomfortable to deny people what they want but not doing anything leads to frustration everywhere.
One of the core jobs of the PO is understanding users and defining requirements from that understanding. Thus, she or he needs to be able to deconstruct the user’s needs and reconstruct them in such a way that they can be implemented. The way this is done can have a significant impact on team productivity.
The requirements then need to be communicated in such a way that it is crystal clear what needs to be implemented. The team needs to fully understand what needs to be done. In the context of Scrum the translation falls under the headline story writing.
In my experience, one of the most frequent causes for all kinds of issues in product development are misunderstandings between PO and team about requirements. They cause waste, rework and consequently bad quality.
Modes of communication
Requirements and stories are usually written, as are blog posts or emails. Phone calls, meetings, and presentations are spoken communication. Depending on the company culture or personal preference one of written or spoken might be more prevalent than the others, but a PO needs to be able to do both.
What I do want to stress here is that it doesn’t always have to be a meeting or phone call. There are use cases where I feel written communication is preferable. It forces you to really think about what you want to say and it scales better. I know many companies focus on written asynchronous communication but it still feels undervalued and underused compared to spoken communication.
By the way, listening is also a part of communication. This is of particular importance for the PO in the context of refining stories to get the input from the team. Of course, it is also important when trying to understand user needs. Without listening to what the team is telling you, product development will be inefficient. Without listening to users or customers, product development will be ineffective.
Empathy is defined as understanding, being aware of, and being sensitive to others’ feelings, thoughts, and experiences. Well…one of the main jobs of the PO – maybe the most important one – is to understand users. This is a prerequisite for determining what the product should be, what things need to be developed.
Empathy is obviously key to understanding users. Even more so, since humans – and I expect most of your users are humans – are not very good at expressing directly why they do things. Thus, only through empathetic listening and observation can we understand what the user’s needs, pain points and desires actually are.
Moreover, empathy is also needed when dealing with other stakeholders. As mentioned above a PO needs to deny many requests. Nobody enjoys this. Understanding the motivations of the person you are dealing with is key to creating an explanation for the decisions that are accepted. This makes saying No less horrible.
Speaking of stakeholders, a PO is a role that interfaces with many. He or she is the first contact in all things product. Thus, any PO will receive a seemingly never ending stream of questions, requests, and meeting invites. It is imperative for any PO to be organized. In my view we do not talk enough about the need for setting up a self-management system that you can trust.
An organized PO efficiently handles everything that is not directly value contributing. He or she does not waste time trying to remember where things are stored, what needed to be done or what some decisions were. Thus, time is freed up to work on the things that are really important, like talking to users, writing stories, or thinking about the vision.
The PO has the responsibility to make the final decisions on what the product can be. This can be delegated or done jointly but in the end the PO must decide and own the decision. This gives the role a lot of leverage to affect outcomes – positively and negatively. It’s crucial for the PO to want and also to be able to handle this significant responsibility (and the organization has to be willing to give it).
Jeff Bezos is famous – amongst other things – for stating that there are two types of decisions, reversible and irreversible. I fully agree that reversible decisions need to be done quickly whereas irreversible ones need to be deliberated.
The vast majority of the day to day decisions a PO has to make are reversible (e.g. which story to prioritize, whether a (small) change can go to production). Thus, she or he should be comfortable making those quickly without becoming a bottleneck the team is waiting on. However, the PO needs to also be able to identify which decisions are irreversible and be sure to give those the necessary attention.
Truthfully speaking, the vast majority of us will likely encounter very few irreversible decisions. I don’t think I have ever had to make one. Those types of decisions are usually taken at a higher level in the company. Thus, I tend to focus on simply making fast decisions.
Four core competencies are enough
In this edition of The Backlog I focused on four core competencies I feel are absolutely necessary in order to be an effective Product Owner: communication, empathy, organization, and decision making.
There are likely many more skills needed. Very obvious is a grasp of Scrum or other agile methods – which to me is a given for any PO. Domain expertise and technical understanding to me also seem extremely valuable. I will likely write separate posts about those since I still need to fully form my opinion.
My feeling is that both help tremendously (for different reasons) but they are not necessarily needed to be successful (and can hopefully be built over time). Grasp of market trends, knowledge of other developments within the company, understanding the dependencies and interplays between different products and teams are others that come to mind.
However, I am convinced that anyone who excels at the four I focused on will likely be a very good Product Owner.
Photo by Oliver Buchmann on Unsplash