Does a Product owner need technical skills?

I recently wrote about the core competencies of a Product Owner (PO). Within that text I didn´t address technical skills. This topic is large enough to warrant a dedicated post. Well, here it is. Does a Product Owner (PO) need deep technical understanding to be successful? 

In my view, the short answer is a clear NO for the vast majority of products. The long answer is a bit more nuanced: it depends. Overall, I do believe that technical understanding for a PO is a net positive. However, it can also lead to some negative outcomes.

I will dive into the pros and cons first before addressing some general points.

Email address:

Leave this field empty if you're human:

Why it helps to have technical background

I believe there is one major benefit of having technical skills as a Product Owner, efficiency:

• Efficiency in evaluating requests
• Efficiency in creating stories
• Efficiency in communicating with the developers.

Efficiency in evaluating requests

First, technical expertise gives the PO an understanding of what type of product improvements are (easily) possible and what is not. It also means the PO is able to – at the very least roughly – estimate the needed effort. This is a major time saver. 

For the vast majority of requests, the PO can quickly evaluate it and give feedback (most of the time to say NO). This saves time as it alleviates the need to always ask the developers. It means efficient communication between PO and stakeholders. It also means less distraction for the developers.

This efficient handling of requests is generally positive but can also have negative side effects. More on that in a second.

Efficiency in creating stories

Similarly as with communication, technical skills the  PO can improve the process of creating and refining stories. In principle, this is a collaborative process between team, PO, stakeholders, and users. Nevertheless, in practice it seems to be the PO that mostly prepares a first version of the stories. 

Technical understanding can lead to stories that in a first version already include much of what is needed. Thus, less discussions and modifications are needed. The following process runs that much more smoothly.

Efficiency in communicating with the developers

Finally, some basic level of technical understanding can mean easier communication with the developers. The developers will not have to explain simple technical concepts to the PO and they can focus the discussion on what is important. This communication (almost) on one level will have many positive effects, including but not limited to building trust between developers and PO.

The downsides of technical skills

There are several downsides to a PO having (too deep) technical understanding. Many of the following points are rooted in the positives mentioned above. Three stand out to me:

• Focusing on the HOW
• Misjudgment in evaluation
• Devaluation of core PO tasks

Focusing on the HOW

First and most importantly, a PO with technical expertise runs the risk of focusing too much on the HOW of the product improvement. This is particularly true for POs who were developers in the past.

Even if it’s hard, the PO needs to decide WHAT is to be built and leave the HOW up to the team. This is not easy! It requires a conscious and deliberate effort to be aware of this and also to resist the urge to tell the team how to solve the problem at hand. This is particularly true in case the PO has significantly more coding experience than the developers in the team.

Misjudgments in evaluation

Above, I wrote that a benefit of technical skills in a PO is efficiency in communication because the PO can qualify requests without needing input from the developers. This carries inherent risk because humans overvalue what they know. 

We tend to be overconfident in our understanding. This can mean that requests are confidently denied because of the PO’s (mis)judgment. Developers might have better solutions that can mean significantly less effort. But they are never involved in the discussion.

That’s why I enjoy the concept of the product trio so much when talking about product discovery. You ensure that a developer is there as well.

Devaluation of core Product Owner tasks

Last but not least, a PO with a programming background specifically can lead to misplaced focus. Some of the most important responsibilities of a PO can be devalued.

We generally try to remain in our comfort zone. In some cases, this can mean that a PO with a programming background can go back to writing code because this is known and easier than talking to users, communicating with stakeholders, or coming up with a product vision.

The consequences of this are twofold. One, it can be a vote of no-confidence in the developers’ capabilities. In the very worst case, the team loses motivation. It senses that the PO doesn’t trust it with coming up with solutions. Two, the important PO tasks like discovery and product vision are not in the focus as they should be.

I have noticed that in myself. Now, I do not have a programming background but I am an engineer. Thus, I tend to focus on technical problems and how to solve them more than I should. As such, I am at times more like an engineering manager or project leader instead of a PO. It takes deliberate effort for me to constantly remind myself what I should be doing.

Overall, I believe the positives of a PO with technical expertise far outweigh the negatives. Nevertheless, any PO with a technical background, in my view, ought to be aware of the risks and act deliberately.

It depends on the product and business

In addition to the general pros and cons of having a Product Owner with technical expertise I want to add more nuance. The need for having technical understanding as PO depends on the product and the type of customers the product is serving. 

In case of an end user facing product, say an E-Commerce website, the PO can very likely be effective without any or with a limited amount of technical skills. In case of a B2B solution that is integrated tightly in technical processes, e.g. some financial service that provides a solution for banks, it is far more likely that the PO needs to have a deep understanding of the technical background and the dependencies.

The reason for this is related to one of the many jobs of the PO, one of the main reasons for having this role, understanding the users of the product. This understanding is key to ensuring effectiveness of the product.

Taking the examples from above, customers and users of the former can likely be understood without having deep technical knowledge. After all, most of us have ordered something online before.

In the latter example the PO will need technical knowledge and ideally a deep understanding of the technical backbone in which the product is integrated. Without it, he or she will likely find it difficult to truly understand the pain points and problems that the customers and users face.

Even in that case, while technical expertise will certainly help, without it the PO can still be effective and help create a successful product. It just won’t come as easy. He or she will need to rely more on others to help. Sales, developers, product managers or industry experts come to mind. However, this may not come naturally and the PO must be aware of his or her ignorance and actively seek out the support.

Knowing dependencies and consequences 

In my experience and somehow related to technical expertise, what I have noticed to be a very important skill for POs is to have a deep understanding of dependencies and of the consequences certain developments will have. This seems to be where a PO with technical expertise can really add value.

Understanding the impact of developments on other teams is so important. There is nothing worse than building something only to then realize that this had an impact on some other team who now needs to frantically fix stuff. 

This can be avoided by proper team set up that minimizes (technical) dependencies. In my experience, this is rarely the case. Thus, having a PO who understands the impacts and knows who to inform can truly add value to the development process.

Be aware of the bigger picture

This might be my conclusion of the Product Owner role as it relates to technical expertise. The PO should be aware of the bigger picture. He or she should be aware of tech trends in the industry, of the high-level architecture within the company, and of the concepts and tools used within the team. The details can and probably should be left to the experts.

Overall, I believe technical skills in a Product Owner are in the vast majority of cases positive but not a must have. In case of having technical skills, it’s important that the PO is aware of the negative effects it can have.

Also, in case you are missing technical expertise, remember that there are three words that can have a magical effect: I don´t know.

Coverphoto by Branko Stancevic on Unsplash