Product Operations

Product operations is a relatively recent term (probably invented by marketers) which refers to a subfunction of product management that integrates and manages feedback collected from analytics and customer success to inform product development and strategy.

But there’s another meaning of the term “product operations” that I think is equally important for some products, which is manual or semi-automated processes the team has to perform to deliver value through a product.

Many products have some operational component and some products can be very operational. For instance, when a product is more like a service (“productionized service”), or if a product is in a less mature/ R&D stage. This is particularly common with AI and data products.

The point is that product vs service isn’t necessarily a binary, but a spectrum.

DevOps, Technical Debt and Development

There seems to be a correlative relationship between technical debt and operations performed by the engineering team: the more technical debt a product has, the greater the operational load. However, I wouldn’t consider these product operations but rather development operations (or “DevOps”), since these operations don’t directly support customers.

One specific example is if the dev team doesn’t yet have CI/CD set up and so code deployment is manual and cumbersome. This is technical debt that leads to operational load as part of development, but doesn’t impact product operations per se.

Product operations are strictly any manual processes that have to take place to fulfill a sale to a customer or satisfy a customer request.

Development work, on the other hand, is work done by the engineering team to improve a product offering, either by developing features, addressing technical debt or automating manual operations that support value delivery. The goal of technical debt work is to reduce development operations burden, while the goal of product improvement is to increase your product’s value to customers, which includes making product operations more efficient (when those exist and affect the product experience).

On-Product versus Technical Debt Trade-off

One of the major tradeoffs product managers have to make is addressing technical debt versus adding new features. The best approach to this I’ve come across is to agree up-front on an “on-product index”, which is a proportion of development time dedicated to improving the product.

And this index will vary based on your company’s stage of development.

For example, if your product is at an earlier stage of development (i.e. pre-product market fit), your on-product index should be as high as possible, to focus your team almost entirely on building a product that is valuable, as opposed to making what you’ve built so far more scalable. In the words of Paul Graham, “do things that don’t scale” at the early stages.

At later stage, after finding product-market fit, you can reduce on-product index (allowing a high percent of tech debt work) as your company starts to focus more on increasing scalability, reliability and maintainability.

Products = Revenue Independent of Time

For products with more of an operational component, an additional tradeoff that has to be made: how do we prioritize between operating versus improving the product (ie operations versus development)? Very similar to the technical debt tradeoff, except here operations directly support customers and revenue.

The ideal product has no product operational component.

What you want is a product’s revenue to be independent of time/ hourly labor.

Something that earns money while you sleep.

In this framing, one of the highest priorities of an engineering team should be to automate any operational aspects of a product, so revenue can become independent of time.

If product operations are very high volume/ time-consuming, the team should probably hire a dedicated resource for operating the product, treating that as an operating cost. The goal should then be to increase automation until those operating costs eventually can be redirected towards product development.