Product Ops Is the Operating System Your Product Team Is Missing

Melissa Perri says product operations has been booming, especially after originating in large tech companies such as Uber. Blake Samic, who started product ops at Uber and later did it at Stripe and OpenAI, is a case study in the book. Melissa had mentioned product operations in Escaping the Build Trap in 2018 after doing it at Athenahealth, where there were 365 product teams.

The adoption data is rough but telling. Melissa says that in her CPO accelerator cohorts of 20 to 25 people, at least half have somebody doing something product-ops-related. Denise Tilles adds that when Produx Labs began offering its product operations masterclass in 2020, about 60% of participants were product curious; now about 60% already have product ops and want to optimize it. Melissa points to Pendo's conversations around 2019 and Blake's advocacy as signs of the inflection.

The core benefit is focus. Denise says many PMs spend 20% to 30% of their time harvesting data and doing implementation work just to get inputs, and product ops helps them concentrate on the strategic work they were hired for. Melissa describes learning MongoDB at OpenSky so she could measure features without bothering engineers, and argues that product ops should remove that kind of busywork rather than take away decision rights.

Melissa and Denise organize product ops around three pillars: business and data insights, customer and market insights, and process and practices. The first is quantitative, giving PMs engagement and revenue inputs; the second is qualitative, helping teams hear from customers and markets; the third is about how product work gets done. The right pillar to start with depends on the company's biggest constraint.

High-growth companies usually start with business and data insights so they can monitor what is happening and make faster strategic decisions. Larger enterprises, especially those going through transformations, often start with process and governance because they lack a product operating model. Melissa gives the example of portfolio roadmaps: Jira does not give a CPO or VP of product the roll-up transparency they need, so product ops may introduce tooling and cadences that connect teams to strategy.

Customer and market insights are the squishier middle, and Denise says people rarely associate product ops with that work at first. In practice, product ops can build a findings database using a tool like Dovetail or a homegrown system, assemble an opt-in participant database for alphas and betas, and make existing research queryable so teams do not duplicate it. It can also gather qualitative signal from sales, support tickets, and Google docs, then communicate back to those teams how their feedback is being used.

Melissa argues that product management was squishy for a long time but is now being standardized, even as product managers become more critical to software-driven businesses. As companies scale and add systems, PMs cannot keep doing data pulls, research logistics, and process work off the side of their desks. The choice is whether to hire more PMs to absorb that work or build shared product ops infrastructure so PMs can spend most of their time on strategy.

Denise compares the situation to companies that avoid hiring PMs by giving the role to engineers or designers. That can work only if those people want to run meetings, write strategy docs, take notes, and handle the context switching that product management requires. Melissa adds that product leaders also get pulled into template decisions, training, and firefighting, and product ops can take on the rollout and maintenance of those shared systems.

The boundary is clear: product ops should not take decision rights. Denise says PMs keep strategy, vision, prioritization, resource allocation, trade-off decisions, hard stakeholder conversations, and responsibility for outcomes. Product ops may help find customers or aggregate information, but the PM still does the research and decides what to build; product ops is not a project manager monitoring developers or a substitute for product judgment.

Go-to-market is another area where product ops can help without owning the product decision. Denise says product ops can connect sales and product, create standard templates, run the coordination cadence, and reduce silos. The PM still supplies GTM inputs, talks to salespeople, and works with marketing on positioning, while product ops handles the program management and consistency around that work.

For the business and data insights pillar, product ops connects existing data science or BI teams to product questions rather than reinventing the analytics function. Denise says the work includes pulling data, generating charts and graphs, and making recommendations that PMs can act on. Melissa adds that the role is not a database engineer: it is about getting information out of SQL tables and making sense of it, sometimes with a direct line to finance so PMs are not all asking the CFO for the same revenue number.

The executive use case is especially powerful. Melissa says board meetings often review ARR, retention, and net retention, but product ops can show ARR by customer segment, ARR by product line, retention by feature set, or adoption by segment and product. Those cuts turn general business health metrics into strategic product insight, and product ops can build repeatable dashboards and surface trends leaders did not know to ask for.

This does not let PMs off the hook on data literacy. Melissa says PMs still need to read charts, understand trends, distinguish causation from correlation, and recognize when a marketing launch explains a signup spike. Product ops can put recurring reports and board inputs into dashboards so PMs are not pulling the same data ad hoc every time; Brian Bhuta, chief product officer at Forsta, described product ops as preventing board-meeting data from becoming obsolete before the meeting ends.

