Originally published on March 9, 2007
After overcoming all of the objections in your control: existence, reliability, support, and scalability, you must now overcome the objections that are not in your control. These are the real show stoppers and come from not understanding your target market. The SaaS industry obviously agrees that SaaS is the future of software delivery, but while they still have a substantial amount of value in their existing systems left on the books, the Pureplay version of SaaS may not be needed in Fortune 1000-sized Enterprises.
SaaS is often a combination of an On-Demand delivery mechanism (SaaS), and an On-Demand licensing model (Utility). This is a very powerful combination. The real power for Enterprise clients, at least in the near future, might be found more in the licensing model more than the software delivery model.
When developing a SaaS product for the Enterprise market and faced with the “legacy controls” objections detailed in Part 2, there are three rules that should be adhered to. First, don’t be a Pureplay SaaS vendor if your market will not accept it. Be a solution provider first, a software company second and a SaaS company third. When talking to investors or other people that know about SaaS, then you should be specific. When talking to the clients, it is best not to mention technology at all. Mention solutions to their problems. Do not get stuck on a technical solution that doesn’t fit with your customers needs.
Focusing on the solutions of your clients is one thing, but you also do not want to try to be all things to everybody. You need to find out what one or two solutions you need to penetrate your market, and go for it. Those customers that require something else will have to be left out. Doing one off deals at first is a great way to kill your scalability as a company and is often what keeps software companies small. They may have big clients, but might only have a handful. This is the difference between the birth of a lifestyle business and a high-growth enterprise.
The second two rules focus on implementing the first rule of not being a Pureplay SaaS provider. There are two ways to work around being a Pureplay SaaS vendor, but still remain in the On-Demand market; Focus on On-Demand licensing/pricing and/or build a Hybrid SaaS system. From the business side of SaaS, the most exciting thing is the next generation licensing model.
The legacy model of paying a large up front license fee for the software (or paying over time on a lease), plus annual renewals and ongoing support fees is definitely ready to be put to rest. Billing companies for their actual usage of the system is very exciting. In fact, using a company like LeCayla with their Metering and Billing Infrastructure, you can do this today with your existing On-Premises software. This is a way to leverage your existing software, but bring a different pricing model to the table.
For a start-up, and that is the target of this series, a service such as LeCayla allows you to offload the processing, storage, and infrastructure support to your Enterprise customer through an On-Premises or Hybrid SaaS solution (defined below), while still offering Utility Pricing to your customer. This provides a “best of both worlds” approach, and helps you sell your product with the always popular “low sunk cost”.
Coming back full-circle to “knowing your customer”, another detail in your customer intelligence gathering should be their economic focus; are they a capital or expense oriented company? In other words, do they care that they can pay over time for what they use or would they rather pay one large, up front fee? If you’ve done your homework, this won’t be a surprise. In this case you just avoid On-Demand pricing as a selling point.
On the technology side, the best solution outside of simply plugging in billing software to an On-Premises application (not ideal) would be to build a Hybrid SaaS system that can support both Pureplay SaaS and On-Premises clients. To do this, the system must be architected from the ground up to support this model. The hosted system would be a single-instance, multi-tenant system. The On-Premises system acts as a remote-tenant, “calling home” and sending billing data and other “network effect” data to the single-instance data layer. If you have “network effect” features, this is a great way to tie On-Premises installations into that shared data layer.
The technical implementation of this is so dependent upon the problem you are solving, the target vertical (if any), the On-Premises requirements and needs, etc. that trying to suggest an actual “remote tenant” solution would be impossible. Remember, the technology used is not important to the customer, just to you and maybe your investors. Whether it is a legacy server-based product that uses SOA to move data to the hosted system, an On-Premises “lite” version of the hosted system, or even a desktop application, the technology does not matter.
What works as a SaaS vendor very much depends on your target market. Involving customers early on will save a great deal of pain down the road. This involvement must be at multiple levels as well. The line manager will give you great functional feedback, the Controller will give you reporting requirements, and the IT group will tell you what you can do, what you can’t do, and what they are willing to do.
This might sound obvious, but this is mostly geared toward start-ups who might not think to pull in all of those resources. The key lesson is whether you are a SaaS or On-Premises vendor, know your customer and involve them from the beginning. You cannot develop a solution to their problem without knowing not only their problem, but the acceptable ways to solve it.