Quantum leap into the Business of Cloud Services
The challenges Software Vendors face adopting the Service Delivery model in the post COVID-19 world
The world is moving from a pay-to-own revenue model to a pay-for-use model. As every product is transformed into a service, software is no longer to be installed but to be subscribed to. Revenue is no longer generated when the product hits the market place, but when the customer finds value in its use. This new normal requires traditional software vendors to transform not only their product, but also their business model and their organization structure. Adopting the service model as the main revenue stream is not merely a strategy to survive, it is a quantum leap into a whole new universe.
If you have paid attention the last couple of years and even more the last couple of months, you know that the world is, gradually, embracing a new business model.
A business model where you ‘pay-for-use’. No longer paying for a product, but for using it. We no longer own or even lease a product, instead we merely use it. We pay for meeting the goal, not for owning the means to reach it.
This change in business model, this change in business sustainability is revolutionary and results from the alignment of business adoption and consumer acceptance of a service-based market. This change follows a global transformation from a product development model into a service delivery model. From a pay-to-own to a pay-for-use mindset with customers.
Utility companies obviously pioneered the model where we pay for what we use. The psychological aspects are evident. When you consume a shared resource, it is only fair when you are billed solely for your consumption. Especially when the goods are abstract like ‘utilities’, consumers are more inclined to prefer the pay-per-use model over a flat-rates model. The latter often viewed with skepticism: ”Is this vendor ripping me off?”.
Also read the companion story on how to effectively succeed in an online marketplace. Think Like a Designer
From Product to Service
After the internet-bubble burst in the late 1990s early 2000s a new computing model rose, Application Service Providers (ASP) provided access to applications hosted and maintained by the ASP. Customers no longer had to pay for the software license, instead they paid for the right of accessing those applications. Software licenses turned into user licenses.
In 2006 Amazon launched its first cloud service, Amazon Simple Storage Solution (S3). With the service Amazon introduced the pay-as-you-go model. Customers of Amazon S3 paid for storage they were consuming. Over time Amazon introduced more services following the same business model. At the same time companies like Google, Microsoft, IBM and several more followed suit, introducing their own cloud offerings.
These Cloud companies follow the NIST definition of ‘The Cloud’ and provide Infrastructure as a Service (IaaS) and Platforms as a Service (PaaS). NIST published its definition of Cloud Computing in 2011.
The NIST Definition of Cloud Computing
The .gov means it's official. Federal government websites often end in .gov or .mil. Before sharing sensitive…
In its publication NIST defines not only what the cloud is but also the three service models IaaS, PaaS and Software as a Service (SaaS). The cloud provider typically provides IaaS and PaaS and third parties deliver SaaS on top of these services.
SaaS can be considered as the ASP model utilizing the essential characteristics of the cloud as per NIST (On-demand self-service, Broad network access, Resource pooling, Rapid elasticity, Measured service). Building on these characteristics, SaaS offerings are typically following the pay-as-you-go business model. Customers do not pay for the right to own the software (software license model), nor the right to use the software (user license model), instead they pay for the actual use of (parts of) the software.
From ISV to SaaS provider
This change in the value proposition of software products requires the Independent Software Vendor (ISV) to transform into a service provider. The vendor’s responsibility expands from ‘delivering a reliable product’ to ‘delivering a consistent reliable service to the customer’.
For companies making this transition from product to service are faced with the complexities of IT Operations which becomes part of their operational model. Organizations that excelled in software engineering are now confronted with the need to also excel in operations engineering, which is a whole different ballgame. Think of it as a marathon runner competing at the Winter Olympics biathlon and never have seen a rifle before in their life.
The responsibilities of these companies with respect to their relationship with their customers have drastically changed. But this is not the only change that these vendors face. One that is possibly even more encompassing is the change in business model.
The ISV’s business model is based on the traditional model based around product delivery. A product is developed, written to DVD, or made available for download and brought to market as a product that the customer can own. The business model is based around the paradigm that money is made when the product enters the market, or even before that moment. As the ISV turns into a SaaS provider, product delivery turns into service delivery where money is made when the service is used. Consequently, money is made only after the product enters the market, or rather when its features can be accessed by the market.
The key difference between both models is that in the product delivery model, revenue is based around the concept of ‘time-to-market’ whereas in the service delivery model, revenue is based around the concept of ‘time-in-market’.
You can share how you like this article by clicking the little applauding hands up to 50 times.
Ever since I started to develop software and got paid for it, time-to-market has been a key performance indicator (KPI). This was in 1991, still a student I had my first project as a freelance software engineer. Delivering the application on time was critical to get paid. I missed my deadline, several times, and consequently I did not get paid. Tough lesson learned.
Time-to-market is a typical product delivery KPI. One reason is that upon delivery, software licenses can be sold. Time-to-market determines when the money is made. An additional consequence is that the first product that makes it to market has a competitive edge, it can enter the market first and attain customers that pay for the product and are than faced with the necessity to use the product in order to get a return of their investment in the product.
Whether your product is custom or common, the business model is that you sell the right to use the product. And the product can only be used when it is delivered to the market. Time-to-market is therefore primarily a cost-driven metric, the shorter the time to deliver the product to the market, the lower the cost of development and the lower the cost of missed market-opportunity.
Cynics will note that when the product delivered is of low quality, i.e. the customer will get limited value from it, the customer will be bound to use the product for a longer time to get her return on investment. Consequently, customers will be less likely to switch to another vendor because there is already so much invested in the current vendor. Low quality pays off.
Around 15 years after I was first introduced to the concept and importance of time-to-market I coined the term ‘Time-in-Market’ at one of the largest financial institutions in the Netherlands. Time-in market refers to the time a product is used after it is delivered to the market. I started using the term to reflect the time a product is available for use by the customers of the bank.
The relevance of this KPI was at the time based around the fact that the change-failure-rate (the % of changes that required corrective actions) was extremely high. Change-failure-rate is one of the 4 de-facto DevOps metrics used to measure software delivery performance. Because of the high change-failure-rate, the time-in-market, the time products where available to the customers of the bank, was low. Consider that the bank made money by charging its customers for every financial transaction they did, the more transactions performed the more revenue was generated. Add to this the ambition to become the national payment hub for the Netherlands and you can understand why a short time-in-market was considered disastrous.
Time-in-market is therefore primarily a value-driven metric, the longer the time-in-market of a service, the higher the potential revenue made from the service. Note that time-in-market is related to revenue potential because product availability does not imply product use.
The New Business Model
The new business model that many traditional ISVs adopt is one where customers are charged for the usage of services instead of owning the product that provides those services. It is a paradigm shift from pay-to-own to pay-for-use. It is the common SaaS model, in fact it is one of the core aspects of the cloud according to NIST, Measured service.
In an online world, this model makes more sense than the old model, based around product ownership. This business model around selling a product that is then owned by the customer is for online services, at its core ‘business destructive’.
Right-to-Own vs. Pay-for-Use
When you use a service, there is nothing for you to own but the results of that usage. As a customer you pay for the goal not the means. I like the analogy with a taxi service. When you use their service, you do not own the car nor the driver. Once you have paid for your fare, you pay for the fact that you arrived at your desired destination. There is a little flaw in this analogy which I am going to straighten out.
In the product ownership model, when you want to get a ride to the airport from your home, you would buy the taxi, car, and driver, and then use it to get to the airport. Or not when you changed your mind. In any case, you would own the taxi with driver and have it available for future use. It might become obsolete when you want to go somewhere that is not reachable by car. You would need to buy a plane and pilots instead. The taxi company would probably sell you only one car with driver and even though it might have a ‘better’ taxi 6 months down the line, you would not have the money to buy it. The model would destroy the taxi company.
For service providers the business model based on product ownership does not work well. A fact that is often lost upon service providers that used to be successful ISVs. Next to extending the span of responsibilities, these companies also need to change the complete sales model (selling a product is quite different from selling a subscription to a service).
Another aspect of adopting the business model that is often lacking attention is around bonus structures of employees. No more large deals and sales targets to base bonusses on. Revenue is generated after the product is delivered. With customers no longer paying for product delivery, sales targets are no longer relevant. This has a huge impact on human resource management.
A SaaS provider not only develops its products, it also deploys these products on environments managed by them. Although this is not entirely correct. As SaaS companies leverage services provided by cloud vendors like Amazon, Google, and Microsoft, they are prone to use the cloud vendor’s IaaS and PaaS offerings. Which are also services and paid for on a pay-per-use basis. The SaaS vendor does not own the hardware its services run on and often not even the database systems, the messaging systems, the storage systems, the high-availability infrastructure etc. Consequently, the SaaS provider only manages parts of its infrastructure and relies on the services of their cloud vendor for the remaining part.
Nevertheless, all costs involved in providing the service to the customer are for the SaaS provider to bear. Operational costs are the SaaS provider’s costs and will have to be paid for with money paid by customers.
ISVs that have not yet adopted the pay-per-use model will find themselves in a treacherous situation. When just entering the SaaS market, they will have relatively high costs because their on-premise product must be transformed into a product that can be deployed in a cloud environment and offered as a service. And costs are involved with setting up the operational support organization as well. Cost that will initially be hard to be repaid because existing customers will likely not migrate from the product offering to the service proposition. Therefore, new customers must be attracted. When these new customers pay upfront all license fees, for example on a named-user model, the new to the market SaaS provider will benefit from getting all revenue at the start of the contract with the new customers. Enough, hopefully, to pay for the investments done to turn a product into a service.
Return of Investment
When the customers consider the offered service to be useful and valuable, they will use the service more actively, the costs for providing the service will increase. With the cloud vendor charging the SaaS provider for the resources used, the charges will go up as more resources are needed to handle the increase load generated by the customers. What initially seemed to be a perfect model for paying of the go-to-SaaS-market costs turns out to be a business risk. Ironically, when the offered service is not considered to be useful and valuable, the SaaS provider will not face increased costs and will close their fiscal year with better numbers.
The treacherous situation is of course in that great service means disastrous business results and bad service means great business result. Neither results in a sustainable business. Albeit a little dramatic, the biggest risk for failing is being successful.
The new business model addresses this risk by using the cloud native characteristic of ‘measured service’. The mitigation for this risk is of course the adoption of a different business model, one where cost and benefit are intertwined. Increased cost should be the result of increased revenue, which is the case when a pay-for-use model is used as the revenue model. As explained earlier, in this business model, it is measured what the use of the service by customers is and apply the cloud characteristic of a measured service, something the utility services have done since the dawn of their time. The more a customer uses the service, the more revenue will be generated. This is fair, because the more the customer uses the service, the more benefit they have in their business from that service and the more cost the SaaS provider has in providing that service.
A real-world challenge, and significant risk is related to the adoption of the new service and the investments required to develop the service. In a pay-for-use model, no revenue is generated when the service is not being used. Yet the investments are still required. It is the reverse of the situation where the pay-to-own model is applied, in that model cost incurred after market-launch are not covered by generated revenue in the event of business success. In the pay-for-use model, cost incurred before market-launch will not be covered in the event of business failure.
Viable products help customer solve urgent problems.
Although a hybrid approach seems to be the answer, meaning use a pay-to-own model up to a threshold and apply the pay-for-use model once the threshold is reached. For example, the customer will pay for online file storage an annual fee of €99 which gives her a max of 1 TB storage, in case more is needed she will be charged on a daily basis €0.01 for each GB over the contracted 1 TB. Considering many online file storage services use a similar model, it seems to be a viable model indeed.
The downside of this model is that it will require a rather feature complete service with many bells and whistles to get the interest of customers to pay for the initial 1 TB. It still requires a large up-front investment which then needs to be repaid.
A more likely approach to succeed is to reduce the required investment before revenue can be generated. Something that can only be achieved by either deliver low quality (which reduces time-in-market and thus a bad idea), or by delivering a less sophisticated service, in other words, a service with fewer and possibly no bells nor whistles. A Minimal Viable Product, or MVP.
By scoping the first service offering as an MVP; a product that has the minimal set of features necessary to be of value to its users. The initial investment needed will be low while still of value to customers and thus generating revenue. ISVs that enter the SaaS market are therefore best off by adopting agile principles, delivering an MVP as initial service offering to enter the market and then increase the product’s features set based on market feedback. In other words, deliver a product that is relevant to its users and improve it by maintaining its relevance.
Viable products help customer solve urgent problems and are doing so in a way that is convenient. In other words, they have relevance. SaaS providers and especially those new to the market must therefore put their focus on products of relevance to its market.
Relevant services are services that are considered by the user to be of value. They typically solve an urgent problem. There will never be a user that will use a service that is not relevant to them, i.e. of benefit to them. Benefit might be defined as ‘satisfying curiosity’.
Up to a point relevance can be measured, which is convenient to determine next steps. Every service that is used, is of relevance. The challenge is to understand how relevant the service is. Knowing how relevant a service is will allow us to understand how important it is to further invest in the development of the service. Investments, especially time, should be on the most relevant features.
By merely tracking whether a service is used or not, we do not know how relevant the service is to the user. It only tells us that it is relevant, or not. The insights we gain are rather binary in nature. The service used or not.
Usage monitoring goes beyond usage tracking and is an important aspect of delivering software as a service. The captured metrics not only provide insights about which services are being used, but also when they are used and in which context they are used. It is also imperative from a business model perspective, after all, the customer pays for using the service. To be able to bill the customer at the end of the month, we need to know what to bill them for.
Product delivery and service offering are two very different business models. The differences in business model also impact the organizational structure. An Independent Software Vendor that is transforming into a SaaS provider will have to change not only its business model but also its organizational model due to the added responsibility for their customers’ operations.
Entry into the SaaS market will require adopting agile concepts to limit the required investments required for their first returns. Long development cycles associated with product delivery are to be replaced by short cycles that iteratively increase the feature set of the product. At the same time the revenue model of SaaS companies requires a rigorous process to determine which features to develop first, which features will yield the highest return on investment.
On the go and done reading? Check out this continuing piece of pure fiction.
The text very explicitly communicates my own personal views, experiences and practices. Any similarities with the views, experiences and practices of any of my previous or current clients, customers or employers are strictly coincidental. This post is therefore my own, and I am the sole author of it and am the sole copyright holder of it.
Special thanks to my lovely wife Olcay, as well as my friend Sytse who took the time and made the effort to review my article. I am confident that the article’s quality was significantly improved by their feedback.