I just posted a lengthy article about the Morph Application Platform, Ruby on Rails, and Amazon Web Services at the Morph Labs USA Blog. Basically, there is a lot of confusion about how developers interact with the Amazon Web Services when deploying their Rails applications on the Morph Application Platform.
The takeaway from the article is simple. When you deploy your application using Morph AppSpaces, you do not interact directly with Amazon Web Services unless you want to. You will never work directly with EC2, but you could leverage S3 or SQS if you want to for centralized storage; but you don't have to. Morph completely abstracts developers from the underlying technology so developers are free to focus on development of the core product.
Check it out if you had any questions about how Ruby on Rails developers work with Amazon Web Services when leveraging the Morph Application Platform.
I have been actively blogging over at the Morph Labs USA blog. I will probably post something here very so often, but for now, if you want to know what is going on with me or Morph Labs, check out our USA blog or grab the feed.
My main focus at Morph is bringing the concept of a Platform-as-a-Service (PaaS) to the Ruby on Rails community. The idea of a PaaS for your Rails applications is quite compelling, but is also difficult to wrap your brain around for those with a server-centric background. With a PaaS, you no longer think about servers or infrastructure. Obviously the benefits of PaaS to a Software-as-a-Service (SaaS) or web start-up are great, the least of which is the reduction of infrastructure investment. The greatest gains come in the form of improved productivity by allowing developers to focus on the core product and not the underlying system administration and scalability functions.
The productivity gains from a PaaS such as the Morph Application Platform and Morph AppSpaces, that allow you to use standard development and deployment tools (such as Git, Capistrano, etc.), along with a standard language and framework (Ruby and Rails respectively) are significant. Where in the past you might have pushed features to version 2.0 (or higher) because you needed to spend time on scalability, security, and administration features or spend money on infrastructure and not developers, with Morph AppSpaces, you can pull those features back into the 1.0 release!
Developers can try out the Morph eXchange, Morph Application Platform, and Morph AppSpaces for FREE, too. Simply signup and you can start deploying your applications to show off to your friends or potential clients. If your application gains traction and you want to move into production, you can simply change the "type" of AppSpace from developer to production. You can "move" to production without actually "moving" anything. All of the pricing is detailed on the site, but the "smallest" production account, which gives you an elastically scalable, redundant system, that is load balanced, highly-available, backed-up, monitored, etc. is about US$1.00 per day!
Obviously I'm pretty excited about what Morph is doing. The Platform-as-a-Service (PaaS) market is heating up, and Morph is right there with the first PaaS offering for Ruby on Rails applications. If you are a Rails developer, you owe it to yourself and your clients to take a look at what we have to offer.
On December 31, 2007 I wrote a post about what 2008 will hold for Software-as-a-Service (SaaS). In that article I stated that 2008 will be the year the small ISV enters the SaaS market in a big way. It was, and is, my opinion that in order for this to happen, certain barriers to entry had to be removed. For instance, it is one thing to build an application, and it is yet another altogether to architect that system properly for scalability and business continuity.
Additionally, existing Platform-as-a-Service (PaaS) offerings, especially those that resemble RAD tools in deployed software, require developers to learn and program around proprietary APIs or even worse, learn an entire, also proprietary, programming language. Finally, pricing is generally such that an entrepreneur or start-up that builds a SaaS product and wants to launch into a production-ready environment must shell out a lot of money for dedicated systems at a host or "virtual" systems at a SaaS enabler or other "clustered" type of host.
What if there was a system that SaaS application developers could leverage without changing the way they build their software, that would allow them to rapidly deploy their SaaS or Web 2.0 solution on a platform that can grow with them (elastic) and provide the business continuity that their clients require?
What if the pricing structure was such that you can start for free, deploy a prototype, expand and contract your available resources on-demand, allowing you to instantly scale to handle whatever load is required, always paying only for what you use and nothing more. If this type of system existed, this would be the key to lowering those barriers to entry for small ISVs and would allow that large influx of vertically focused and tight horizontal niche SaaS to come to market as I predicted.
Guess what? It does exist and I've decided to put my money where my mouth is! I've joined Morph Labs, the creators of the Morph Application Platform. Morph Application Platform allows Ruby on Rails developers to quickly (it takes 6 minutes... see this video) deploy an application that leverages grid computing technology (currently using Amazon S3 and EC2) and provides the afore mentioned benefits.
My role with Morph Labs is Business Development Manager and I am going to be building out the user community and affiliate network in the United States. If you are a Ruby on Rails developer, ISV that builds applications in Rails, an offshore/near shore development company, or anyone else that would like to participate in our Beta program, please sign up here. This is your chance to test the system and tell us what you think, request features that don't exist, and generally have a hand in building something necessary for the industry.
Also, if you have a Ruby on Rails or SaaS group and would like us to come show you what the Morph Application Platform is all about and how we believe it can help your developers and entrepreneurs, please give me a shout at lincoln //at// morphlabs //dot// com.
I've been monitoring my web statistics and have noticed some interesting things, and have also made some changes.
First, I've noticed a handful of clicks on my email address, which is behind a "mailhide" feature I wrote about here. I've noticed that these clicks came from people that found my site via a search for something to do with SaaS or they came from my LinkedIn profile. Either way, I can see that they weren't robots. The problem is that I never received an email from them.
Either the system failed (thy couldn't read the captcha, the popup was blocked, etc.) or they simply got irritated and moved on. Either way, that cost me a valuable contact so I have removed it. You can now contact me directly via email at lincoln@lincolnmurphy.com.
Second, aside from SaaS traffic, which makes up the majority of my traffic, thankfully, I've also noticed a lot of traffic coming on older articles. Some are links from other blogs that linked to my article when it was first posted. Others are coming in from Google searches (almost exclusively). Many keyword searches include the term Mapsco and end up at my lengthy article about the mapping company. In fact, I've had a handful of searches internally via my Lijit widget with the term Mapsco. The other non-SaaS traffic is coming from northwest Arkansas (Wal-Mart territory) to my article published early in 2007 about Wal-Mart's customer segmentation plan.
I'm have an pipeline of Software-as-a-Service (SaaS) Product Marketing articles that I'm going to try to bring online in the next couple of weeks. Also, I'm experimenting with Squidoo as a platform for aggregating SaaS Product Marketing news and articles.
I'm always trying to learn about real life, in-the-field objections that sales people are having when it comes to selling SaaS products, especially to enterprise clients. There was an article published today on Silicon.com that features an objection to a SaaS product that I have not yet heard of... limited feature set. Wait, yes I have, and this is not a SaaS problem just because the product in question was a SaaS product.
If you aren't interested in reading the article, or the synopsis of the article, here is my take on it. Basically, the vendor showed the client some pre-release features that they couldn't deliver in a timely manner so the client looked for a product that could deliver. Unfortunately to get the features they needed, the client had to take a best-of-breed (do we still say this?) approach rather than an integrated one. This new approach caused problems since sharing data with the systems chosen proved to be a challenge.
This scenario could have occurred regardless of the software delivery method. First, integrating products that are not built to share data is not easy. Whether deployed or SaaS, products that are built without data sharing in mind often cause problems when forced to integrate. I think the mentality with a deployed solution, where you generally have access to the underlying database, is that if push comes to shove, you can drop down and query the data manually. Queries are one thing, but often people think they can import and export data this way. What they often miss is that business rules are enforced within at the application level and by writing directly to the database they could be causing data integrity problems.
Since SaaS products are hosted, a mechanism to directly work with the underlying database is generally not available, nor should it be. The SaaS vendor should know their market, know where they fit in the market, and know what products they might have to integrate with. They should learn this early in the process and create the tools necessary to allow for integration with those third-party systems. This should not come up as a concern to the client if the SaaS vendor has done their homework.
Second, in the case of the scenario referenced in the Silicon.com article, the vendor made the error of showcasing features they were not ready to deliver. Again, this is not a SaaS problem but an age-old problem in the Software business itself. Selling features that do not exist yet, or even products that don't exist yet, is not new, and not limited to SaaS. Software vendors of every kind must be cognizant that over promising and under delivering is not the way to build a sustainable business.
At the first Southwest Venture Forum meeting of 2008, the official topic was "Venture Capital Update: 2008", but the unofficial topic, when speaking with those in attendance, was all SaaS. First, I spoke to a banker who said his client is a SaaS vendor (technically an ASP, but I forgive him) and the company handing out a 3-fold pamphlet for their MySpace killer (guerrilla style) have a "SaaS Guru" as their CTO.
Finally, the two companies that presented their investor pitches (Red Oxygen and 2Go Software) made sure to use the SaaS buzzword in their presentations, even though they don't seem to have SaaS products at all. Red Oxygen definitely has a hosted solution and I think 2Go said they do as well. Don't forget, however, that hosted is not the same as SaaS.
This was interesting, especially given the fact that this was a non-tech event. I do think that we need to re-define what SaaS is, but at least its out there, and technology start-ups in North Texas apparently see enough value in the term to use it in their pitches. I'm going to begin work cataloging the true SaaS start-ups in North Texas. If you have a SaaS start-up in this neck of the woods, drop me a line… lincoln [at] lincolnmurphy [dot] com
I'm not going to attempt to predict the future, but I believe 2008 will be the year of the Small Vertical (intra-vertical focused) and Niche Horizontal (spanning only a few, related verticals) SaaS ISV. The headline producing SaaS ventures in 2007 were the big players, with horizontal offerings. These were Salesforce.com (CRM), Business Objects (BI), and NetSuite (Office Productivity). Just as in the deployed world, "big" horizontal applications are the same ones that have traditionally received the press. And 2008 will not be much different.
Small ISVs that until now have remained in the "deployed" software and traditional licensing game will begin to break out. I predict that 2008 will see the largest influx of vertically focused and niche horizontal SaaS offerings to the market to date. The future of SaaS (the long tail, if you will) is the Small Vertical and Niche Horizontal products and tools. These will be new tools, tools ported from "deployed" solutions, and internal tools utilized by technology services organizations they would like to productize.
The problems I wrote about in my articles in early 2007 regarding selling SaaS solutions to the Enterprise for the most part still hold true. Sure, the climate is changing, but many of the objections are still being faced. These challenges are actually a good thing for well-prepared ISVs as they provide barriers to entry for those SaaS vendors that are not ready to overcome them.
In 2008, these barriers will become an even larger part of the story as more and more small ISVs attempt to sell SaaS products to F1000 companies. Large, well-funded, and well-connected, SaaS vendors had to overcome these same hurdles to get to where they are, but had the resources to wait out the market; small ISVs do not have that luxury.
Since I work with companies to bring their vertically-focused and niche horizontal on-demand software and technology service products to market, 2008 will present some interesting challenges and opportunities.
You probably capture a lot of data in your web or SaaS app, but how often do you mine that data for Actionable Business Intelligence; information you can use to solve business problems, such as slumping revenue, high client turnover, etc? It might be time to stop everything else you’re doing and go write some queries. Below are some scenarios that I helped a start-up solve recently with information right at their fingertips.
If you have paying customers who aren’t using your system, find out why they aren’t actively using the system and fix it.
Ask them what you can do to make their experience better, what problems they are having, etc. If you do not, when their contract is up, or they get their next bill, there is a high probability they will no longer be paying customers. It is much easier and cheaper to keep these customers than it is to go find new ones. If the majority of your system’s usage is from non-premium users, maybe you are giving away too much.
Contact those free users who are actively using the system and find out why they haven’t upgraded. If the answer is “I don’t need those premium features” then you are giving away too much. You can either reduce the feature set on the free version or introduce advertising within the free product.
The former might cause some problems with your users, but the reality is it has to be done. Tell them you are scaling back on the feature set in the free version but you would be happy to upgrade them to the premium version at a discount.
The latter can be implemented without making existing users too upset and would be one of the reasons someone would upgrade to the premium version; to get rid of those pesky ads. Remember, however, that if your user base is small, ads might not make up for the lost premium revenue.
If you have multiple people from the same company using your service, perhaps you could leverage that into a corporate account.
Those users may not even know the others in their office are using it. If you don’t feel you have enough users at that company for them to consider a corporate account, leverage the few users you do have to spread the word internally… give them an incentive to spread the word (free month for every new user, etc.). This will quickly get you to that magical number you’ve conjured up that would give you confidence to sell to corporate. Alternatively, you might find that you have a large, un-related user base in certain cities, and that might be a great place to go for an early-adopter round table (with free pizza!) to get their feedback and to get them to spread the word for you.
If the usage of your system is very small or the majority of the users are not paying, perhaps you can use that data to justify reducing your overhead.
Do you need all that hardware at the co-lo if you are only getting 70 hits per day or do you really care if the freeloaders have to wait a second longer for processing to occur? This is difficult for tech-founders who might have a geek crush on their servers but could be enough to save a company with low revenues.
Finally, whether you are mining data or not, make sure to constantly solicit feedback from your early-adopter customers. It reminds them, and you, who exactly you are building your web service for.
I have received and amazing amount of feedback on the Enterprise SaaS series; just about everyone who read it has contacted me. One person said he had a problem adding a comment on the site. I have not been able to reproduce the problem he encountered; if you are having problems commenting, too, please contact me via email (lincoln [at] lincolnmurphy [dot] com). Other than that one technical glitch, I have received mostly positive comments, but usually someone has at least one concern. I am going to try to address all of their concerns at one time.
Hybrid SaaS != Hybrid Licensing Model
A couple of people have mentioned that trying to support a hybrid licensing (or business) model would be difficult at best. I couldn't agree more. I never intended to support or even condone multiple licensing models.
I re-read what I wrote, and while it makes sense to me, you really have to follow it closely otherwise you could think I am supporting multiple licensing models. In fact, my "Hybrid SaaS" model is a hybrid technology model that is supported by only one licensing model, utility pricing. What I condone is pretty much technology agnostic and relies on the system being able to "call home" to handle the pricing. I think that is the future of the software industry more so than any actual technology.
That said, I think the SaaS delivery model is the future of software. I am definitely pro-SaaS, including Pureplay SaaS. This series was just to let people know that while we as technologists, entrepreneurs, and evangelists have adopted SaaS as the de facto standard for software delivery, Corporate America, as I have seen it, is not onboard with that. Are they changing? Yes. Will it get better? Absolutely. SaaS is just not ubiquitous yet and you must be prepared for that as a new SaaS start-up. In one or two years, these objections may go away completely; you still need to know your customer though.
A problem with many SaaS vendors is they come in and say "we're a SaaS vendor" like the customer cares. Do on-premises software companies come in and say "our software is written in Java" or "we distribute our software on CDs"? No. And they shouldn't because no one cares. The caveat with SaaS is that it is actually more difficult (hence the creation of my articles), because you actually need to make sure they can support that type of delivery mechanism.
But what about selling the benefits of the SaaS model? Yes, you need to do this. But it has been my experience that you must do this after you talk about solving the problems of your customers; "Not only can we solve your problems, bring you these value-adds, but also our unique delivery model can save you money...". If your only differentiation point is the delivery method of your software, that seems rather weak.
Source Code Escrow Questions
I got this response from one reader:
I liked the idea of setting up an escrow for the source code as an insurance policy for the customer. I suspect many will scoff at that idea since the IP can be sold at bankruptcy auction but perhaps with an expiration date on the escrow agreement it would be a good tool for start-ups to use.
I'm not sure how widely used software escrow is, but it is certainly not a new thing. I ran into it when I was looking for a hosted supply chain solution a few years ago. I asked them what would happen if they go away and they introduced me to the concept of software escrow.
Source code escrow is a very detailed process and has strict controls over the IP. It is totally up to the parties involved, but you can always specify that the beneficiary is not allowed to use the IP outside of the scope of its intended purpose, i.e. they can't take it and commercialize it on its own or use it in their own products.
Source code escrow is really only used to facilitate business continuity, not to turn over rights to use the IP as you wish. Those rights are maintained by the owners, probably the investors (or creditors) in the venture, to do with as they wish.
I have also been told that SaaS is in use in just about every Enterprise in one form or another. I would take it one step further and say that both Pureplay SaaS and Hybrid SaaS applications are both in use heavily. Pureplay SaaS in the form of HRM, CRM, SCM and Hybrid in the form of vendor-provided desktop applications such as benefits management, shipping carrier systems from UPS and FedEx, etc.
If SaaS is already in Corporate America, why do I say the barrier is still there? Three reasons. 1) you are a start-up, not an existing vendor with a new (often free) product to improve the relationship (such as UPS or FedEx) or 2) you are requiring payment in excess of the unit managers expensing abilities or have requirements outside of that of a standard PC (thus drawing the attention of the IT and Finance departments) and/or 3) you are trying to differentiate your product and must sell to multiple levels, thus bringing it to the attention of the IT department and other conservative levels of management.
I have been inside of multiple companies where I am getting resistance due to the nature of our product architecture, while simultaneously talking about how we are going to integrate with other systems in use that are SaaS themselves. Again, your experience may vary, and this is all based on my experiences. In my experience it is still a challenge for a vendor to sell a SaaS-delivered product in Fortune 1000 companies. Times are changing, it is getting better, and soon, SaaS will be ubiquitous. Until then, please be prepared. You *can* sell SaaS-delivered solutions to Fortune 1000 companies; it is just easier if you know what to expect when you go in there. Good luck!
This series is to help Enterprise SaaS vendors with two potentially business-stopping problems; scalability and sustainability. I am attempting to address both the real-life objections seen in Fortune 1000 enterprises when selling a SaaS solution and some ways to work around them.
This series is also meant to get SaaS vendors to really look at their delivery model and make sure they are not taking on more of the support costs than they actually need to. By knowing your target customers, you can save yourself (and your investors) a lot of money and improve your margins; you could even save your company in the long run.
This series is my opinion and is based on my experience. Your experience may differ, and this is not meant to be the definitive text on the subject. I just thought I would share it. Below are links to all three parts of the series, abstracts of each part, and a fourth part addressing Economies of Scale and SaaS.
Part 1 Who needs Pureplay SaaS? Why do you want to be a Pureplay SaaS vendor if you are not targeting those market segments? One of the biggest "selling points" of SaaS as a software delivery model is reduced support costs for the user. This is great, but if you are selling to a company that already has the infrastructure to support On-Premises enterprise software, why would you take on those support costs yourself? With SaaS delivered software, who supports it? More than likely it is the SaaS vendor handling all support, from first level up. Can you as the SaaS vendor really handle these support costs long-term?
Part 2 Starting a software company from scratch, On-Premises or SaaS, is no small task. There are five major objections witnessed when a start-up is selling SaaS solutions to Fortune 1000-sized companies: existence, reliability, support, and scalability. These are objections faced by almost every start-up in one form or another whether they sell software or not. The list of "legacy controls" are objections witnessed that are specific to selling Pureplay SaaS in a Fortune 1000 Enterprise: Internet access blocking, locked down PCs (no ActiveX controls or Flash animations), disk space quotas, etc.
Part 3 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). 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. Mention solutions to their problems. Do not get stuck on a technical solution that doesn't fit with your customers needs. Meet the immediate needs of your customer by building in Utility Pricing to your application and/or architecting a Hybrid SaaS system.
The Elusive Part 4 - Economies of Scale and SaaS
A big selling point for SaaS is the economies of scale the hosted solution provides. This is true, especially at the data center level. I seem to have missed the boat on the economies of scale argument, or so I have been told. However, when working with Enterprise customers who do not need their software vendors taking over their infrastructure support costs, why would the SaaS vendor take on this burden? Perhaps you would be happy with 35% margins when handling all of the support costs. Your investors would throw the Economies of Scale book at you when they find out you could have been working with 60% margins by not taking on the additional support burden.
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? (a great discussion of this if found at 35:42 of this podcast from SaaScon) 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.
Starting a software company from scratch, on-premises or SaaS, is no small task. The barriers to entry into the Enterprise software market are significant to say the least. To top it off, there are a number of things that can hinder adoption of your solution in large corporations, putting a stop to your venture before it ever starts. Below is a list of five "issues" witnessed when selling SaaS solutions to Fortune 1000-sized companies. Assuming you have everything else in order, be prepared to address these objections..
Oh, you're a "start-up".
Of all the issues that have come up, this is the one that you simply cannot avoid or steer around. I have always addressed it openly and to the point. "Yes, we are a start-up", I then tell them that this is something we have thought a lot about; how do we convince our client that we are the ones they should take a chance on? I always tell them that "I can't go back in time five years and start then, I wish I could".
As much as SaaS vendors like to talk about "low sunk cost" in selling SaaS solutions or the flexibility of on-demand pricing and being able to drop the service at any time, the reality is the company who says "yes" to you isn't just making a monetary investment in you; they are investing their time and resources in your product. They are not looking to "just switch" if they aren't happy. Regardless of licensing or contracts, they do not want to have to find another solution.
The biggest issues with a start-up is that of sheer existence. Will the vendor be around beyond next week? This is a real concern to customers and, frankly, it is warranted. There is little that can be done to alleviate the chances of existing for a long time. The first is to show the customer the $20M in fresh VC money that was just deposited. That should release some of the pressure, although in reality it probably shouldn't. Barring that kind of funding to show off, the only solution that makes sense is to take out an insurance policy for your customer. Put your source code into escrow with the beneficiary listed as your customer. This way, if your company goes away, at least the customer can take the software and continue to support, and develop it, internally. The software escrow process is actually quite extensive, as it requires both source code and binaries, installation manuals, checklists, and the developers personal contact information.
After the existence hurdle comes reliability concerns. With everything running on "your network", how can the customer be sure of 24/7 access to the system? The best bet is to partner with a reliable hosting company, preferably one that understands your business model and can provide more than just hosting space. There are companies out there called SaaS Enablers, such as OpSource, which combine everything from server hosting, on-site DBAs (who learn your schema and can offer performance improvement tips) to first level tech support for your application. OpSource also offers 100% uptime guarantees and you can have your customer's IT staff talk to someone there if they have questions about the data center itself. This is my preferred method for launching a start-up SaaS business, but there are other ways. You could build your own data center, and if you have a great deal of VC funding, perhaps that is the way to go. But being able to show 100% uptime guarantee, and back it up with referenceable accounts, is the key to overcoming this objection.
Using a company like OpSource also addresses the scalability and support questions your clients will have. If you architect your product correctly, OpSource can monitor your application and scale it where needed on-demand. If you need more application server horsepower or more database storage, those resources can be allocated on-the-fly, ensuring your system maintains stability and integrity. (note... I am not a pitch man for OpSource; they just happen to be great people with a great service and they have been very helpful to me).
Those objections, existence, reliability, support, and scalability, are really the most difficult to address, the first one being the hardest. Never try to skirt the issue of being a start-up; explain what you are doing to alleviate the potential problems and get through it. While I have seen those as objections, I have not seen them as show stoppers. The following I have seen as show stoppers.
In Part 1, the Myth of SaaS Ubiquity was addressed and dispelled. It is simply not the case, and the following objections to your SaaS offering will make you scratch your head and ask if you are still in 1994. The first stumbling block in getting your SaaS offering in the door is going to be the antiquated corporate policies in place. These will include Internet access blocking, locked down PCs (no activeX controls or Flash animations), disk space quotas (severely limited local disk space), and more. The best bet as a SaaS vendor is to include someone from their IT department from the beginning. In fact, if you provide a line-of-business application rather than an Enterprise support product, you may be able to get the IT department to champion your product and do a SaaS pilot. If their IT personnel are exploring the blogosphere, perhaps they believe SaaS is ubiquitous and feel left out!
Outside of the legacy controls still present in many large companies, there are some other factors that are present in just about every company, big or small; an internal need to justify infrastructure expenditures. If the CIO six months ago signed off on $2M worth of new server hardware, the last thing they are going to be looking for is software that does not run on it! Whether recent or not, the internal investments must see a return, and SaaS does not fit the bill. Remember, if they can't justify that expenditure, they might not get more money down the road, and that is simply not going to happen.
Finally, and perhaps the most difficult hurdle to overcome when pitching SaaS delivered software, is the job protection angle that the leader of the IT group might take. Why would the IT Manager want to give up control when that would mean less headcount, which leads to smaller budgets, which leads to smaller salary and smaller bonuses? If you are selling to the C-level, talking about reducing FTEs can be a great thing. If you are selling to line managers and Directors, this is the slippery slope theory in action. They do not want to give up control and will hold on for dear life and at all costs.
What those objections have to do with Vendor Sustainability in the SaaS space is elementary. Focus on the needs of your target market. If you are set on being a Pureplay SaaS vendor in a market that does not like Pureplay SaaS vendors, you will fail. At the same time, if you are in a market that does not need Pureplay SaaS vendors, you might not fail, but you will certainly spend more money than you have to; why take on any more of the support costs than you absolutely have to? Part 3 will focus on a couple of ways to appease those Enterprise clients who aren't keen on your SaaSy ways.
The definition of Pureplay SaaS is where the SaaS vendor offers a completely hosted system with the customer needing nothing more than a standard PC with normal input devices to take full advantage of the offering. If you live in the blogosphere, you might think that SaaS is ubiquitous in the Enterprise by now and that on-premises software is a thing of the past. In fact, SaaS is so ubiquitous and it is almost old news, and you are seeing more of the XaaS variants rearing their ugly heads. That is simply not true. While SaaS is certainly growing, it is not the norm yet as many pundits would have you believe.
This series is to help Enterprise SaaS vendors with two potentially business-stopping problems; scalability and sustainability. I'm not sure many people are looking at these problems when planning their SaaS offerings. By examining who actually needs SaaS versus who might just want it, a bad scenario for the Enterprise SaaS vendor may be avoided.
Who needs Pureplay SaaS? If you look at the major benefit that SaaS brings it makes sense that the low-hanging fruit will be in the consumer and lower-end SME markets. I'm not going to address the consumer market because it is not one that I understand well. I understand business, so I tend to only play in that arena. The market that I do understand are the SMEs. Rarely do SMEs have a well-defined technology infrastructure (and even more rarely do they want one), so a SaaS offering in the CRM, Supply Chain Management, or vertical-specific space makes sense for them. They can offload the support costs onto the SaaS vendor and allow them to focus on their core competency and just use the software. This is the way it should be.
Why do you want to be a Pureplay SaaS vendor if you are not targeting those market segments? Perhaps you are caught up in the hype. If that is the reason, you need to examine a couple of things that you might not have thought of. One of the biggest "selling points" of SaaS as a software delivery model is reduced support costs for the user. This is great, but if you are selling to a company that already has the infrastructure to support on-premises enterprise software, why would you take on those support costs yourself? The fact is, as you add customers and users to your system, your support costs go up. Whether it is storage or bandwidth, you will end up paying for your success.
Aside from the hard support costs of taking on all of the burden yourself, you also take on all of the tech support issues. It is the norm that on-premises software will be supported in house as much as possible. If the problem cannot be resolved internally, someone on the technical team of the organization will call the vendor and work through the problem. The technical team has a vested interest in making sure that the problem is resolved in a timely manner since they "own" it. With SaaS delivered software, who supports it? More than likely it is the SaaS vendor handling all support, from first level up. Even if you have worked out an agreement with the customer's technical team, how do they actually support the product, even first level? Can you as the SaaS vendor really handle these support costs long-term? What is more, large-scale on-premises software is almost always accompanied by a support contract. It is much more difficult, though not impossible, to sell one of those when you have a Pureplay SaaS product?
While it may be a long-term company killer to take on all of the support costs yourself, it may in fact be a company starter-killer. In some large enterprises you may find being a Pureplay SaaS vendor to actually hinder the adoption of your product. That will be addressed in Part 2.
Most people in technology these days are familiar with, or have at least heard of, SaaS, or Software-as-a-Service. I have recently seen Integration-as-a-Service or IaaS, and witnessed a proposal for BPOaaS, or Business Process Outsourcing-as-a-Service. The latter was more of a tongue-in-cheek sort of comment. This means it may be time to revisit the x+ variable acronym system, the x+VAS.
I decided to post about the creation of the term XaaS (pronounced Zaas), meaning whatever (the variable "x")-as-a-Service. I then decided to Google this little gem and found... duh duh duh... someone already coined the term. And they made a video to:
After we come up with enough XaaS acronyms, as more and more "things" move the "as-a-service" model, hopefully we can drop the "aaS" and just call it, once again, Software or Integration or BPO. Hopefully this will come as part of the understanding that we have dropped the silly legacy pricing / licensing model in favor of the more liberal, and in my opinion more profitable, utility pricing model.
Great post over at Saas Blogs about traditional distribution channels and SaaS or On Demand applications. I left a comment about how the Mailing Industry works with dealer networks almost exclusively and how that will be a large hurdle to overcome for SaaS players.
I help companies bring their Software-as-a-Service (SaaS) and Web applications to market by leveraging the Morph Application Platform and Morph AppSpaces, the first Platform-as-a-Service (PaaS) for Ruby on Rails.
I am located in Dallas, Texas. Contact me via email.
| »
