Do You Need a Product Owner If You Already Have a PM?

One question that keeps coming up is whether a product owner and a product manager are the same thing.

Most of the time, when people ask this, they’re really trying to figure out who owns what. Who decides what gets built? Who manages the backlog? Who talks to customers? Who sets direction?

The reason the answer gets confusing is that “product owner” is a Scrum role, while “product manager” is a job title. In some companies, they’re the same person. In others, the responsibilities are split across two people. That’s why you’ll hear completely different answers depending on who you ask.

I’ve worked as a product manager at Userpilot for years, and I’ve never worked with a dedicated product owner. Looking at our product analytics, figuring out where users get stuck, deciding what to prioritize, and shipping improvements are all part of the same role. But there are organizations where the split is intentional and makes sense.

So instead of asking whether product owners and product managers are the same role, I think the better question is when it makes sense to separate them. That’s what we’ll unpack in this article.

One quick note before we start: PM can mean either product manager or project manager, depending on the organization. Those are different roles. Throughout this article, PM refers to product manager.

Are PM and PO the same thing?

No, not technically, but in most product teams, the key differences between the two roles are invisible because one person holds both responsibilities.

At large organizations with multiple engineering squads each needing dedicated backlog management, you might find the roles formally separated. For most SaaS product companies, the PM writes actionable user stories, owns the product roadmap, and sets the strategic direction without a formal title split.

The key difference driving this question is that Scrum gave the PO a specific, bounded definition while product management has always been a broader discipline.

In a Scrum context, the PO is a named role with core responsibilities: owning the backlog, prioritizing features, leading sprint planning with the development team, and accepting completed user stories.

Product management covers the entire product lifecycle through high-level strategy: market research, competitive positioning, pricing, and go-to-market decisions that Scrum has no opinion on.

Why does the difference exist in the first place?

The reason this question exists at all is that a product owner and product manager came from different places.

Product management as a discipline predates Scrum by more than half a century. Procter and Gamble formalized the brand manager model in 1931, and Hewlett-Packard was organizing itself around products by the 1940s. By the time Silicon Valley tech companies were scaling up in the 1980s, Product Manager was an established career track covering market positioning, product features, roadmap ownership, go-to-market coordination, and post-launch iteration.

When Scrum introduced the Product Owner role in the mid-1990s, it wasn’t trying to define all of that. Nowhere in the Scrum Guide is there guidance on what a PO should do about customer needs, market opportunities, competitive positioning, pricing strategy, or long-term product vision. Those questions belong to business strategy, and they were outside the framework’s scope by design. That gap is why POs in different companies ended up doing very different amounts of the broader product job.

Melissa Perri, founder of Product Institute and author of Escaping the Build Trap, made the clearest possible distinction:

“Product Owner is a role you play on a Scrum team. Product Manager is the job.”

She expanded on why this matters on Lenny’s Podcast in November 2024, arguing that frameworks like SAFe made things worse by formally separating the two, thereby disconnecting strategy from execution. That diagnosis matches what I’ve seen in practice: when the PM owns the roadmap, and the PO owns the backlog, you end up with two people who each have half the context they need to make good decisions.

The confusion is compounded by the fact that companies that adopted Scrum through the 2000s and 2010s landed all over the map on what they called their product people. Some gave existing PMs the PO title because that’s what Scrum prescribed, without changing what the role actually did. Others created a genuine organizational split, with a senior PM setting direction and a junior PO maintaining the backlog.

Outside the US, both titles are frequently used interchangeably with no connection to the Scrum methodology at all. The result is that “product owner” and “product manager” can describe roles that are structurally near-identical, or roles with a sharp hierarchy between them, entirely depending on the company.

Where PM and PO sit in an org chart (and who earns more)

When both roles exist in the same organization, the standard hierarchy gives the PM direct authority over product direction and strategic decisions, though not always as a direct reporting line.

In larger organizations, product owners often report directly to product managers to keep both roles aligned toward the same product strategy. A useful shorthand for how the three Scrum roles relate in practice:

“The Product Manager says, ‘This is what we need.’ The Product Owner says, ‘This is how it will work.’ The Scrum Master says, ‘Let’s get it done.'”

The product manager defines the strategic priorities:

• Aligning cross-functional teams.
• Developing the feature roadmap.
• Conducting market research.
• Coordinating go-to-market timing.

Product owners focus on translating those priorities into actionable user stories, epics, and acceptance criteria for the product development team. In terms of scope, the PM has a broader range of responsibility and operates further from the sprint cycle, while the detail-oriented PO operates closer to it.

The two roles also differ significantly in timescale: product managers typically operate on 6 to 24-month product roadmaps, while product owners work in sprint cycles of 1 to 4 weeks.

That difference in time horizons explains why the two roles feel distinct in practice, even in teams where a single person holds both. It also defines who interfaces with senior leadership to align on business goals versus who works closely with engineering on daily execution.

The external-versus-internal divide reinforces this. Product managers work with external-facing groups such as customers, non-technical stakeholders across marketing and finance, and senior leadership to determine the product roadmap. Product owners work closely with internal teams, primarily engineering and design, to translate that roadmap into sprint-ready deliverables.

