Tim Farrell     health + engineering

Product Operations versus Development

Note: 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 “operationalization” of the feedback loop 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’m using product operations here is: manual or semi-automated processes the team has to perform to directly serve customers, as part of value delivery. For some products, the operational component is larger than others. Say, when the product is more like a service, or if the product is a technical product at an earlier/ less mature/ R&D stage (like with early stage AI or data products).

DevOps, Technical Debt and Development

There is a correlation/ relationship between technical debt and operations (i.e. manual processes) performed by the engineering team: the more technical debt a product has, the larger the operational component. 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 development team doesn’t yet have CI/CD set up and so the code deployment process is manual and cumbersome: this is technical debt that leads to increased operational load on the engineering team, as part of development, but shouldn’t impact product operations per se. Product operations are more like operations where manual processes have to take place in order to fulfill a customer request, like in a customer service scenario.

Development work then is work done by the engineering team to improve the product, either by improving product features, by addressing technical debt or by automating manual operations that support the product’s value delivery. The goal of technical debt work is to reduce development operations burden; while the goal of product improvement work, sometimes called “on-product” work, is to increase your product’s value for customers (to include also automating/ streamlining product operations).

On-Product versus Technical Debt Trade-off

One of the major tradeoffs that product managers/ owners have to make is deciding between addressing technical debt and adding new features (“on-product” work).

The best approach I’ve come across for thinking about this tradeoff is to agree up-front with the team on an “on-product index”, that is a proportion of tickets (or development time) that will be 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 early stage of development (i.e. pre-product market fit), you want a high on-product index because you should be focused entirely on learning what your customers actually want, as opposed to trying to make the product more scalable (i.e. reducing technical debt). Once the product is at a later stage, then the on-product index should probably be reduced as you focus on making your product more scalable, sustainable and easily maintainable.

Product = Revenue Independent of Time

For products with more of a product operational component, an additonal tradeoff has to be made is: how do we prioritize between product operations versus development (i.e. operating vs improving the product)? Very similar to the technical debt tradeoff, except here operations are directly supporting customers and potential revenue (if the company is at that stage).

The ideal product actually has no product operational component (i.e. is completely automated), since what you want is a product’s revenue to be independent of time. This is what it means for a product to be truly scalable.

In this framing, the highest priority of the development team should firstly be to automate product operations, so that product revenue can be independent of time, and then secondly to engage in the technical debt tradeoff (which is actually a slightly easier tradeoff to make, since it doesn’t directly involve revenue).

If product operations are so high volume/ time-consuming, the team should probably hire a dedicated resource for product operations (who doesn’t necessarily have to be an engineer per se, although that would be ideal scenario if possible), treating that as a product operating cost. The goal then should be to eventually redirect those operating costs towards development and product improvements as the level of automation increases.