Product Owner or Product Manager: which one do you really need?

It happens to us a lot. A company asks us to find a Product Owner and, ten minutes into the call, they’re describing someone who talks to customers, sets the year’s roadmap and persuades leadership where the product should go next. In almost any organisation, that’s a Product Manager.

Nobody’s to blame. Look through a few job ads and you’ll see the two titles used almost interchangeably, with the same job description carrying a different name from one company to the next. The trouble starts when you hire the wrong person for what you actually need. It shows quickly, in the engineering team, in priorities and in what eventually reaches production.

Where the line sits

There’s no universal definition and every company organises product its own way. Still, there’s a distinction we find genuinely useful.

The Product Manager decides which problems are worth solving and why. To do that they work with customers, usage and market data and the rest of the business, and the product strategy comes out of that work.

The Product Owner makes sure the team builds what has been decided, and builds it well. They manage the backlog, write and prioritise stories, unblock the team and sign off what gets delivered.

The Product Owner role comes from Scrum, where it sits inside the team. Product Manager is a broader role that exists with or without Scrum. In many companies one person does both; in others they’re clearly separate.

An ordinary week for each

If you shadowed a Product Manager for a week, you’d see them talking to customers and users to find out what hurts, going through usage data and what competitors are doing, and sitting with leadership, sales, marketing and engineering arguing why one thing should come before another. After each launch you’d see them checking whether it did what it was meant to. A lot of their time is spent outside the development team.

A Product Owner spends the week much closer to the team. They keep the backlog in order and prioritised, write user stories with clear acceptance criteria, join planning, refinement and reviews, and stay available so nobody gets stuck waiting for a functional answer. At the end of the sprint, they accept or reject what’s been delivered.

What your team is missing

Your context decides which profile to look for far more than the title does. These are the situations we come across most:

• The product’s direction isn’t clear. You need a Product Manager. A Product Owner who’s excellent at running a backlog without a strategy will only help the team build something that may not matter, faster.
• The strategy is set, but the team drifts day to day. You’re missing a Product Owner, someone who turns the vision into concrete work and is there for the team.
• You’re a small company with one or two teams. You almost always need one person covering both. Look for a Product Manager who’s happy to get into the detail, not the other way round.
• You have several teams and a complex product. Splitting the roles is the norm, with Product Managers owning strategy for an area and Product Owners embedded in each team.

Who your users are matters too. With internal or highly technical products, the role tends to lean towards execution. When there are end users and plenty of competition, discovery carries more weight.

Interviewing a Product Manager

Product interviews have a habit of staying at the level of frameworks, and nearly every candidate knows those well. What works is asking for stories and digging into them.

Ask about a hard product decision: what the options were, what information they had and why they picked one. Notice whether they mention what they ruled out. Ask about something they launched that didn’t work, how they realised and what changed afterwards. We’re fairly wary of anyone who has no example like that. Find out how and how often they talk to users, and about something specific that changed because of those conversations. And ask how they got another team to back a priority it didn’t initially agree with, because much of the job is influence without authority.

A practical exercise helps if it’s short and realistic. Give them a problem from your product and ask how they’d approach it, what they’d ask first and what they’d need to know.

Interviewing a Product Owner

Here the conversation gets closer to the ground. Ask how they decide what goes into the backlog, what comes out and in which order, and what they do when everything looks urgent. One very simple test that tells you a lot is asking them to write a user story for a basic case. Five minutes and you’ll see how clearly they think.

Ask about working with engineering too, how they handle debates about scope and estimates and how they shield the team from constant change. And from the other side, how they tell someone in the business that their request won’t make this sprint.

A good Product Owner gives the team clarity and stability. If the team is firefighting in every example they give, ask why.

Start with the work, then pick the title

Plenty of searches go wrong before they start, with a job ad copied from another company, one that expects full-time strategy and full-time execution at once, or one that confuses product with project management. Tracking deadlines matters, but it isn’t the same as deciding what to build. Filtering on certifications doesn’t help much either. A Scrum certificate tells you about training, not judgement.

Our suggestion is to do it the other way round from usual. Write down where this person’s time will actually go in a normal week, and only then decide what to call the role. If you’d like to do that exercise together, we at Mimmic Talent are always happy to help you shape the role before anyone starts searching.