Christine Itwaru on Product Operations

Source: Lenny’s Podcast Speaker: Christine Itwaru Source URL: https://www.lennyspodcast.com/christine-itwaru/

Key ideas

• Product ops dual definition: (1) a system or process any PM or leader creates to help their team thrive; (2) the people/role that supports PMs day-to-day and advises product leaders strategically. The role need not always be a person — it can be a well-designed system.
• PM’s sacred responsibility: spending time with customers. Product ops exists to take everything else off the PM’s plate so they can be fully present with customers and engineers.
• Three core domains: voice of customer (qualitative + quantitative synthesis, cross-functional transparency); tooling/data stack management; content and education strategy.
• Systems first, then automate, then strategic: the product ops mandate is to stand up systems, hand them off or automate them, and move to higher-value strategic advisory work. Leaders who don’t communicate this upfront create confusion when the role evolves.
• When to hire: lack of cross-functional transparency; revenue teams asking “what is this?” instead of “how do we prepare for this?”; quality time for PMs with customers consistently crowded out by stakeholder firefighting.

Product ops definition

Two meanings that must be decoupled:

1. The thing: a system or process a PM or product leader creates to enable their team to thrive. This can exist without a dedicated person.
2. The person/team: individuals who partner with PMs on data, qualitative/quantitative synthesis, and voice of customer — and at more mature stages become strategic advisors to the CPO or VP Product.

The role emerged prominently around 2019 (the “summer of product ops” at Pendo). Drivers: rapid company growth during the pandemic, shift towards product-led growth tactics, increasing CPO accountability to business metrics beyond pure product delivery.

Analogous maturation arc: marketing ops, sales ops, revenue ops all followed the same pattern as their functions scaled.

Core responsibilities

The transparency and readiness distinction

Pendo’s founding product ops story: a bad launch in Christine’s fifth week. Teams knew it was coming — the failure was not awareness but readiness. “Knowing something’s coming” vs “knowing what to do with it” are different. The product digest Pendo built was oriented to the second: not “this ships Q4” but “here’s the new value, here’s how you position it, here’s what to do now.”

Alignment health metric: quality of inbound questions from the revenue team. Early signal: the ratio of “tell us what you do” questions vs. “help me understand how to get my customers ready.” The former indicates transparency gap.

What product ops is not

• Not product marketing: PMM positions, runs lead gen, outbound campaigns. Product ops educates internal teams on new value — how to use it, how it impacts their role, how to help customers understand it. Not selling or positioning.
• Not programme management or agile: overlaps with both in less mature orgs but distinguished by product and customer knowledge — product ops people understand the product, the customer, and the business from the inside.
• Not a permanent process owner: the goal is to build the system, then hand it off or automate it, then move to higher-leverage strategic work. Failure to communicate this at hire creates friction when the role naturally evolves.

When to hire product ops

Signals:

1. PMs spend meaningful time fielding revenue team questions they could spend with customers.
2. Outcomes and product decisions are not transparent across the organisation consistently.
3. Launch readiness repeatedly breaks down — teams know what’s coming but not what to do.
4. Growth has created internal coordination load that crowds out PM’s core work.
5. Product ops is not needed if the PM population is small and the organisation is not yet scaled enough for coordination overhead to be real.

Pendo approach: every few quarters, review goals and determine which product areas need a product ops person and why. Product ops people shared across two to three teams rather than 1:1 ratio.

Career path

Who fits product ops:

• Former PMs who love team health, cross-functional collaboration, and solving system-level problems more than building features.
• People from management consulting, technical customer success, customer success — strong data orientation + advisory skills.
• Sales backgrounds: rare in product ops so far.

Leadership roles: should have hands-on product background. Understanding customer pain firsthand determines where to place efforts and builds credibility quickly.

Career shift signal: if you’re a PM who doesn’t love building features but loves enabling others to do it well, product ops is worth exploring. The customer-problem-solving instinct transfers — internal teams are your customers.

Bringing engineers to customer meetings

Christine’s high-impact low-effort change at Pendo: systematically including engineers in customer calls. Initial resistance (“I’ve got other things to do”) dissolved rapidly once engineers experienced customer pain and delight first-hand. Outcome: engineers’ voices had more weight in planning; PM-engineering alignment improved; engineers gained customer confidence.

See also

• Christine Itwaru
• Product Operations
• Brian Chesky on Airbnb and Product
• Christian Idiodi on Product Management