The difference between a product manager and a product owner is that one is a job and the other is a seat in a team. A product manager is employed to make a product succeed: to decide who it is for, what it should do and how it earns its keep. A product owner is defined by Scrum, the best-known agile framework, as the one person who decides what a development team works on and in what order. The same person can do both, and in a small company usually does. Confusion starts when an organisation uses the two titles without saying who holds which decisions.
What a product owner is
The term comes from Scrum, and the current Scrum Guide (the 2020 edition) is the place to check what it means. The guide describes three accountabilities in a Scrum Team: the Product Owner, the Scrum Master and the Developers. It calls them accountabilities, not roles or job titles.
According to the guide, the Product Owner is accountable for maximising the value of the product that results from the team’s work, and for managing the Product Backlog, which is the ordered list of everything that might be done to the product. That covers:
- developing and communicating the Product Goal, the longer-term objective the team is working towards;
- creating Product Backlog items and explaining them clearly;
- putting those items in order;
- making sure the backlog is visible and understood.
Three further points in the guide matter in practice. The Product Owner is one person, not a committee. They may delegate the work of managing the backlog but remain accountable for it. And for the Product Owner to succeed, the guide says, the whole organisation must respect their decisions.
Two things often attributed to the product owner are not in the Scrum Guide at all. It does not mention user stories, which are a popular way of writing backlog items but an optional one. And it does not mention product managers.
What a product manager is
Product manager is a job title with no single official definition. In companies that sell software, the product manager is generally responsible for the product’s success in its market. The work usually includes:
- finding out what customers need, through research and conversation and not only through feature requests;
- deciding which customers and problems the product will serve, and which it will not;
- setting direction for the coming quarters and explaining it to the rest of the business;
- working with sales, marketing, support and finance on pricing, launches and feedback;
- judging whether what was released had the intended effect.
A product manager may or may not sit with a development team. In a company with several teams working on one product, a product manager may set direction for all of them.
The difference side by side
| Product owner | Product manager | |
|---|---|---|
| What it is | An accountability defined in the Scrum Guide | A job title, defined by each employer |
| Main question | What should this team do next? | What should this product become, and for whom? |
| Looks mostly at | The backlog and the team’s next few Sprints | The market, the customers and the months ahead |
| Works most with | Developers, the Scrum Master and stakeholders | Customers, sales, marketing, finance and leadership |
| Judged by | The value of what the team delivers | The product’s results in the market |
| Exists where | Any team using Scrum | Mostly companies that sell a product |
A project manager is different again: responsible for delivering a defined piece of work on time and within budget, whatever the product is.
Where the two overlap, and where it goes wrong
Read the Scrum Guide closely and the Product Owner already has a strategic job. “Maximising the value of the product” and setting the Product Goal cannot be done by someone who only writes tickets. On that reading, product ownership is product management carried out from inside a Scrum Team.
The split into two people comes mainly from large organisations. The Scaled Agile Framework (SAFe), used by some big enterprises, defines both: Product Management looks outward at the market and strategy, and each team’s Product Owner turns that into the team’s backlog. With many teams on one product, dividing the work that way can be sensible.
Copied into a smaller organisation, it tends to produce one of three problems:
- A product owner without authority. The person with the title writes up decisions made by someone more senior, and the team learns to wait for the senior person. The guide’s requirement that the organisation respect the Product Owner’s decisions has been dropped.
- A committee. Several managers share the decisions and the order of the backlog changes with whoever spoke last.
- A gap. The product manager assumes the product owner is talking to users, and the product owner assumes the reverse.
The cure in each case is to write down who decides what, and to make sure one person has the final say on the order of the work.
If you are commissioning a business system
Most of our readers are not selling software. They are having a system built or improved for their own staff or customers. There is no product manager in that situation, and often no Scrum either. The product owner’s decisions still have to be made by somebody, and that somebody has to be on the client’s side:
- which piece of work matters most;
- what a screen or a rule should do when the specification is silent;
- whether a finished piece of work is acceptable.
A supplier can provide an analyst to prepare the backlog and ask the right questions, and good suppliers do. They cannot decide your priorities for you. Expect the person you nominate to need a few hours every week, and the authority to answer without calling a meeting.
On a fixed-price project much of this is settled earlier. The scope and the acceptance checks are agreed before the price is set, as we describe in the importance of acceptance criteria, so the client’s decision-maker spends less time ordering a backlog and more time confirming that each part meets its checks and deciding what to do about new requests. Our approach to bespoke software and our fixed-price packages both work this way.
Which one do you need?
Before advertising a job or naming someone to a project, answer these:
- Do we sell this software, or use it ourselves? Only the first needs product management in the commercial sense.
- How many teams work on it? With one team, one person can hold both sets of decisions.
- Who will have the final say on the order of the work, and does everyone above them accept that?
- Who talks to the people who use the system, and how often?
- How many hours a week can the named person give?
Then write the job description around the decisions, not the title. Candidates and suppliers use both terms loosely, so ask anyone with either title on their CV which of the decisions above they held. For how Scrum compares with the other methods a supplier might propose, see the top software development methodologies, and for the client’s side of running a project, our 10 tips for project managers.