Keep vs. Offload: The PM Decision-Rights Boundary
A clear line for what a PM keeps versus hands to product ops — decision rights never move
- Difficulty
- Easy
- Time to result
- ~days to results
- Steps
- 3
- Confidence
- 92%
When product ops arrives, PMs fear losing their job scope. The boundary is simple: product ops operationalizes and informs, but the PM retains all decision rights and ownership of outcomes. Anything that is repeatable busywork or coordination can move; anything that is a product decision, a hard tradeoff, or accountability for outcomes stays with the PM.
Origin
Melissa Perri and Denise Tilles, articulated in their Product Operations book as a response to the common PM fear that product ops erodes the role.
Core principles
- 01Product ops is 'the product manager for the product managers' — they operationalize great product management, not the product itself
- 02Never outsource decision-making to a product ops person
- 03The PM owns outcomes, so the PM must own the levers that produce them
How to run it
- 1
Offload repeatable operational and coordination work
Hand over data extraction/queries, scheduling and automating customer outreach, aggregating information across the org, roadmap-template standardization, cadence-setting, and go-to-market program coordination.
Pro tip Ideal targets are anything you do repeatedly that a system or automation could own — automating customer-interview invites is a perfect example.
- 2
Keep all decision rights
Retain strategy, vision, prioritization, resource allocation, and the actual build decisions. A product ops person can point you toward customers or surface information, but must never tell you 'you should build this.'
Watch out If a product ops person is making product decisions or dictating what to build, the boundary has been crossed and it's the wrong setup.
- 3
Keep the human-judgment and accountability work
Keep doing your own user research and interpretation, hard stakeholder conversations about tradeoffs, and monitoring outcomes. Product ops does not project-manage your developers or own delivery timelines.
Pro tip You must still be comfortable reading charts, spotting trends, and understanding causation vs correlation — that never becomes less important.
Watch out Product ops are not project managers watching developers ship on time, and they won't handle hard tradeoff conversations for you.
In the wild
A product ops person can send the email inviting customers to a meeting, ideally automated, and bring you related information from around the org on a problem area. But you still run the interviews and you still read through the information and decide what to build.
→ The PM keeps decision ownership while shedding the scheduling and aggregation busywork.
Common mistakes
Outsourcing decisions to product ops
Delegating what to build hollows out the PM role and misassigns accountability for outcomes.
Expecting product ops to police delivery
They are not project managers; chasing developers on timelines remains the PM's job.
Is it for you?
Best for
A nervous PM or product leader defining scope as a new product ops function is introduced
Not ideal for
Solo PMs at tiny companies with no product ops person to delegate to
From the transcript
“They don't want to offload decision rights. You should never be like outsourcing your decision making to a product ops person.”
“they're they're the product manager for the product managers. That's how I think about it”
“They're not going to handle hard stakeholder conversations about trade-offs for you.”
“as a product manager, your job is to produce outcomes and you do need to make sure that you're monitoring those outcomes”
From the episode
The ultimate guide to product operations
Melissa Perri and Denise Tilles