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:

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

Subscribe for updates

Subscribe for weekly advice covering product strategy, development operations, building teams and more.

Privacy and terms

I care about privacy as much as you do. I will only use your email address to send you this newsletter or to reach out to you directly, and you can unsubscribe at any time. I will not share, sell, or rent your email address to any third party, though I do store it the software I use to dispatch emails.

The information provided on this blog is for informational purposes only and should not be considered investment advice. The content on this blog is not a substitute for professional financial advice. The views and opinions expressed on this blog are solely those of the author and do not necessarily reflect the views of other organizations. The author makes no representations as to the accuracy, completeness, currentness, suitability, or validity of any information on this blog and will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its use. The author may hold positions in the companies or products discussed on this blog. Always conduct your own research and consult a financial advisor before making any investment decisions.