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:

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email Computerworld
• Follow Computerworld on twitter

• Share
  Share this article

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark