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
Could you please help me out/give me some advice? I just started a new role as a Product Owner but I do not work in Scrum, my team lead is always checked out and we do not have regular weekly meetings at all. In fact my team lead is not at all involved in the kind of work I am doing. Which means that I have to interact with the stakeholders without really having much training/someone to ask questions to regularly. The only process that I am really part of and that falls into my role is managing the backlog. However, when it comes to user stories or making business decisions, I am not involved at all. Furthermore, I am expected to do a lot of setting up work – for example, setting up fonts or colors for our website, which is primarily based on a CMS. Here is how the process normally goes: Stakeholders tell me to ‘set up’ a page for them on the CMS, which I manually have to do, sometimes without clear guidelines, and then if the work is too hard for me, I get to ask a developer and coordinate with the developer for the set up to happen.
Is this a normal way of working as a PO? I find it very confusing and vague, and without a team lead or training I am often unsure about what to focus on. The CMS I am working with is something I should learn in and out, but my motivation is low because I am also expected to do some of the actual technical work in the CMS.
Since this is my first role as a product owner, the information I find online confuses me even more (but also sounds more interesting) because it is not the actual work that I am doing.
Could you please give me your take/view on my situation?
Thanks for sharing your question P.Shah, and no, that’s not the way the product owner role should be applied. As a Scrum product owner you should manage the product, set product goals, and prioritise the product backlog. But you should not have to do what the stakeholders tell you, as I explain in more detail in the following articles:
Six Types of “Product” Owners
5 Tips for Saying No to Stakeholders
Stakeholder Management Tips for Product People
Hope this helps!
I have more than 9 years of work experience working as a Business Analyst and Product Owner. This is my first time that I have been involved in a sort of technical project, that is about OpenAPI project. All the keywords such as references, end-points, methods etc are pretty alien to me.
I am pretty confused as to how do i start the project and how should i decide about the release planning? How will the user stories be documented? And how will Swagger play an important role in it.
Can you please guide me a useful resource or a book that talks about OpenAPI project? How can a person like who has always worked on functional projects, be able to deliver the best on this project.
Thank you for sharing your question. I am not an OpenAPI specialist and hence struggle to recommend a specific book. But as I mention in the article, you should have the technical skills required whenever you look after a technical product. I therefore recommend that you either decline to take on the product or acquire the necessary skills before you start managing it. The latter may require that you learn to program and create web services.
When it comes to describing technical products, I prefer to work with a modeling language like UML. User stories are great at capturing how an end user interacts with a product. But they are not well suited to describe interfaces / APIs. Please see my article “Why User Stories Fail” for more information.
Hope this helps!
Hello Roman –
Thank you for your quick response to address my query.
I went through your response/article and wanted to let you know that I have been working in one IT life science project for last 2 years for one pharmaceutical MNC client to enhance their IT system functionality where they capture all expenses. I am responsible here to work as project manager/Scrum master. Though I don’t have as such any product management experience; However, in this project I also got an opportunity to work as Junior product owner to shadow the product owner from client side where I was requested to understand system requirements either with product owner or directly by end business users, maintain the product back log, writing EPIC, user stories over JIRA tool with a direction from product owner. So I feel that I am developing my tactical skills in this project as of now and can showcase this work experience as Junior product owner with addition to certification. Once I switch my career as Junior product owner, I am sure I would be getting other opportunities to develop my rest of the skills to prove myself as best product owner.
Any thoughts from your end would be much appreciated.
Sounds like you have a plan. Good luck with your career in product management!
Hi Roman –
Great Article and thank you for sharing with us. Just need your point of view on my one query.
I have around more than 17+ years of IT experience that includes project management, Software Design/Development across large number data ware housing IT projects with use of ETL and database management skills. I am also Certified Scrum master and have been performing scrum master role in my current project for last 2 years. However looking at my experience level and as per latest IT market trends, I wanted to switch my carrier to adapt product owner role. Though I worked in various domains like Banking, Life Science but I don’t have any working experience as product owner. So If I do Complete Certified Scrum Product Owner certification, Would it help me to get entry to work as product owner without any prior experience? your answer may give more insights to me to take next step.
Thanks for your feedback. I am glad that you found the article helpful. Unfortunately, I can’t tell you if becoming a Certified Scrum Product Owner (CSPO) will help you secure a product owner position without prior experience. This will depend on the specific job you are going for. But I’d like to recommend the following: Assess your current product management knowledge, for example, by talking my product management test. Then compare your knowledge and skills to the requirements stated in the job ads you are interested in and determine the right measures to close any gaps. This might involve taking a CSPO class. Additionally, you might want to look for product owner jobs in the data warehouse space, as you have lots of relevant knowledge in this area. It tends to be challenging to move into product management and simultaneously work with new products or in a new industry. Finally, you might find my article “The T-Shaped Product Manager” a helpful read. Good luck!
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.
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!
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!
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!
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 ?
Hi Faizal, I recommend you take a look at my post What is a Digital Product?, which explains how I define what a product is. Hope this helps.
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!
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!
Thanks for your feedback Jade! I am glad that the post was helpful.
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.