Flexera recently published a research report called the Monetization Monitor: Monetization Models and Pricing. It covers a lot of interesting insights on licensing but what I want to focus on is a specific data point they share on deployments:
63% of software organizations continue to have moderate to extensive on-premises deployments.
This statistic is not a total surprise. However, if you do a review of current product management blogs, books, podcasts, and tweets you will find a number of modern product development best practices that simply do not work with on-premises software. Some can with extra work, but most do not. This is a problem.
Modern Product Management practices are built to provide more value to customers faster. Without these practices in place, it means that vendors are delivering less value than would be possible with SaaS models.
Modern Product Management Practices
Below I explore a few of these best practices and how they relate to on-premises software.
Agile Software Development
The Agile Manifesto was written before cloud and SaaS computing was a thing. So, of course, it can work within on-premises software products but the last decade has demonstrated it fits even better with SaaS.
When combined with the DevOps methods for Continuous Integration and Continuous Delivery the ability for agile to create working software quickly and get it into customers’ hands immediately has removed months of delay from value realization. By contrast, on-premises software has a high cost to package, deliver, and upgrade that customers cannot accept new valuable features as quickly as agile shops can release them. Customers receiving additional business value monthly is simply better than getting it every two years.
Data-Driven Product Management
Product teams in SaaS organizations have the benefit of collecting and analyzing data that is captured by their software application. This enables analyzing usage patterns to create new capabilities, improve existing ones, and remove capabilities that are not working.
Specialized third-party applications like Pendo, Amplitude, and Mixpanel help product teams with the collection and analysis of usage data directly from their applications. Moreover, it can sometimes be combined with demographic, psychographic, and behavioral data to unlock incredibly actionable insights on user segments.
By and large, these tools cannot be deployed into an on-premises enterprise software deployment. The best some on-premises products do is include limited usage data gathering into the product and periodically send it back to the company for analysis. If you want to leverage a new data collection point, you need to wait until another product update is installed with new data collection features. Then, you need to hope the customer will accept sending data out of their network or it is all for not.
A/B Testing, a very popular design optimization technique, has proven very useful at helping design teams improve user experience incrementally in live systems. For on-premises, this is not feasible to perform live.
This lack of data insight hampers on-premises software product managers’ ability to assess potential problems and opportunities for improving and delighting customers. The end result is that on-premises products inevitably become bloated with underutilized features and less user-friendly.
Intelligent Assistants and Chatbots
User experience has been improved significantly in many applications through the use of chatbots that offer users help when needed. True, Clippy was around many years ago for locally installed copies of Microsoft Office. However, Clippy turned out to be an industry joke. It could only offer the most basic of help. New, AI-driven assistants are much more effective for on-premises software but the most advanced are integrated live into products via SaaS APIs that integrate humans directly into the discussion loop when needed.
Leveraging such interactive, communication and support tools on-premises is impractical today. While possible to build, they would quickly become unsupportable in a rapidly changing world. For example, consider an on-premises product deployed in Jan 2019 with Walkme integrated customer success capability. Since the on-premises product may not be upgraded for multiple years to bring in new features the integration must continue to work during that time which may not be commercially reasonable. The reason is that Walkme might update its API many times over this period to support evolving standards and capabilities. SaaS enables a more limited demand on backward compatibility enabling more rapid innovation.
APIs Everywhere
Whether enriching the user experience with third-party data or pulling in capabilities to augment a specific offering, SaaS benefits significantly from the explosion of open and commercial APIs. On-premises software can sometimes access these APIs but it will frequently have challenges. First, is the issue of legacy support as described in the previous Walkme example. The second is that access to APIs may be blocked due to on-premises security protocols. Lastly, integrating from many on-premises systems requires repeated configuration work that is open to more opportunities for problems.
I recall many years ago building a new dashboard capability into a product, that included a mapping visualization option. Only about half our customers could use this, much-desired feature, due to a variety of security and technical blockers within their networks. SaaS products can test and control for these issues to ensure higher quality delivery for all users.
Without reliable access to all the APIs available today, on-premises software vendors much either compromise on capabilities that reduce delivered value or invest much more to replicate the value provided. Neither is in the best interest of the customer or the vendor.
Data Exhaust and Consortium Data
One of the more sensitive topics today is the ability of the vendor running the SaaS applications to leverage data created or passed through the application for enabling additional value-added services.
A classic example here is cybersecurity. Consider a cybersecurity software company that delivers on-premises software. Customers can analyze network activity to detect previously known and newly emerging risks within the network traffic they experience. Now imagine, this same software being able to learn from the data of hundreds of customers. The effectiveness of its detection capabilities would be significantly improved through a consortium of data rather than many silos learning on their own.
For on-premises software companies, they must ask customers to provide data into a centralized, secure repository. For SaaS companies, there is no extra data acquisition required, therefore, learning can be more immediate, and new types of threats can be prevented before they spread across hundreds of customers.
Freemium Pricing
While the concept of freemium product pricing existed back in the 1990s, it was not until SaaS applications took hold that this pricing model began to drive many popular business models. The fact that SaaS products can now be designed in a manner to very easily onboard new users with insignificant incremental cost to the vendor enables freemium models to thrive. Once on-boarded and happy, it is easier for customers to adopt higher level paid services.
On-premises software vendors, therefore, are prevented from taking advantage of modern marketing and customer acquisition tools that have proven extremely potent for many vendors including Spotify, Box, Evernote, Mailchimp, and many of the most popular video games.
Why Build On-Premises then?
Most software organizations and enterprises know the standard arguments for SaaS. They include benefits such as:
- Lower upfront investment in hardware, supporting software, and implementation services
- Faster implementation time than on-premises projects as you remove the need to acquire hardware, perform installations, and IT training.
- Shift from CapEx to OpEx as costs are now predictable and more level over the period of use
- Elasticity and scalability to handle growth in data, usage, and spikes in such activity as fundamental to SaaS architectures
- Support and Maintenance can be handled by the experts in the software
So why, with these benefits and the long list of modern practices for delivering great products, do vendors still produce on-premise software? In short, customers do not fully realize the cost of sticking with on-premises software. Instead, the discussion to stick with on-premises software usually centers on:
- Data Security – Fear of reduced security especially where sensitive personally identifiable financial and health information. A single point of failure is a real concern, especially in heavily regulated industries. However, more evidence in practice is showing that SaaS can actually be more secure through leveraging greater expertise in security than most individual customers would have.
- Control and Customization – Working with a SaaS application creates inherent limitations in the flexibility firms have to customize the software. Customers are dependent on the vendor creating sufficient configurable control to replace this lost flexibility. In truth, such customizations are typically regretted later for most on-premises software as they drive up support and maintenance costs over time with minimal added business value.
- Technical Performance – Applications that require large amounts of data movement, ultra-low latency processing, very high availability, or other strict technical performance characteristics.
- Legacy investments – Deep investments by vendors and customers in previously installed software systems create a challenge to show the value of switching. As products age, new vendors are arriving at the scene that is providing superior capabilities and business value that will eventually drive a switch to SaaS. If the legacy vendor is not creating this replacement product, someone else will.
Few market categories require on-premises deployment all the time due to these or other reasons. In this article, I have compared SaaS versus On-Premises deployment. There are additional deployment models including hosted, containerized, and hybrid approaches that can address some of the challenges while gaining some of the benefits in a SaaS model. However, only the SaaS model fully supports these best practices.
Conclusion
Modern product management and design best practices help to create the best possible solutions to market problems in the shortest time. Since on-premises software is frequently limited in its ability to leverage these practices, we are left with a single conclusion:
On-Premises software products are inferior to SaaS products.