Product Operations

Review

There was no definitive account of Product Operations before this book. It existed as a scattering of blog posts and job descriptions, everyone borrowing the term to mean something slightly different. Perri and Tilles finally give the discipline a stake in the ground, something concrete enough to reference or push back on.

It is not a riveting read, and it is not going to join the Product Management canon. But it is the book the community needed. I am grateful for a thorough, thoughtful account of a role that badly needed one.

Key Takeaways

The parts worth keeping:

• Product Operations exists to help a product management function scale: surrounding teams with the inputs they need to set strategy, prioritize, and streamline how they work. It is an enablement function, not a decision-making one.
• Three pillars: Business and Data Insights (collecting and contextualizing internal product analytics so leaders can track outcomes and ROI), Customer and Market Insights (aggregating external research and making it accessible instead of siloed), and Process and Practices (the operating model: how strategy gets made, how cross-functional teams collaborate, how governance and tooling work).
• You do not need all three pillars at once. Start with whichever pain point is biggest for your organization right now.
• Multi-product companies tend to fracture into mini-kingdoms, each team hoarding its own information and process. Product Ops exists to break down exactly that kind of silo.
• On the data side: build a habit of understanding what questions the strategy needs answered, tracking down where that data actually lives, and automating a dashboard instead of re-pulling numbers by hand every time. Revenue and cost should be visible in product-centric terms, not just finance-centric ones.
• On the research side: democratize access to it. Friction in booking interviews is often what stops product managers from talking to customers at all. A research repository that people are expected to check before commissioning new research prevents the same study getting run five times.
• On process: do not standardize everything, that overwhelms teams. Standardize the things that cross team boundaries, idea management, roadmapping formats, onboarding, and treat roadmaps as a communication tool shaped by what the audience actually needs to know, not as an internal planning artifact.
• Governance and annual planning are not about process for its own sake. They are about setting a cadence for the conversations that keep a company responsive: designing the rhythm of inputs and decisions, generating urgency around aligning initiatives, and giving every meeting a clearly defined outcome instead of a vague agenda.

Starting a Product Ops function

• Start small. Run it in one team first, find the actual pain points, iterate before you try to scale it.
• Find and work with the promoters, people already excited by the vision, rather than trying to convince skeptics first.
• Say no. Be explicit about what you can and cannot take on with your current bandwidth.
• Secure executive support early, and think about the intersection of what Product Ops can realistically do and what is most strategically important to the company right now.
• Get to visible impact quickly. In a small team, you set the standard through the problems you solve, not through a mission statement.
• The recurring tension throughout the book: PMs sometimes worry Product Ops will take over their decisions. It doesn't. The team enables decisions, it doesn't make them. Balancing process with agility is the whole job.

The Product Ops tool stack

The book maps common tooling categories against what each one is actually for, which is a more useful way to evaluate a tool than by brand name alone:

The book's own warning is worth repeating: teams can lean on tooling as a substitute for actually solving the underlying process problem. Buying the tool is the easy part.