System-First Product Ops (Build It, Then Get Out of the Way)
Product ops is first a system you build, only second a team you hire — and the system should outlive the role.
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 93%
Christine Itwaru splits product ops into two things people routinely conflate: (1) product ops as a noun-thing — a system that lets a product team thrive — and (2) product ops as people. Decoupling them means you can get most of the value without a headcount, and it means the ops people you do hire should be building systems designed to be handed off, automated, or deleted — then moving up into strategic advisory work. She applied it to herself: she stood up Pendo's product ops system, then changed roles once the system no longer needed her.
Origin
Developed by Christine Itwaru while standing up product operations at Pendo from 2019. She explicitly engages with Casey Winters' contrarian take (aired on Lenny's Podcast) that ops hires are often a band-aid for inefficiency, and partially concedes it: she agrees ops should stand up systems and then get out of the way, while arguing ops emergence is a sign of growth, not inefficiency. Marty Cagan's outcome-over-output framing is credited as background influence.
Core principles
- 01Product ops is a thing you do before it is a person you hire — a system can be the whole deliverable.
- 02Any system you build should be designed for its own obsolescence: hand off, automate, or cut it.
- 03Ops maturity is measured by movement up the stack — from process-running to strategic advisor to the head of product.
- 04The natural end-state of a good ops function is fewer humans doing the mechanical work and more humans doing the strategic work.
- 05Hire only people who are comfortable being told 'I no longer need you to do that.'
How to run it
- 1
Name the pain before naming the role
When something breaks (a botched launch, misaligned stakeholders, no feedback loop), do not immediately conclude you need a product ops hire. State the problem as 'we need to create a system so this doesn't happen again.' Itwaru is explicit that in the moment of Pendo's bad launch she did not say 'we need product ops' — she said they needed a system.
Pro tip A strong product person who understands the customer and the business can build the system without a new title existing.
Watch out Hiring an ops person to be a human band-aid for a process gap institutionalises the gap.
- 2
Build the system explicitly to be given away
Stand up the process, the tooling connections, the feedback loop — but architect each piece with a named exit: which team will own it, or what will automate it. Write down the handoff target at build time, not later.
Pro tip Ask at design time: 'in 18 months, is this a team's job, a tool's job, or nobody's job?'
- 3
Hire only change-tolerant ops people
Screen candidates on their comfort with impermanence. Itwaru made this explicit in every interview: take this role only if you are comfortable letting go of things and moving to something more worth your time. Processes will be tweaked, cut, or automated away.
Pro tip Say this in the interview, not in the first reorg — people who built a process and were then told to drop it will otherwise 'lose their minds'.
Watch out Changing course two or three years in, after a team has built its identity around a process, is the failure mode she is guarding against.
- 4
Redeploy freed capacity to strategic work, not more process
Once the system runs itself, push the humans up: retention, growth in a specific area, in-app experience, better voice-of-customer management, and strategic advisory to the CPO. Do not backfill their time with new process.
Pro tip Mature product ops people become strategic advisors to the head of product — that is the promotion path, and it is also the pitch you make when asking for the role.
- 5
Re-run the loop as the org changes
Treat the audit as recurring. The company changes, tooling changes, and AI makes previously human work mechanical. Periodically ask which of the current systems are now candidates for handoff, automation, or deletion.
In the wild
After several years building Pendo's product ops org, Itwaru concluded she had done what she set out to do — stand up the systems the team needed, with each one either handed to another team or automated. Rather than defend the footprint, she switched roles inside Pendo to focus on higher-leverage work for the product team, product community, and customers.
→ The systems persisted without her, and her energy moved to retention, growth, in-app experience, and voice-of-customer maturity rather than process maintenance.
Five weeks into her role at Pendo, the company shipped its biggest launch since the original product — and it went badly. Sales, success, and customers knew the feature was coming but had no idea what to do with it. Itwaru's response in the moment was not 'we need a product ops person'; it was 'we need to create a system so this doesn't happen again.'
→ The system came first; the formalised product ops function was spun out of it afterwards, and four years later the launch is a war story the team learned from rather than a recurring failure.
Common mistakes
Treating product ops as headcount rather than as a system
Companies jump straight to a hire because a hire is visible and a system is not. Itwaru's decoupling — 'it does not have to be humans, it can be that there's a system being created' — means many orgs can get the value without the role, and orgs that hire without designing the system just add a stakeholder.
Building processes that no one is allowed to kill
Ops teams that define their worth by the processes they run resist automation and handoff, which is exactly the inefficiency critics accuse ops of being. If the process cannot be given away, the ops function calcifies.
Hiring people who need permanence
Someone who needs their remit to stay stable will be destabilised when the process they built is cut or automated. That has to be screened for at hire, not managed after.
Is it for you?
Best for
A head of product or first product ops hire at a fast-growing company deciding whether to build a process or add headcount, and wanting the function to compound rather than calcify.
Not ideal for
Very small product teams where a single PM can hold all internal alignment in their head — the system overhead exceeds the pain it removes.
From the transcript
“the creation of some sort of system that allows you to thrive or allows your team to thrive in product management”
“I didn't say in that moment we needed product Ops rule out all I said in that moment was we need to create a system…”
“it does not have to be humans it can be that there's a system being created that is from a strong product person who knows…”
“product apps want to and should be standing up whatever processes or systems are needed and then get out of the way so we can…”
“so for years when I was interviewing folks for my team I made that one point abundantly cleared them get into this role if you're…”
From the episode
Understanding the role of product ops
Christine Itwaru (Pendo)