What product operations is and how to build it at your company

Executive overview

Product managers increasingly spend 20–30% of their time on data wrangling, scheduling research, and administrative coordination — work that doesn't produce product decisions. Product operations (product ops) is the function that absorbs that work, freeing PMs to focus on strategy, customers, and outcomes.

The role is organised around three pillars: business and data insights (quantitative), customer and market insights (qualitative), and process and practices (how product teams operate). Product ops does not take decision-making from PMs — it equips them to make better decisions faster.

The core insight: product ops doesn't replace PM judgment — it removes the operational overhead that prevents PMs from exercising it.

The three pillars of product ops

• Business and data insights — connecting PMs and leaders to product-level metrics (adoption by segment, retention by feature) rather than company-level metrics alone
• Customer and market insights — building participant databases, centralising research findings, enabling PMs and researchers to access and share qualitative data without duplicating effort
• Process and practices — standardising roadmap templates, review cadences, go-to-market coordination, and executive-level reporting

What product ops does not do

• Make product decisions or tell PMs what to build
• Manage developers or ensure delivery timelines (that is project management, not product ops)
• Handle hard stakeholder conversations or trade-off decisions — those stay with the PM
• Replace the PM's ownership of strategy, vision, prioritisation, and go-to-market inputs

When each pillar matters most

• High-growth startups typically start with business and data insights — getting fast access to product metrics to inform strategy
• Enterprises undergoing digital transformation often start with process and practices — establishing a shared operating model across large PM teams
• Customer and market insights is the "squishy middle" — often underestimated, but high value once teams start duplicating research or losing qualitative data in siloed systems

How product ops relates to adjacent roles

• Project manager — time-boxed, delivery-focused; product ops is ongoing and enablement-focused
• Program manager — runs large cross-functional initiatives; overlaps with product ops on go-to-market coordination but is distinct
• Agile coach — optimises sprint ceremonies; product ops focuses on product management processes, not development rituals
• User researcher — does the research; product ops operationalises access, tooling, and participant recruitment so researchers can work faster
• Data analyst / BI team — owns the data infrastructure; product ops applies a product lens to extract decision-relevant insights from it

Who product ops should hire for each pillar

Business and data insights

• Consultant or analyst background — strong at telling stories with data, comfortable with BI tools (Looker, Tableau)
• Does not need a product background; you steer the questions, they pull the answers
• Not a database engineer — the job is interpreting data, not building pipelines

Customer and market insights

• User research or research ops background
• Operationally minded — builds systems, not just runs studies
• Look for research ops practitioners; Dovetail is an example of tooling this person would own

Process and practices

• Must have a product management background — they coach PMs, roll out operating models, and facilitate cross-functional reviews
• High EQ; understands how to introduce process without mandating it
• Avoid pure agile coaches without PM experience — they default to sprint mechanics, not product operating models

How to roll out product ops

• Start with one person; identify the single highest-leverage pillar for your company right now
• Run a listening tour before assuming what the biggest need is — the most visible pain is not always the highest leverage
• Show quick wins early; then make the gap visible ("here's what one person can do; here's what we'd unlock with a second hire")
• Hire experience if you have no time to coach; hire potential if a leader can provide close guidance
• People with PM titles who've been doing operational work are often strong candidates — the product ops title is new but the work is not
• Product ops reports to the head of product, ideally as a right-hand hire for the CPO at growth-stage companies

Staffing ratios and team shape

• One-to-one (one product ops per PM) is too many; one-to-hundred is too few
• Well-instrumented data reduces the headcount needed in the data insights pillar — PMs can self-serve more
• Hybrid models (embedded ops people per product area) are often a temporary fix while data instrumentation catches up; shared services is the target state
• The team should stay lean; the goal is programs and tools that run themselves, not a large ops org

Case study: Athena Health

• 360+ product managers, 5,000 developers; product management was newly formalised when the work began
• First need discovered: executives had no visibility into what teams were building or how roadmaps tied to strategy — the CEO was manually digging through Jira
• Solution: trained PMs to write substantive epics; found portfolio tooling to roll them up; built OKR dashboards for executive visibility
• Second need: Amplitude was being rolled out inconsistently — individual product teams couldn't extract useful data
• Hired a VP of product operations (moved from a PM role) who oversaw embedded data analysts at the director level and the portfolio governance work
• Research ops (led separately under the head of UX) built a participant database, design systems library, and user research toolkit
• After multiple restructurings and a take-private, the product ops function survived — the CPO stated he would not join any company that lacked it

Skills to look for across all product ops roles

• Builds systems rather than solving problems one-off
• Strong interview question: "Tell me about something you hated doing that you eventually automated or systematised — what did you build?"
• Comfortable communicating with many stakeholder types (executives, engineers, sales, PMs)
• Constantly re-evaluates whether processes and tools are still fit for purpose — not a set-it-and-forget-it mindset