When I’m asked what I do for a living, I say “product management,” then explain that I work with developers, designers, testers, users, operations, and sales to deliver a product. The next question is usually, “So, you work as IT is it?” Sometimes I say yes to keep the conversation simple. But that answer leaves out much of the work.
Scrum accountability and the broader product bridge
In Scrum, the Product Owner is accountable for maximising product value and effective Product Backlog management. The Product Goal and backlog order make the direction and priorities clear. Some work can be delegated; that accountability stays with the Product Owner.
The broader product-management job varies by organisation. My view of ownership connects direction, positioning, launch, maintenance, and stakeholder alignment. Agree those responsibilities explicitly; Scrum does not automatically assign all of them to one person.
Ownership does not mean controlling every specialist. Developers plan how to deliver the work; designers, testers, operations, and commercial colleagues contribute their expertise. A useful owner connects their evidence and decisions around a product outcome.
A hypothetical conflict: a sales feature or reliable service?
Sales wants a demo feature for an opportunity, operations needs fewer service failures, and engineering identifies an integration dependency that affects both. The Product Owner asks what value and risk each request carries, while the team explains the dependency, likely effort, and feasible options.
If the evidence shows that reliability blocks customers’ core task, the Product Owner can prioritise resolving that risk and enabling the integration before the demo feature. Explain the trade-off to sales and consider a smaller demonstration that avoids an unsupported promise. The team collaborates on delivery; the Product Owner does not dictate every specialist’s task.
A different evidence picture could justify a different order. Caring about the whole product means making that reasoning visible and revisiting priorities when the facts change.
Product Owner, project manager, and business analyst
The boundaries can overlap, especially in smaller teams. These are useful distinctions rather than universal job descriptions:
- Product Owner: which product outcome matters, and what should be prioritised to create value?
- Project manager: how can a defined initiative be coordinated across time, resources, dependencies, and risks?
- Business analyst: what needs, processes, rules, and requirements must be understood to solve the problem?
One person may wear more than one hat. The important thing is to clarify decision rights and expectations. Who sets priorities? Who coordinates commitments? Who analyses the requirements? Clear answers make collaboration easier.
Product ownership goes beyond software
Most of my work involves software applications, but product thinking can apply to physical products and services too. The same questions remain useful: who is this for, what value does it provide, and how should it improve? The delivery methods and constraints will differ.
Keep learning and explain the work through its value
A Product Owner needs to keep learning about customers, the business, technology, and the people doing the work. Creativity helps explore options; evidence and judgement help choose between them.
My simpler answer to “What do you do?” is: “I help the team decide what product to build, why it matters, and how to keep improving it.” That describes the purpose of the work more clearly than its connection to IT.