Lenny's PodcastThe ultimate guide to product operations | Melissa Perri and Denise Tilles
CHAPTERS
- 0:00 – 3:45
Why product ops exists: freeing PMs for strategic work
Melissa Perri opens with the core trade-off: scale by hiring more PMs to do operational work, or build shared systems via product ops so PMs can focus on strategy. Lenny introduces Melissa and Denise, their backgrounds, and the goal of demystifying product operations end-to-end.
- •Product ops as leverage: shared infrastructure vs. “side-of-desk” PM work
- •Context: Melissa and Denise’s book and experience scaling product orgs
- •What the episode will cover: definition, differences vs. other roles, hiring, rollout, case study
- 3:45 – 7:41
How common product ops is—and how it spread
They trace product ops from a niche concept to a role present in many scaling tech companies. Melissa and Denise share informal benchmarks from cohorts and classes, plus influential early adopters and advocates.
- •Product ops adoption has surged over ~5 years
- •Rough signal: ~50–60% of cohort companies have some product ops capability
- •Early propagation via leaders like Blake Samek (Uber → Stripe → OpenAI)
- •Acceleration as more companies standardize what “good product” needs at scale
- 7:41 – 11:37
The ROI case: benefits of product ops and getting PM buy-in
Denise frames product ops as enabling PMs to spend more time on outcomes and less on data wrangling and operational busywork. Melissa addresses PM fears directly: product ops supports decision-making without taking away decision rights.
- •Primary benefit: PMs refocus on strategic, outcome-driven work
- •Common pain: 20–30% of PM time lost to data harvesting and coordination
- •PM reassurance: product ops informs decisions; it doesn’t own product decisions
- •Examples of “busywork” to eliminate: interview logistics, ad hoc querying, template chaos
- 11:37 – 15:26
The product ops model: three pillars that define the role
They introduce a clear framework for product ops work: quantitative insights, qualitative insights, and process/practices. Which pillar matters most depends on company stage and the specific bottlenecks preventing good product execution.
- •Three pillars: business & data insights; customer & market insights; process & practices
- •High-growth companies often start with business/data insights
- •Enterprises in transformation often start with process/governance and operating model
- •Customer/market insights is often under-invested (“the squishy middle”)
- 15:26 – 18:36
Customer & market insights: how it fits with user research, sales, and support
They clarify that product ops doesn’t replace user research; it operationalizes it—repositories, participant pools, tooling, and insight distribution. Product ops also helps translate and route qualitative feedback from sales/support into usable product inputs and closes the loop back to GTM teams.
- •Create research repositories (e.g., Dovetail) to avoid duplicated research
- •Build participant databases and opt-in programs for alphas/betas and interviews
- •Improve insight flow from sales/support systems into product decision-making
- •Increase transparency back to sales/support about how feedback is used
- 18:36 – 28:57
Why product ops will be essential—and what PMs must still own
Lenny frames product ops as a major evolution in product management: a new specialization that makes teams more effective at scale. Melissa and Denise draw sharp boundaries: PMs keep decision rights, strategy, and stakeholder trade-offs; product ops standardizes and coordinates the systems around that work, including go-to-market enablement.
- •Scaling makes “PM does everything” untenable; context switching and overhead explode
- •PMs must keep: decision-making, strategy, prioritization, trade-offs, outcome ownership
- •Product ops can support GTM via templates, cadence, coordination—PM still provides core inputs
- •Avoid misusing product ops as a proxy project manager or stakeholder shield
- 28:57 – 29:43
Product ops vs. project/program management (and why it gets confused)
They distinguish product ops from project and program management by the outcome: faster, higher-quality product decision-making. Program managers run broader initiatives; project managers drive time-boxed delivery—product ops builds the operating infrastructure across product work.
- •Product ops optimizes decision speed/quality across product teams
- •Program management: ongoing, cross-company initiatives
- •Project management: time-boxed projects with defined end dates
- •Role boundaries can get fuzzy, so clarify purpose and expectations early
- 29:43 – 37:48
Business & data insights: dashboards, product lenses, and executive visibility
They go deeper on what the quantitative pillar looks like in practice: connecting data/BI/finance inputs and translating them into product-relevant views. Melissa emphasizes the executive use case—product health dashboards and cuts by segment/product line that enable strategy and board reporting.
- •Connect existing BI/data science outputs to product decisions (no reinvention needed)
- •Shift from company metrics to product metrics (e.g., ARR by segment/product line + adoption)
- •Build repeatable dashboards and board-ready reporting to avoid constant manual refresh
- •PMs still need data literacy; product ops improves access, reliability, and speed
- 37:48 – 39:27
Will product ops become obsolete? Automation and the “product mindset”
They respond to the idea that ops roles indicate inefficiency that software should eliminate. Product ops should actively streamline and automate—but oversight, evolution, and stewardship remain necessary as tools and organizational needs change.
- •Product ops should seek to productize/automate repeatable work
- •A lean shared-services model is the goal—not a 1:1 shadow org
- •Even automated systems need owners to keep them relevant and effective
- •The role evolves with changing tools, data, and organizational complexity
- 39:27 – 44:41
Team sizing and structure: shared services vs. hybrid embedding
They explain why there’s no fixed ratio for product ops staffing and why 1:1 is a red flag. The right size depends on instrumentation maturity and whether you need a temporary embedded “stopgap” model while building scalable shared systems.
- •No hard ratio; 1:1 product ops to PM is “doing it wrong”
- •If instrumentation is weak, you may temporarily embed analysts near product leadership levels
- •As systems mature, the team should get leaner and focus on platform-like services
- •Different pillars often require different backgrounds (data/consulting vs. product vs. research ops)
- 44:41 – 59:49
How to roll it out: quick wins, first hire strategy, skills, and reporting line
They outline practical steps to start: pick the highest-leverage pillar, run a listening tour, deliver quick wins, and set expectations about what a team of one can/can’t do. They cover hiring trade-offs (experienced vs. coachable), key skills by pillar, and why product ops should report into the head of product.
- •Start with one person and one pillar; validate value before expanding
- •Do a listening tour/user research to find the biggest bottlenecks and fastest wins
- •Hiring: if you can’t coach, hire someone who’s done it; otherwise hire for skillset + learning
- •Skills by pillar: data storytelling + BI tools; high EQ + systems thinking; research ops + process orientation
- •Reporting: product ops should report to the CPO/head of product; often becomes their “right-hand”
- 59:49 – 1:09:33
Case study: rolling out product ops at athenahealth (what they built and why)
Melissa shares how product ops emerged at athenahealth during a massive product transformation (hundreds of PMs, thousands of engineers). The initial trigger was executive visibility—moving beyond Jira tickets to portfolio roadmaps, OKR tracking, and consistent instrumentation—then scaling into a VP-led function with data and governance capabilities.
- •Trigger problem: executives (even CEO) couldn’t see strategy-to-work alignment through Jira
- •Built portfolio-level roadmaps, OKR dashboards, and governance for consistent visibility
- •Created VP of Product Ops; added business/data insights support near director-level groups during instrumentation gaps
- •Parallel research ops improvements (participant database, research tooling, design system enablement)
- •Product ops persisted through restructures—seen as foundational by later leadership
- 1:09:33 – 1:19:31
Lightning round: recommendations, interview questions, tools, mottos, and wrap-up
They close with rapid-fire personal insights: books, shows, interview questions, favorite tools, and guiding mottos. The episode ends with where to find the book and how listeners can share their own product ops stories.
- •Book recs: Escaping the Build Trap, The Art of Action, Continuous Discovery Habits
- •Interview questions: changing your mind; learning from failure
- •Tools mentioned: Dragonboat, Dovetail, Vistaly
- •Mottos: “If you try to serve everybody, you serve no one” and “What’s the worst that can happen?”
- •Where to connect: productoperations.com, LinkedIn, and leaving reviews/sharing stories