The hosts raise Casey Winters's view that operations roles can signal inefficiency that software should eventually remove. Denise responds that product ops should be the group looking for ways to optimize and streamline with software, tools, processes, and frameworks, not a reason to hire 10,000 product ops people. In the shared-services model, a lean team builds products and systems for the product team and keeps them relevant.

Melissa and Denise do not offer a hard ratio, but they offer warnings. A one-to-one ratio of product ops people to PMs is wrong, and a one-to-hundred ratio is also wrong. A hybrid model may be a stopgap when data is poorly instrumented, such as placing a business data and insights person with every director or VP of product, but well-instrumented companies need far fewer people because PMs can pull ad hoc reports themselves.

The three pillars require different profiles. The business data and insights person usually is not a product expert and may not come from product management, while the process and practices person needs product background to coach roadmaps, define systems, and communicate with executives. Melissa warns that agile coaches without product management experience may optimize for Scrum instead of helping cross-functional roadmap reviews, decision-making, and the right level of executive communication; customer and market insights often need a user research or research ops background.

Denise cites Shintaro Matsui's product ops rollout at Amplitude as a case study in building momentum. His top tip was to run a listening tour and research sprints rather than assume the biggest perceived need is the right first target. The first product ops person should find where they can make the most difference quickly, celebrate those wins, and communicate what is above and below the line for a team of one.

On hiring, Melissa says getting someone who has done product ops before is ideal, but it is not the only path. If the company is not ready to invest fully, it can pull someone from another function and use them to demonstrate value; if a CPO has budget and buy-in, hiring an experienced VP or director of product ops can let that leader build the team. The first hire matters because failure can taint the whole function, so leaders must decide whether they have time to coach someone into the role.

For the business and data pillar, Melissa looks for someone who can interpret data, tell stories with it, and communicate with stakeholders, not a database engineer. Consultant backgrounds and BI-tool experience with Looker or Tableau are valuable, especially combined with Excel and PowerPoint fluency. For process and practices, she wants high EQ, systems thinking, and the judgment to introduce methods as suggestions rather than mandates, while customer and market insights benefit from user research and research ops experience such as Jen Cardello's work at Fidelity.

Product ops should generally report to the head of product or CPO, and Melissa describes the role as the CPO's right-hand person for data, board preparation, and strategy operationalization. If the CPO has no time to train someone, they should hire experience; if the burning issue is data, they may hire a data analyst and teach that person the product cuts they need. The speed of rollout and the amount of available coaching should drive the hiring choice.

Melissa's Athenahealth case study began with more than 360 product managers, 5,000 software developers, and an $8 billion electronic health record platform. The company had just introduced formal product management, so she helped train PMs and saw maturity improve, but then the organization hit problems that training alone could not solve. There were also far too many PMs, with one person reporting into one person all the way down, and many people self-selected out of product management after training; product ops was not a substitute for product skills but a way to help skilled PMs and leaders do their jobs better.

The first fires were executive visibility and strategy alignment. The CEO was digging around in Jira trying to understand what teams were working on, but with hundreds of thousands of tickets that was not workable. Athenahealth needed a portfolio roadmap tied to strategic goals, visibility into R&D allocation for an upmarket move into hospitals, training on writing meaningful epics, portfolio software to roll information up, and dashboards to track deployed OKRs.

Data and insights were another major gap, especially as Athenahealth began rolling out Amplitude inconsistently. The company created a VP of product operations role, filled by someone from product management who was process-oriented and understood product well enough to build systems. Reporting into that leader was a business data and insights team overseeing the Amplitude rollout, with embedded analysts at the director level to support five to eight Scrum teams while shared services and governance sat at the top; research ops lived under UX and collaborated closely.

Athenahealth later restructured and many leaders left, but the product ops team survived. Tim Davenport, formerly chief of staff to the CPO, continued building the function and became a case study in the book; Melissa says the current CPO has said he will never go anywhere else that does not have product ops. The VP of product ops managed data analysts, some of whom moved out of PM roles because they preferred data work over stakeholder-heavy product work, and they collaborated with the CTO-side data team on instrumentation and analytics.

In the lightning round, Melissa recommends Escaping the Build Trap, Traffic by Ben Smith, and The Art of Action as a sleeper hit on strategy deployment. Denise recommends Theresa Torres's Continuous Discovery Habits and Traffic, which covers the rise of HuffPo and Gawker. The strategy recommendation fits the episode's theme: product ops is partly about seeing where strategy is well deployed and where gaps need to be filled.

For recent television, Denise recommends Deutschland 82, 86, 89 on Hulu, a series about East Germany. Melissa recommends House of Usher on Netflix, noting that it fit the Halloween season. The recommendations are brief and personal, closing the conversation after the substantive product ops discussion.