Great product companies operationalise their investments in development

Two belaboured topics in the product development community are the operationalisation of software costs (i.e., the SaaS-ification of everything) and the movement from project teams to product teams. I think what many product professionals miss is the deep connection between these two movements, and how this impacts the importance of the latter transformation for all SaaS companies.

Businesses have always required tools to get work done. Traditionally, these tools have been acquired up front, and used on an ongoing basis until the expiry of the tool (i.e., the tool breaks), after which an (often improved) replacement is procured. Farms buy ploughs, factories buy machinery, presses by a printing press. Since the early days of the software industry, many companies have bought software this same way. Businesses call this process of pre-purchasing equipment that will aid a project capital expenditure.

At first, it made sense for the software industry to mimic the existing business models employed by other tool manufacturers. But, today, this business model is increasingly rare for software businesses. This is because of the rise of Software as a Service, the model where software (and support services) is effectively rented on a monthly, quarterly, or annual basis. This is enabled by the low marginal costs that come with digital goods — because software developers do not need to pay anything upfront to “manufacture” their software for each new user, they do not need to charge their customers upfront. This dramatically lowers the barrier to entry for businesses that require software as they no longer need to invest a large chunk of capital upfront. Instead, they can license any required software, paying for what they use as they use it. This moves software licensing fees away from capital expenditure and towards operational expenditure (i.e., regular business-as-usual costs). In the industry, we’ve referred to this as the operationalisation of costs.

This is all very SaaS 101 and probably goes without saying for most people working within the software industry. What I find interesting, though, is that while most of the software industry has now adopted the SaaS model and operationalised their revenue (i.e., they receive regular, ongoing payments for their products, rather than one-off payments that require new products to be sold in order to get more revenue from existing customers), many have not operationalised their own costs in that they still allocate capital on a project-by-project basis.

Let’s dig deeper into this idea. So, we’ve established that as a software vendor, our customers can invest in tools either through capital expenditure (upfront purchasing of tools with a limited lifetime) or operational expenditure (regular business-as-usual costs). The same model applies to you as a software vendor: do build your product through capital expenditure (i.e., we will invest $450,000 into this project) or operational expenditure (i.e., we invest in this product on an ongoing basis, this cost line never goes away).

In the traditional model, investment of R&D was typically aligned with the sales model. In the same way that software products were sold as one-off sales to the customer, these products were invested in as projects. ROI was simply calculated by looking at how much we spent on ACME Software App Version 2, and how many customers bought it. Many SaaS companies still use this outdated model when it comes to product development. They imagine new revenue lines (e.g., a new product or feature) as projects to be prioritised and completed, after which the team can move on to the next product on the list. This model is flawed because it misaligns the incentives of the software vendor away from the best interests of their customers.

Before SaaS, products were completed before they were sold (this sounds like pointing out the obvious, but it really is very different to how software works today). Just like any tool in the physical world, when you bought software, you bought it in its current state, and it generally stayed pretty much the same from then onwards. In the world of SaaS, customers are repurchasing your product every single pay cycle. The same low costs of adoption that made it easy for you to sell your product to your customer without upfront capital expenditure also make it very easy for your customer to adopt a competitive product if it becomes more suitable. Therefore, it is critical for SaaS products to improve throughout the lifecycle of a customer (though the bar for how much a product may need to improve over time varies based on the maturity of the product and the market niche being addressed). In SaaS, you are technically reselling your product to every customer every month, quarter, or year. While automated billing turns this resale into a passive process on behalf of the customer, you should still think about renewals this way: you need to remain the most suitable product for the customers in your market niche on an ongoing basis.

The best way to achieve this ongoing success is to operationalise your investment in product development, aligning your costs with your revenues. Products are re-purchased every month, so they need to improve at that same pace. Instead of budgeting on a project-by-project basis, allocate ongoing resources towards products in your portfolio.

Practically, this looks like:

• Align teams to products instead of projects. Product teams are long-lived teams that have ownership over a product, rather than teams that bounce between products and projects.
• Any product with customers also needs developers. If your product has a customer, it needs development resources there to maintain and improve it. If you can’t justify this for a particular product, you should probably kill this product.
• Products are not projects. New products should not be built with a project mentality. They must be built with a product mentality. This means you need to spin up a new team, dedicated in the long-term to this new product. This may not be necessary for explorations and proof-of-concepts, but by the time you’re ready to get some customers, you need a team.
• Measure the success of your products over projects. It’s most valuable to establish long-term, product-wide success measures that all of your initiatives will work towards improving. Individual initiatives might have their own success or failure indicators, but these should be aligned to the success measures for your product. If these become difficult to align with your product, you may be working on the wrong things. Alternatively, you may be stumbling into a new product, for which you need a new team.

This transformation is much more difficult than the business model transition that most software companies have now completed. Operationalising software revenue has proven much easier than operationalising the investment of capital. But, for long-term success as a SaaS business, this needs to be done.

9 January, 2022