Back

What product operations (product ops) actually does

Picture a company with twelve product managers. On Monday, three of them ask the data team the same question in three different Slack threads. Two of them are running customer interviews with the same customer, a week apart, and the customer has started to notice. Every team plans in its own format, so the quarterly roadmap review is mostly people translating spreadsheets for each other.

Nobody did anything wrong. Twelve reasonable people each built a reasonable process, and the company ended up with twelve processes.

Eventually somebody gets asked to fix it. More and more often, that person’s title is product operations.

Product ops is the function that helps product management scale

In 2023, Melissa Perri and Denise Tilles published Product Operations, a book-length attempt to define the job. Their definition is the one to start from: product ops is the discipline of helping your product management function scale well, by surrounding teams with the inputs they need to set strategy, prioritize, and work efficiently.

The important word is scale. With two PMs, nobody needs product ops. The PMs just talk. Somewhere past that, the cost of every team reinventing the same research and the same metrics starts to exceed the cost of one person owning them.

Perri and Tilles organize the work into three pillars.

Data and insights

Making sure product teams can get the numbers they need without filing a ticket and waiting. Mostly that means metric definitions everyone agrees on, and dashboards people trust enough to stop rebuilding.

Customer and market insights

Making research and feedback reusable. Recruiting interview participants, keeping a library of what’s already been learned, and routing feedback from sales and support to the team that can act on it. (Also making sure two teams don’t interview the same customer a week apart.)

Process and governance

Deciding which rituals are shared across teams, like the roadmap format and the launch checklist, and which ones each team gets to choose. Good governance makes the right way the easy way. It rarely adds an approval step.

The book profiles companies that built the function, including Stripe, Uber, athenahealth, Oscar Health, and Fidelity.

Product ops is not the process police

The failure mode is easy to predict. A product ops team that measures itself by how many templates it publishes will publish a lot of templates. PMs will fill them in grudgingly, and the templates will describe the work rather than improve it.

The test I’d use is simple. After product ops touches something, does a product manager spend less time on it? A shared metrics dashboard passes. A mandatory 14-field intake form usually doesn’t. If PMs start routing around product ops, it has become a layer they report to, and the function has failed at the one thing it was for.

The other failure mode is the opposite: product ops as the place where every job nobody else wants ends up. That’s an assistant with a better title. It won’t make the function scale, because the function hasn’t changed.

What a product operations manager does

A product ops manager’s responsibilities usually include:

  1. Strategic alignment. Working with product leadership so that roadmaps across teams ladder up to the company’s goals, in a format leadership can actually compare.
  2. Process improvement. Finding the bottlenecks in how teams plan and ship, and removing them. Sometimes that’s a new tool. More often it’s removing a step.
  3. Data and analysis. Owning the definitions and tooling for product usage data, so PMs can answer their own questions.
  4. Customer feedback management. Collecting feedback from every channel, organizing it, and getting it to the team that owns the problem.
  5. Launch coordination. Making sure sales, marketing, support, and engineering are ready on launch day, with the same understanding of what’s launching.

Much of the job is translation. A product ops manager sits between product and every team that depends on it, and most of what they do is make sure all of those groups are working from the same picture.

A day in the life of a product ops manager

No two days look the same, but a typical one might run like this.

  • Morning check-in. A short sync with the product ops team on priorities and anything that broke overnight.
  • Roadmap alignment. A meeting with product managers about roadmap changes, and possibly a follow-up with sales or customer success about what those changes mean for customers.
  • Data work. Looking at usage trends, fixing a dashboard that two teams read differently, or answering the question three PMs asked on Monday, once.
  • Feedback triage. Reviewing what came in from support and sales, then routing the patterns to the teams that own them.
  • Lunch. The only meeting of the day without an agenda.
  • Process work. Looking at where planning or delivery is slow and trying one change.
  • Launch prep. If a launch is coming, checking that every team knows its part.
  • Wrap-up. Closing loops and writing down what’s still open.

The mix changes with company size and product stage. Early on it’s mostly data and feedback. At larger companies, process and governance take over more of the week.

Where CardBoard fits

Process and governance is the pillar where tools matter most, because the process lives in the tools. If every team plans in a different format, product ops spends its week translating.

CardBoard gives teams a shared planning surface that stays connected to the tracker. A user story map lays out the work across the user’s steps, cut into release slices. Cards on it can link to Jira or Azure DevOps, and linked cards mirror the tracker’s title, status, description, acceptance criteria, parent, and assignee, with edits flowing both ways. Product ops gets one picture of what’s planned without asking anyone to update a spreadsheet by hand.

It also has the retrospective boards process improvement runs on: 4Ls, sailboat, and start, stop, continue. When a process change is working, the retro is usually where you hear about it first.

A CardBoard story map called Weeknight recipes: five blue activities across the top (Find a recipe, Plan the week, Shop, Cook, Come back tomorrow) and three named release slices below. The Release 1 cards are linked to Jira and show DONE, IN PROGRESS, and TO DO status pills. Two cards carry three reactions each.
Release 1 reads its status straight from Jira. Nobody updated a spreadsheet to make this screenshot.

Learn more about product operations

Books

  1. Product Operations by Melissa Perri and Denise Tilles
  2. Escaping the Build Trap by Melissa Perri
  3. Inspired by Marty Cagan
  4. The Lean Product Playbook by Dan Olsen
  5. Product Leadership by Richard Banfield, Martin Eriksson, and Nate Walkingshaw
  6. The Lean Startup by Eric Ries

Courses

  1. Become a Product Manager on Coursera
  2. Product Strategy on Coursera
  3. Product management courses on edX
  4. Product Management: Building a Product Roadmap on LinkedIn Learning

Websites

  1. Mind the Product
  2. Product Coalition
  3. Product Talk
  4. Product School blog

Certifications

  1. Certified Product Manager from AIPMM
  2. Product Management Certification from Product School
  3. Agile Certified Product Manager and Product Owner from 280 Group

Communities

  1. ProductCamp (regional unconferences)
  2. ProductTank
  3. Product Management Festival
  4. Women in Product

If you know a product ops resource that belongs on this list, tell us on LinkedIn.

For the measurement side of the job, see how to pick product metrics. For the research side, customer discovery.