Do Product Owners Need Technical Skills?
Do Product Owners Need Technical Skills?
While it helps, it's not 100% necessary. What's more important is the understanding of how what your team is doing fits in with the company's big picture.
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
How can you tell if you would benefit from having technical skills as a product owner? To answer this question, I find it helpful to look at how the role is applied. If you manage a digital product that end users employ, such as a web or mobile app, then you usually do not require in-depth technical skills, such as, being able to program in Java, write SQL code, or know which machine learning frameworks there are and if, say, TensorFlow is the right choice for your product.
But if you look after a technical product—a product that is integrated into a larger offering like a physics engine, which forms part of a computer game—then you will require the appropriate technical skills in order to formulate technical requirements and define software interfaces (APIs). For instance, if you were responsible for a physics engine, then you would probably have to be able to program in C++, use UML, and apply the right software architecture and design patterns.
The same applies if you are a component owner, someone who looks after an architecture building block like a service, component, or layer that forms part of a digital product: you will benefit from having hands-on experience in the appropriate technologies.
Independent of your specific product job, you should take an interest in software technology and be aware of major trends like artificial intelligence (AI) and Internet of Things (IoT). I would argue that every product owner should have at least a basic understanding of core concepts, such as object orientation, design patterns, and architecture principles, as well as Agile development practices, such as test-first, refactoring, and continuous integration.
This knowledge helps you make the right product decisions, for example, investigating how AI and machine learning can improve your product or allocate time for architecture refactoring work. It also helps you empathize with the development team and understand some of the challenges the team members experience whilst designing, programming and testing the product.
Learning to program can help you acquire the relevant knowledge—I am certainly grateful that I had the opportunity to learn to write code and architect software systems. But do make sure that you focus on your actual job—to ensure that your product creates as much value as possible for the users and your company. It’s more important that you understand the value your product creates for its users, who the product serves, what makes it stand out, and what business benefits it should deliver than being able to know if a layered or service-based architecture is more appropriate, for example.
Additionally, don’t interfere with the development team’s autonomy by making technical decisions, which can be tempting for product owners with strong technical skills in my experience. It’s the team’s job to decide how the product is built, not yours. If you feel that people lack the necessary skills to make the right technical decisions, then discuss this observation with the team in the next Sprint retrospective and agree on the right improvement measures, rather than you taking over and telling people what to do.
Finally, recognize that playing the product owner role and working in product management is as exciting as it is demanding. Don’t feel bad if you lack technical understanding. See it as an opportunity to learn and grow, and expand your product management practice.
Published at DZone with permission of Roman Pichler , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.