Great product companies operationalise their investments in development

Today, we pay for almost all B2B software on a monthly or annual subscription. The subscription software model has revolutionised how software customers budget and pay for software costs but hasn’t transformed the ways of working for software vendors as much as it should.

Businesses have always required tools to operate. You buy a device, use it, and replace it when it breaks. Farms buy ploughs, factories purchase machinery, and newspapers buy a printing press. In the early days of the software industry, companies bought software this way. If you needed Excel, you purchased the latest version and used it until you had a good reason to buy a more recent version or competitive alternative. Businesses call this process of purchasing equipment upfront capital expenditure because the total cost is immediate, even if you receive value from the device over time.

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 you rent software (and support services) monthly, quarterly, or annually. Low marginal costs that come with digital goods enable this model. 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. The subscription model 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, moving 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 software costs.

This is all very SaaS 101 and probably goes without saying for most people working within the software industry. But while most of the software industry has now adopted the SaaS model and operationalised their revenue, many are yet to operationalise their investments in that they still effectively 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 you build your product through capital expenditure (e.g., we will invest $450,000 into this project) or operational expenditure (e.g., we invest in this product on an ongoing basis, this cost line never goes away).

In the traditional model, software companies aligned R&D investments with their sales model. We sold software products as one-off sales to the customer and built products in the same way. We calculated ROI by examining how much we spent on ACME Software App Version 2, and how many customers bought it. Many SaaS companies still use this outdated model for product development. They imagine new revenue lines (e.g., a new product or feature) as discrete, short-term projects with their own measures of ROI. This model is flawed because it misaligns the software vendor’s incentives away from their customers’ best interests.

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 repurchase 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 you address). In SaaS, you technically resell 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. Customers repurchase your products every month, so your products must 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 own 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 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. Don’t build new products with a project mentality. To build a new product, you need to spin up a team dedicated in the long term to this new product. This may not be necessary for explorations and proofs-of-concept, but you need a team when you’re ready to get some customers.
• 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 align with 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 complicated than the business model transition that most software companies have now completed. Operationalising software revenue has proven much more accessible than operationalising capital investment. However, it’s essential for long-term success as a SaaS business.