Product Owner vs product manager: role and job title

Hiring pages and org charts treat Product Owner and product manager as rival titles. Scrum treats them as different kinds of thing. One is a role defined in a short framework document. The other is whatever a company decides it is. That is why the same two words can mean a strategic leader in one firm and a backlog administrator in the next.

What the Guide defines

The Scrum Guide gives the Product Owner a precise set of accountabilities. The Product Owner is accountable for maximising the value of the product resulting from the work of the Scrum Team, and the Guide adds that how this is done may vary widely across organisations, Scrum Teams and individuals. The Product Owner is also accountable for effective Product Backlog management: developing and explicitly communicating the Product Goal, creating and clearly communicating Product Backlog items, ordering them, and ensuring the backlog is transparent, visible and understood.

Two features matter for this comparison. The Product Owner is one person, not a committee, and may represent the needs of many stakeholders in the backlog. And the Product Owner may do the work or delegate it, but remains accountable. The Guide also states that for Product Owners to succeed, the whole organisation must respect their decisions.

What "product manager" means

The Guide does not mention product managers. In practice the title usually covers work that sits around the Scrum Team: understanding the market and customers, setting product strategy, deciding positioning and pricing, working with sales and marketing, and building a longer-term roadmap. Different companies stretch or shrink that list. Some product managers write stories and attend every Sprint Planning. Others never see a backlog.

A vendor article on Scrum roles makes the general point that roles are not job titles, and that any job title can be used to perform a role. It follows that a product manager can be the Product Owner, and a Product Owner can have the title of business analyst, engineer or director.

The SBOK® Guide similarly says the Product Owner is the Voice of the Customer, with a dual view: understanding the needs of business stakeholders and also the needs and workings of the Scrum Team. It adds that the Product Owner does not always represent an external customer. In an internal IT project, requirements such as performance, security or reliability may be owned by technology groups, and the Product Owner may then be a technical architect or lead.

Three common setups

One person holds both. The product manager is the Product Owner for a single team. This is the cleanest arrangement for a small product. The risk is overload: strategy work and daily backlog care compete for the same hours, and the Sprint suffers when strategy wins.

A product manager above Product Owners. One product manager sets strategy for a product area and several Product Owners each serve a team. This can work where the product is large. The risk is that the Product Owners become order-takers without authority, which the Guide's "one person, accountable" wording warns against. If a Product Owner cannot reorder the backlog without asking, the accountability sits elsewhere.

Split by function. The product manager owns outward-facing work and the Product Owner owns inward-facing work with the team. This can be a sensible division of labour if the Product Owner keeps the final say on what enters the backlog and in what order.

A worked example: who decides?

This is an illustrative case. A company has a product manager who has just come back from a customer conference with three feature requests. She also leads a Scrum Team, which has a Product Owner who joined last year.

In a healthy arrangement, the product manager shares what she learned and the evidence behind it, and the Product Owner decides how it fits against the Product Goal and the existing order. The Product Owner might take one request to the top, park another with a note about what would change that, and decline the third with a reason. All of this is visible in the Product Backlog. If the product manager does not agree, she tries to convince the Product Owner, as the Guide says anyone wanting to change the backlog should do.

In an unhealthy arrangement, the product manager adds the three items to the top of the backlog herself on Monday morning, in the middle of the Sprint, and tells the team they have to be in by Friday. The Product Owner learns of it from a Developer. At that point there are two owners, and the Sprint Goal has lost its protector. The fix is not a better title. It is an agreement about which decisions each person makes.

Questions that settle the overlap

1. Who may reorder the backlog without asking anyone? That person is the Product Owner in Scrum terms.
2. Who speaks for the product at the Sprint Review? The Guide expects the Product Owner to be the one who answers to stakeholders.
3. Who decides the Product Goal? If the answer is a committee, the Guide's single accountable person has gone missing.
4. Where does strategy come from, and how does it reach the team? There should be a regular, visible path, such as a quarterly review of the Product Goal.
5. Who owns revenue, pricing and market position? If it is not the Product Owner, the Product Owner needs to know the targets, and the product manager needs to understand what the team can do.

Why it matters for the team

Developers feel the difference quickly. If priorities arrive from two people who disagree, the team ends up choosing which to follow, and a self-managing team should not have to referee its own stakeholders. If strategy never reaches the backlog, the Product Goal turns into a slogan. The remedy in both cases is the same: one named person who can say yes and no, and a visible route for strategic input to reach that person.

It also matters for careers. A Product Owner who is told that their job is only to write stories will not grow into the accountability the Guide describes. A product manager who is told that the backlog is somebody else's problem will lose touch with what the product actually does. Naming the split helps both.

Common mistakes

• Using the titles as if they ranked, with the "manager" above the "owner". The Guide says nothing of rank.
• Appointing a Product Owner with no authority over the backlog, who relays decisions made elsewhere. See the proxy Product Owner problem.
• Treating Product Owner as a part-time duty for a busy executive. The Guide expects active management of the backlog.
• Assuming a Product Owner should not think about strategy. The Product Goal is a strategic statement that the Product Owner develops and communicates.

How to practise it

Write down, for your own product, the five questions above and the names that answer each. Gaps and double answers show where the confusion lives. The simulator lets you play the Product Owner, where you feel the weight of ordering the backlog with competing requests.