Product Operations versus Development
24 Mar 2022Note: this post is mostly about software or digital products , but the general principles apply in some way to all types of products.
Product Operations
Product operations–or “product ops”–has recently been used to describe the operationalizing of feedback between product, engineering and customer success[1]. I actually think this is, in essence, operationalizing the product management function, so would be better termed “product management ops.” Or, since it relies heavily on data, “product analytics.”
The way I use product operations here is: manual or semi-automated processes the team has to perform to deliver value to customers. All products have some operational component, and some products can be very operational. For instance, when a product is more like a service, or if a product is at an earlier, R&D stage. (The latter is common with AI and data products.)
DevOps, Technical Debt and Development
There is 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 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 (to include making product operations more efficient, if those affect the product experience).
On-Product versus Technical Debt Trade-off
One of the major tradeoffs product managers have to make is deciding between addressing technical debt and adding new features. The best approach I’ve come across for addressing this tradeoff is to agree up-front on an “on-product index”, that is a proportion of development time dedicated to improving the product.
And this index should 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 high as you focus almost entirely on building a product that is valuable enough for your customers to buy, as opposed to making what you’ve built more scalable.
“Do things that don’t scale” at the early stages, as Paul Graham has said. At later stage though, after finding product-market fit, your on-product index should be reduced as your company focuses on increasing scalability, reliability and maintainability.
Product = Revenue Independent of Time
For products with more of a product operations component, an additional tradeoff has to be made: how do we prioritize between product operations versus development, operating versus improving the product? 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 engineer time. Something that earns money while you sleep.
In this framing, the highest priority of an engineer team should be to automate product operations, so revenue can be independent of enginer time. Then secondly to engage in the technical debt tradeoff (which is slightly easier, since it doesn’t involve revenue).
If product operations are very high volume/ time-consuming, the team should probably hire a dedicated resource for product operations, treating that as an operating cost. The goal should then be to increase automation until those operating costs eventually get redirected towards product development.