“Product Owner” isn't a job. It's a Scrum role - and the difference is costing you.

I'll admit it: whenever I come across a “Product Owner” job ad, I go a little nuts. Not because the people in those roles aren't talented - they usually are - but because the role, as most companies define it, quietly strips out the most important parts of building a product.

The confusion starts with a category error. “Product Owner” is a role within Scrum. “Product Manager” is a discipline. Treating them as synonyms is how you end up paying for product leadership and receiving backlog administration.

What Scrum actually says a Product Owner does

Go to the source. In Scrum, the Product Owner's responsibilities are, roughly:

• Define the product backlog and write actionable user stories for the development team.
• Groom and prioritise the work in that backlog.
• Accept completed user stories.

Notice what all of that has in common: it's delivery-facing. It's about turning already-decided work into tickets a team can build. It says nothing about whether the work is worth building in the first place.

What a Product Manager actually does

A Product Manager operates a level up:

• Prioritises work against clear, outcome-oriented goals - not just a list of requested features.
• Discovers and validates real customer and business value before committing to build.
• Reduces the uncertainty around whether the product will actually succeed in the market.

Why “Product Owner,” as usually practised, isn't product management

When the role is scoped the way most orgs scope it, here's what you actually get:

• The PO is told what to build and how to build it.
• They focus on delivering outputs - features shipped.
• There's no cross-functional discovery: the PO tells developers what to build, while value and business viability are treated as “the stakeholders' problem.”
• They receive a list of features that need to be coded and shipped.
• The role gets scoped down to Backlog Administrator - whose main job is prioritising a queue of features someone else decided on.

That's not a knock on the individuals. It's a knock on a setup that hires a smart person and then removes their ability to influence the two things that decide whether a product works: is it the right thing to build, and is it viable for the business?

To be clear: this isn't Scrum-bashing

Agile methodologies are genuinely useful, and the Product Owner is a perfectly good Scrum function. The problem is treating that Scrum function as the ceiling of product responsibility instead of one slice of it. Product Managers should ultimately own both Product Discovery (building the right thing) and Product Delivery (building the thing right). Scoping someone to only the second half and calling it product management is where it goes wrong.

If your title says “Product Owner,” do this instead

You don't need to wait for a re-org to start acting like a Product Manager:

1. Focus on outcomes, not outputs. Tie the work to a change in customer behaviour, not a count of features shipped.
2. Decide together. Pull design and engineering into product decisions instead of handing them a spec. (This is the whole idea behind a Product Trio.)
3. Talk to customers. Discover their real problems and needs - the actual product opportunities.
4. Infer, then validate. Propose solutions based on those opportunities and test your riskiest assumptions before building.
5. If none of that is possible in your current setup, that's a signal - the organisation may need to transform into a genuinely product-led model.

Think of it like a ship with one captain, or a football team with one quarterback: a product team needs a single person taking end-to-end ownership of customer value and business viability. Call it Product Owner if your framework demands it - but do the Product Manager's job.