Photo courtesy of Pexels

Do Product Owners Need Technical Skills?

Published on 9th August 2017

As a product owner, you look after a digital product and work with a development team. Does this mean that you require technical skills? Should you be able to program and write code? Or is it sufficient that you take an interest in software technology and leave the rest to the team? This post shares my answers and recommendations.

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 framework 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, investigate how AI and machine learning can improve your product or allocate time for architecture refactoring work. It also helps you empathise 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, recognise 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.

Post a Comment or Ask a Question


  • Benjamin Sherman says:

    Hi Roman,

    Great inspiring article! Can you give me some advice, please? For the past 3 years, I’ve been working as a Project Manager in my own small construction company. I don’t have any formal PM qualifications (although I am degree educated), but I’ve gained a vast amount of experience in designing and delivering construction projects to domestic customers, running multidisciplinary teams of contractors, and delivering projects from inception to completion.

    I would like to get into an Agile Product Owner position. Although I have little knowledge of the technical side of programming – or the software development life cycle – I do have experience of understanding customers needs, running projects and teams and a good understanding of business in general.

    With a background in such a different domain, do you think I could realistically take on the PO role? Would I likely be considered by an employer? Is there anything I can do to improve my position, such as taking Agile accreditation?

    Thanks for your time and help.


    • Roman Pichler Roman Pichler says:

      Hi Benjamin,

      Thank you for sharing your feedback and question. I wouldn’t regard a lack of technical knowledge as a showstopper for playing the product owner role unless you want to manage a technical product like a platform that is integrated with other assets to create a larger, end-user facing product.

      But you may want to assess your current product management knowledge, identify strengths and weaknesses, and determine the most helpful learning and development measures, based on the job you want to move into, if you haven’t done so. One way to do this is to take my product management test. You may aslo want to read my article “The T-Shaped Product Manager“, which discusses the skills product people should have.

      Hope this helps!

  • MK says:

    Can an Application Support Engineer apply for the position of the Product Owner? I believe they have technical skills and even the ability to understand and analyse and reproduce a particular issue.

    • Thank you for sharing your question. There is no reason why application support engineers can’t become product owners. But please note that the job of porduct owner is very different from an engineering role: Product owners manage their products and are responsible for achieving product success; engineers build the product. I would not expect that a product owner is able to find or reproduce issues and bugs. That’s the job of the development team. You may find my article Product Leadership in Scrum helpful, as it explains the focus of the three Scrum roles, product owner, development team, and Scrum Master. Hope this helps!

  • Eugene T says:

    I do see how it’s a learning opportunity, but more and more jobs I see of Product Owners requires at least some technical background.

    For those people who have no experience and no technical degree, what do you recommend these people do? This is like the chicken or the egg problem.

    • Thanks for sharing your observation and question Eugene. You will have to decide what works best for you based on the technical skills you want to require, your learning preferences, and your time and budget constraints. I would recommend, though, that you address three aspects: The relevant theory like object-oriented programming, practical programming skills, such as learning to write Java or C# code ideally using test-driven development, and software design and architecture patterns. Hope this helps!

  • Faizal says:

    why should a technical product like a physics engine need a product owner/product manger ?
    Cant the software development team handle the requirements ?
    Do we even need to call an engine as a product ? It is a technical requirement of an application. Isn’t It ?

  • Rahul V Thombre says:

    Some specific instances happen when a senior technical Architect is asked to become a product owner (which is usually not in his area of interest) or a person from the domain is put into these shoes who is no-where close to any technical teams nor has he been into any project-team management roles earlier.
    The Architect, who originally did not have interest in such a role, gets too involved with technical discussions, implementation related decision making, rectifying developers designs etc and looses sight of the valued-deliverable. The domain person is never able to connect with the development team.
    What should be the correct way of identifying a Product Owner for the product ? Should she/he be one among the development teams who has proved to be a good manager over the years and who can catch-up with the domain and the market needs “OR” should he be a domain side pwerson who gets some exposure of the technology that the development teams are dealing with ?

    • Thanks for sharing your observation and question Rahul. Unfortunately, there is no one right answer–it very much depends on the product. If it’s a technical product like a physics engine, then depth technical knowledge will be more important compared to a consumer-facing product like a web app. Please take a look at my post “The Agile Product Owner Responsibilities” to determine who the product owner should be for a given product. Hope this helps!

  • Jade Bennett says:

    Great insights Roman, thanks for sharing. As a recruiter specialising in the product space, this is a question I get asked a lot and a topic I regularly explore with hiring managers, so this will really help shape conversations moving forward. Thanks again!

  • Wim Veldhuis says:

    Full agree. Let product owner focus on consumer value and make sure that the team has a good architect onboard who can be the bridge towards the tech teams.

    I love to read your blog posts by the way!

    • Thanks for your comment and feedback Wim! I would suggest though that the development team should jointly make software architecture decisions, as this increases buy-in and understanding.

Leave a Reply

Your email address will not be published. Required fields are marked *