5 rules for guaranteed failure at SaaS, without even trying

We're all too familiar with outages in Google's Gmail, Salesforce.com and the RIM BlackBerry network. Recent failures by Apple MobileMe, Jott and Cuil online-delivered software demonstrate that software-as-a-service -- or Software+Services, as Microsoft would call it -- isn't just a matter of putting your software up on the Internet, gathering users and declaring your Version 1.0 ready so you can start charging for services. The three recent examples of MobileMe, Jott and Cuil clearly demonstrate other major pitfalls in trying to deliver online software. Are all online software services destined to repeat these same mistakes, or will we learn from the mistakes of others? I certainly hope the latter.

How to fail at SaaS Rule 1: Forgetting the fundamental problem you solve

One of my own rules in product development is that all the bells and whistles don't amount to a hill of beans if the product doesn't solve the primary need it's intended to solve extremely well. A crappy word-processor with a great spell-checker won't stay on users' desktops for very long. A cool, feature-laden SmartPhone must first be a great phone, then provide handy applications and whiz-bang features.

Cuil clearly violated this principle by serving up search results in a new, fresher, media-rich format, but search results that were not only inaccurate but flat-out wrong. Users might be dazzled by the new user interface, the lack of advertising or the possibilities the product presents, but you're not going to use the service if the results are consistently wrong, and very wrong at that. In addition to building up a user base and associated revenues, Cuil now has the problem of overcoming a history of serving up inaccurate search results, a fundamental problem not likely present in its original business plan. Think that product-launch false start didn't cost Cuil a lot of money and potential market share? Think again.

Your product's not ready, SaaS or not, if it doesn't solve the core problem (and solve it well).

How to fail at SaaS Rule 2: "Big launch fever" or Overloading your 1.0 coming-out party

As vendors, we all want to make a big splash when launching a new product or SaaS service. Launching a new software version, new feature, new product add-on, and moving from beta to a 1.0 release -- the more, the better, right? Not necessarily, in the world of SaaS. More is better doesn't apply if the service won't survive the launch. Just ask Apple .MAC users who migrated to the MobileMe service only to suffer repeated downtime.

Apple really piled it on, suffering from "big launch fever" by launching the iPhone 3G and iPhone software update (causing a whole host of problems provisioning new phones and downloading the update via iTunes), launching the new MobileMe service and transitioning .MAC users to MobileMe, all in a short span of time. Did MobileMe really need to come out within a week of the iPhone 3G and iPhone software updates? Did .MAC users really need to be cut over immediately? Users suffered repeated outages and were sometimes down for days, while the MobileMe service has experienced repeated downtime, cutting people off from their business lifeline: e-mail.

Maybe we should learn from Apple's debacle (and Jott's, as we'll see in a moment) and not try to do everything all at once. Bottom line, what we really need is a SaaS/S+S Hippocratic Oath:

Page Break

How to fail at SaaS Rule 3: Extended betas do not a ready product make

We've all led ourselves to believe that one of the things you do to get your online SaaS service ready for prime time is to have a long, extended, free beta-test period. Google taught us that (expect its stuff rarely ever comes out of beta). During that time, we gradually build up a user community (sometimes even a quite large one), roll out new product features and software updates, resolve bugs commonly experienced in new software, work out the kinks delivering an online service, and help scale the systems to handle large and possibly unexpected user demand. It's all good, right?

Jott, an online voice-to-text to-do-list service and BlackBerry app that I've used for quite some time, was in beta for more than 2.5 years. Over that time they'd built up thousands and thousands of beta users. Come 1.0 launch day, what happened? Their service couldn't handle it, and they were down for nearly two business days. Like Apple, Jott suffered from "big launch fever" (see Rule 2) by trying to launch the 1.0 product version, a new Outlook plug-in, Express desktop software and premium paid-for services. As a Jott user, that's all great and I'm really happy for Jott that they have this really cool stuff coming out, except for the fact that I couldn't even get to the site for a day and a half to access all the tasks I've been tracking in Jott.

Jott's founder and CEO hit the nail on the head in his apology letter to "early adoptors," a euphemism for "you get our stuff for free so you don't have much right to complain" (which is wrong as well -- see Rule 4):

So, just because you've had a long, extended beta doesn't mean you're ready to launch your product or overload the launch with "big launch fever."

How to fail at SaaS Rule 4: Users will put up with it -- it's free, after all

Like any euphemism, there's probably some truth (or at least there has been up until now) in the belief that users who get something for free will put up with a lot more than would someone paying to use an online service or software. If you were the only free service and the next alternative is a very cost-prohibitive option, that's one thing. But in a world of increasing SaaS alternatives -- and of course the option of returning to what you were doing before (when that exists) -- free doesn't hold users nearly as captive as it once did. The other added factor is that SaaS usually makes it easier for users to switch between services. Suffering from poor software or service quality? C'ya, don't want to be ya. If MySpace tanked today, they'd all be on Facebook by tonight.

But no matter how low the cost, how high the pain threshold to change, or even user loyalty to a brand (like Apple), users will only put up with so much and then they'll switch, oftentimes never to return. Today, my primary e-mail client is Outlook, not an online service like Gmail or some other online service. Even given ALL the frustrations I have with Outlook, and believe me there are many, I can't and won't tolerate the downtime problems that Gmail and MobileMe users have experienced.

What product people and those in the decision-making chair forget is that user frustration isn't a blemish, it's a callus that builds from experience after experience. Each experience, no matter what the source of frustration, thickens that callus, desensitizing the users from why they like (or liked, rather) using your product. At some point, users can and will move on, applying the "life's too short" principle. Every day the fact that something is free diminishes as a compensating factor.

Page Break

How to fail at SaaS Rule 5: It may be hosted software, but it's still a product

Just because your software is delivered as SaaS, S+S or on a subscription basis doesn't mean you're immune to all the fundamentals and best practices of delivering products to customers. Matter of fact, those principles can be even more important because it's so much easier to gain and lose customers. And unless you're delivering something truly unique from the user's perspective (not yours), users will just as easily move on to the next option, leaving you on the heap of "been there, done that" virtual shelfware.

Those who forget this, taking shortcuts in the belief that ALL the rules have changed (and many have, btw, but not all) when it comes delivering software online, are destined to learn the hard way, as users vote with their browsers and eyeballs to spend their time with someone else's product that works or solves their problem better.