In practice, the collaboration follows a continuous loop: the product manager’s vision sets the direction, the PO translates it into actionable tasks for the development team, the team executes, and customer feedback cycles back to inform the next iteration. That loop works well when both functions are handled by a single person.

In organizations that separate the roles, the loop becomes a handoff chain, and that chain is where strategic intent tends to degrade.

At Userpilot, my standard practice after releasing a feature is to create a report and track the meaningful events to understand usage and feature health. From there, I use funnel analysis to look for where drop-offs occur and which steps create friction.

More often than you would expect, it turns out to be the in-app messaging, and when it is messaging, the fix doesn’t require a ticket at all. That’s the part of the PM-to-PO-to-dev chain worth examining: if the issue can be diagnosed in product analytics and resolved with an in-app change, the translation layer never needed to exist.

On compensation, Glassdoor’s 2026 data shows a US median base salary of $150,575 for product managers and $141,494 for product owners, a gap of roughly $9K. That gap narrows considerably at the senior end, where a specialist PO at a large Scrum organization running SAFe can command PM-level pay. Outside the US, both titles are used interchangeably enough that title-based salary comparisons are mostly noise.

Do you need to have both roles in the same team?

Most product teams don’t need the formal PM/PO split.

It’s primarily an enterprise pattern tied to mature agile practices. It makes sense in specific conditions: the organization is running Scrum or SAFe across multiple engineering teams, each agile team responsible for a product area needs dedicated backlog ownership to maintain business value delivery across complex products, and the PM’s scope is wide enough that managing story-level detail isn’t feasible. That describes large banks, enterprise software companies, and any org that went deep on SAFe.

For most SaaS product teams, those conditions don’t apply. Creating a separate PO role doesn’t reduce the work; it creates a handoff layer where strategy must be retranslated before it reaches engineering, and that layer is where intent tends to degrade.

In my experience, the better answer when a PM has too much on their plate is a second PM, not a PO layered between strategy and execution. The PO role compounds the coordination overhead rather than removing it.

The AI dimension is making it even more complicated to sustain a dedicated delivery PO. Itamar Gilad, a product strategist and former product leader at Google who writes extensively on product management practice, published an analysis of the changing PM role in May 2026 that named the delivery PO specifically as the product role most vulnerable to AI displacement:

“The delivery PO’s main job is to translate roadmaps defined by other people into backlogs, PRDs, and user stories. The challenge here is that AI is already capable of producing such artifacts at a fraction of the time and cost, and they are polished and convincing.”

His full analysis draws a parallel to CAD software displacing draftsmen in the 1980s: the draftsman’s core skill was translating a designer’s intent into schematics, and once architects could produce those schematics themselves with the right tool, the role compressed. TrueUp data from March 2026 shows that 41% of global code is now AI-generated, meaning the sprint-cycle translation work that once justified a dedicated PO is already compressing at the execution level.

I’ve seen this play out directly at Userpilot. When we launched our email feature, the activation funnel showed a sharp drop-off at the domain verification step. The problem wasn’t in the code; it was that users weren’t sure what to do next at that point in the setup.

Within a few hours, I used Userpilot’s no-code in-app builder to ship a targeted tooltip that highlighted the correct next step, scoped to the user segment hitting the drop-off. That resolved the friction in real time, without involving the dev team. There was no ticket, no sprint, no handoff to a separate role to translate a strategy into a specification.

That’s what a PM with the right toolset looks like in practice: feature analytics to find the problem, in-app flows and tooltips to ship the fix, and a measurement layer to confirm the result. Userpilot puts all three in one platform — product analytics, no-code in-app experiences (tooltips, modals, banners, checklists), user segmentation, and funnel tracking — which means the traditional PM-to-PO-to-dev chain is increasingly a description of an older workflow rather than a necessary one.

What AI is absorbing is specifically the delivery variant of the PO, the one whose core job is artifact generation and backlog translation. A PO who pushes back on roadmap decisions, drives discovery sessions with customers, and challenges the PM’s prioritization is doing something harder and less automatable. That version of the role is not under the same pressure, and conflating the two misses the point.

PM, PO, or both: Making the call for your team

The product owner and product manager titles come from different traditions that converged when companies adopted Scrum at scale. On paper, they describe different roles. In practice, in most product teams, one person serves as both the PM and the engineer, resulting in a more valuable product built without the friction of a handoff layer.

The split makes sense only when an organization is large enough, Scrum-mature enough, and team-dense enough that dedicated backlog ownership per team genuinely can’t be covered by the PM. Most SaaS companies never reach that point. The teams that separate roles often find that the handoff overhead outweighs the benefit, particularly now that AI can generate the kinds of artifacts that once made a full-time delivery PO necessary.

If you’re trying to decide which structure fits your organization, start with one PM owning the full cycle, invest in tools that let that PM stay close to both strategy and execution, and consider adding a PO only when the scope genuinely requires a dedicated translator at the sprint level. The goal is the same regardless of how you structure the titles: shipping a successful product that meets company goals and serves user needs. That’s a much higher bar than most teams realize.

If you want to see what that looks like in practice, book a Userpilot demo and we’ll show you how one PM can run product analytics, ship in-app fixes without engineering involvement, and measure the results — all on a single platform, without a handoff layer.