TBM 45/52: What is ProductOps?

Credit: Rome Sentinel

I have a simple definition of ProductOps.

ProductOps solves problems for product teams that single teams and individuals cannot solve.

In this sense, ProductOps is an internal platform product. It is about collective leverage. Like any product, it requires product management and strategy. It also involves a lot of systems thinking, service design, operation’s chops, learning design, and experience shepherding change experiments.

Above all, like any product, it has CUSTOMERS. A big red flag is when the primary ProductOps customer is not cross-functional product teams. Why? If you’re not focusing on helping teams be the best they can be (to help your customers), who are you focusing on helping? If you become the process police, who is that helping? ProductOps is not PMO rebranded.

Examples

What do these problems look like? It varies between companies (which makes defining ProductOps hard). Some recent examples from companies I have spoken with:

Telemetry

The teams agree that a consistent naming convention for tracked events would be valuable. But the reality is that no one needs consistently named events to do their day-to-day work. Yes, it makes occasional questions hard to answer, but it isn’t the end of the world. It only becomes a big issue once you attempt to understand how customers use the whole product. 

Challenge: Help people instrument events with a consistent naming convention WITHOUT infringing on autonomy, limiting what gets instrumented, requiring tracking spreadsheets, working outside normal tools, slowing teams down, adding process hoops, etc.

Strategy

The teams agree that they want context from the c-suite when forming their strategies and an opportunity to provide structured feedback (and even pushback) before the strategy is finalized. The c-suite agrees as well. But you know how calendars are. And you know how busy the CPO is and how tough it is to run these meetings well. No team can make this happen, yet a company can muddle through if forced.

Challenge: Enable the bidirectional sharing of strategic context and empower teams to provide meaningful feedback and critique WITHOUT pitch theater, premature convergence, dull strategies, killing creativity, non-interactive meetings, no agendas, no pre-reads, etc.

Schedule Customer Calls

The teams all want to talk to customers. They agree that it would be harmful to overload specific customers with interview requests. They also agree that drawing from the same pool of vocal customers would be bad for product decisions. But, when push comes to shove, the easiest thing to do is look at some analytics, find a customer, and email them. 

Challenge: Help teams do the best customer research possible WITHOUT overburdening individual customers, limiting research options, reducing the amount of research, long waiting times, long delays for confirmation, manual scheduling, and non-representative customers.

In a startup, none of these problems would require any additional help. But as a company scales, the scope of the operational challenge grows, and it becomes harder for one team (or person) to fix the problem even if they want to.

Note: When reviewing this piece, it struck me that each of the functions above could fall under another group (e.g., telemetry to DX). But I somehow was not surprised that in context they fell to ProductOps.

Without…

This definition also surfaces a critical point. Like any product, your goal is to make people’s lives easier, not harder! You’ll notice the “without” caveat with each point above. Yes, sometimes individual teams need to make a small sacrifice for the benefit of the team of teams. That’s OK, and with the right messaging and visibility, you’ll hopefully get buy-in. 

But many ProductOps teams fail to consider all the risks and damaging 2nd/3rd order effects. They launch big-bang change efforts without discovery, experimentation, looking out for negative impacts, and pivoting based on feedback. They forget their customers and their needs. Things implode.

This is why people with operations experience in different domains sometimes go wrong when they try ProductOps. What works in manufacturing, finance, or X, may not work in product. The paradigm is different. The motion is different.

ProductOps is a strategic function. Your product involves helping humans do their job in a messy socio-technical system. There are plenty of ways to mess things up. And plenty of ways to get reactive about short-term fires and lose the forest through the trees.

So to return to the definition:

ProductOps solves problems for product teams that single teams and individuals cannot solve (and does so thoughtfully, keeping the long-term health and goals of the teams and organization as a top priority).

ProductOps varies a great deal between organizations because those problems vary. And that is what makes it fun and rewarding.