Respect the Hustle: Goal-Based Product Ops Allocation
Allocate ops support to goals, not headcount ratios — and deliberately under-process the teams still finding their way.
- Difficulty
- Moderate
- Time to result
- ~ongoing to results
- Steps
- 5
- Confidence
- 90%
Itwaru rejects the idea of a fixed product-ops-to-product-team ratio. Instead, every few quarters her team re-derives allocation from the company's goals: which goals need a product ops person, and why. The corollary is a deliberate asymmetry she calls 'respect the hustle' — mature product teams get the full process and the slower, heavier voice-of-customer cadence; new products still finding their way get minimal process and fast, raw signal, because imposing planning rituals on a team trying to hit the ground running stifles the creativity you hired them for.
Origin
Christine Itwaru's operating model for the product ops team at Pendo, sharpened by lean-times headcount pressure and by her own prior experience managing three very different products at once — a legacy product, a zero-to-one build, and a product she was merely shipping and sunsetting.
Core principles
- 01There is no correct product ops to product team ratio; allocation follows goals.
- 02Ops people are shared across two or three teams by design, not by scarcity.
- 03Process is not a neutral good — applied to a young team it stifles creativity.
- 04Product maturity determines process weight: mature product, heavy process; new product, light touch and fast data.
- 05Re-derive allocation every few quarters; a static assignment silently becomes overhead.
How to run it
- 1
Start from the goals, not the org chart
Every few quarters, review the company's goals and ask, explicitly: which of these goals need a product ops person, and for what reason? Allocate against the answer.
Pro tip Write down the 'for what reason' — it becomes the exit criterion for pulling the person off later.
Watch out Assigning one ops person per product team by default creates work to justify the assignment.
- 2
Share people across two or three teams
Even where product ops is integrated into every product team, a single ops person should split themselves across two or three of them. This forces prioritisation and prevents them becoming a team's process administrator.
- 3
Classify each product by maturity
Sort products into mature/core (long-standing, broken into components, many directors) versus new/finding-its-way (single product team, still experimenting). The classification determines the process weight, not the team's preference.
- 4
Deliberately under-process the young teams
For the newer product, do not over-index on planning process or on 'you need to send us this because the other teams do'. Instead give them a single hard constraint: we need to know this one thing by this timeframe, and we'll do what we need to from there.
Pro tip This is 'respect the hustle' — the ops team absorbs the coordination burden so the product team keeps its speed.
Watch out The last thing you want is to introduce anything that feels like a time-bound ritual to a team that needs to hit the ground running.
- 5
Run voice of customer at two speeds
For mature teams, run the full, slower voice-of-customer synthesis. For the newer team, prioritise speed: what are we learning right now, and how quickly can we get it to them so they can iterate?
Pro tip Speed of signal is the deliverable for new products; completeness of signal is the deliverable for mature ones.
In the wild
Pendo is organised into revenue-stream business units with GMs (who sit in the product team and have PM backgrounds), a head of growth, senior directors, and cross-functional product teams — all rolling up to a CPO. A product ops person supports roughly all of them, but each one splits themselves across two or three teams. For the mature core product (broken into components), the full process and slower VoC cadence applies. For the newer product that is still one straight team finding its way, product ops deliberately holds back planning process and instead sets a single 'we need to know this by this date' constraint.
→ The new team keeps its speed and creativity, the mature team gets the full synthesis, and the ops headcount stays lean — no ratio, no per-team administrator.
Itwaru's own prior experience — running a legacy product, a product she was building from the ground up, and one she was shipping and eventually sunsetting — taught her that identical process across all three is destructive. The zero-to-one build in particular cannot absorb the planning rituals that a legacy product needs.
→ It became the origin of her 'respect the hustle' rule: never let process stifle creativity on a team whose job is to move.
Common mistakes
Chasing a product ops staffing ratio
Itwaru thought a ratio existed at one point and no longer believes it does. A ratio produces headcount ungrounded in any goal, and the assigned person then invents process to justify the seat.
Standardising process across mature and immature products
Uniform planning process feels fair and is quietly destructive — it stifles creativity on the team that most needs speed, while giving the mature team nothing it didn't already have.
Requiring a young team to conform because the others do
'You need to get this to us because the other teams have' is exactly the argument Itwaru names and rejects. Consistency is not a reason; the goal is.
Is it for you?
Best for
A product ops lead running lean across a multi-product org with a mix of mature and zero-to-one product teams, deciding where to put limited ops capacity each quarter.
Not ideal for
Single-product companies with a homogeneous team maturity — the differentiated allocation has nothing to differentiate.
From the transcript
“are having to operate it's very lean right now so every few quarters we look at our goals we determine who or what goals need…”
“we do have a product UPS person integrated into these teams I'd say probably all of them at this point but the key thing here…”
“so the last thing you want to do is introduce something in there that feels like that you want them to hit the ground running…”
“voice of customer stuff takes a little bit longer for a more mature product team and and or this is more like what are we…”
From the episode
Understanding the role of product ops
Christine Itwaru (Pendo)