TBM 45/52: What is ProductOps?
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.
What do these problems look like? It varies between companies (which makes defining ProductOps hard). Some recent examples from companies I have spoken with:
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.
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.
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.
Completely agree that this should be cross-functionally supporting and the work essentially being product management of the internal workings by focusing on the customers.
I discussed realities of this with a number of peers in the field as part of MBA research into considering whether to implement at my current org. which has an Integrated Product Team concept). The realities seemingly push against this working method as there remains a functional hierarchy. Having a group within the product structure that are looking to engage and understand whats really going on invokes defense mechanisms within the other functions making getting to the real crux of the problems difficult. In some cases the engagements can be combative and not collaborative. I conclude that if you consider the Product Ops function the first tasks in initiating needs to be analysis of the culture as if such barriers exist changing those dynamics will be key to any successes. Indeed, I have completed said analysis at my org. and am about to embark on my first experiment to gauge how viable Product Ops really is.
I also have a point on your summary "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)". It's a great way to put it. I have seem many remits focusing on "making things easier", but some org. goals will require times of sacrifice (as you put it), so adding that 'thoughtfuly' notion in there speaks volumes - to me at least.
This is great and I agree that Product Ops' key "customer" is the product management team, and, done effectively, Product Ops creates leverage (like any other platform team). I would have loved to have seen more examples. Or is there a list of common functions that Product Ops typically performs?