Once you reach a certain age, it’s common at social gatherings to ask your conversation partner about their job. Pretty much everyone has a job, so it’s an easy conversation starter.
For many professions, you have a general idea that helps you exchange questions and opinions. An ophthalmologist takes care of eye health, a roofer puts roofs on houses, a car mechanic repairs cars. And then there’s me: I’m a Product Owner. A job title that almost no one outside of IT knows, and even within IT, many can’t picture what the job entails.
That’s a good reason for me to just describe what a Product Owner, or PO for short, actually does. In doing so, I used my search engine of choice and looked at the definitions on the internet. And just like me, they have trouble describing the role of a Product Owner in just a few words. I’ll try anyway:
As a Product Owner, you are responsible for the development and value enhancement of a part of the company, the product, in collaboration with the business departments and IT.
A more detailed explanation isn’t so easy. As a Product Owner, a company first assigns you one or more products. The product can be a piece of software (like an office suite), a part of a software (the word processor Word), or a business unit. For me, the products are located in the goods receiving area of logistics, and each covers a part of the goods receiving process. The receiving, the goods inspection, the internal transport, and so on. Since no part of a company functions without IT these days, you also need someone to coordinate all the IT topics that arise in these areas.
This coordination mandate is very broad. A Product Owner is positioned quite close to management and is deliberately not assigned to any specific department. This means the department does not have the authority to give instructions to the PO. This is also important for one of their most crucial tasks: to review, evaluate, and prioritize the content of the open development topics, called the backlog. A PO decides if and when a project will be implemented by the developers. Always, of course, with the goal of using the available development resources as profitably as possible. The company goals and agreed-upon product goals serve as a guide and a compass.
All other tasks are more or less derived from this review and prioritization. The development team must always have a sufficient supply of well-defined work packages, the requesters want to be kept up to date on the current status of their topics, and often information or input from other areas needs to be procured. And of course, the Product Owner also actively works on the further development of their products by introducing and fleshing out necessary projects themselves.
As you can see, the job has a lot to do with communication and planning. Here, planning is not to be understood in the sense of fixed schedules. That goes against the agile manifesto in IT, which promotes flexible responses to changing conditions. The biggest challenge as a Product Owner, at least for me, is not only being able to plan and shape through communication and coordination, but also being able to regularly react to new requirements and needs.
I’m still not sure if this text has managed to summarize my work in a reasonably understandable and compact way. The difficulty of the job, in particular, is hard to describe. Nevertheless, I hope you’ve gained a rough insight into the activities of a Product Owner.