Maybe you saw Aaron Levie's article about building an enterprise software company that "doesn't suck". (If not, here's a link) You have to give Aaron credit: he's done a great job getting and keeping his company, box.net, in the news. Although I do think people should have to acknowledge Guy Kawasaki for showing how to capitalize on the shock value of certain words as a means of getting attention.
Aaron's argument can be reduced to this:
- Enterprise software companies suck. They're slow to release new software, the software they release is bloated with features nobody uses, and they lock the customer in via software that's complex to install, manage, and configure.
- We aren't an enterprise software company (they don't quite say what they are).
- So we don't suck.
Let's ignore the logic error in this argument (I'll leave it to the reader, as my calculus textbook used to say). Maybe more to the point, if this was the rallying cry for my company, I'd say we're setting the bar pretty low.
But let's get back to this question, asked but not really answered by Aaron: what makes the new breed of cloud-based or software-as-a-service companies different—and better—than older-school software companies? Here are three factors:
- The "freemium" go-to-market and revenue model
- The open source software development model
- The cloud-based service delivery model
The "Freemium" Revenue and Go-to-Market Model
In the "freemium" model, you offer a free version of your service, with various opportunities and incentives for the user to upgrade to a paid version. For instance (see this article) it's increasingly common for a game to be offered in a free version, but require in-application purchases to achieve certain game objectives. In other instances, a certain level of service is free, but a greater level of service requires a payment. As an example, YouSendIt offers a free version of its service for sending large files, but requires a payment if the user wants to store files on YouSendIt's servers for more than a few days.
So the revenue model is easy to see.
- Build a large base of happy users.
- Continue to add value to the service (yes, even though it's free).
- Continue to engage your users.
- Build reasons to convert from free to paid into the product.
For those more algorithmically inclined: multiply an increasing base of users by an increasing percentage and you get doubly increasing revenues.
Of equal and maybe greater importance is the "try before you buy" go-to-market approach embodied in the "freemium" model. You can sign up for the service and try it for free, before committing to a paid use. This simplification of the purchase process works especially well when the service can be easily understood by the end user. It's easy for a new user to figure out how to send a file using YouSendIt's service. During the course of a two-week free trial, a user can experience the service repeatedly, developing enough experience with the service to make a purchase decision.
But what if the service is more complicated? To take an extreme example, Oracle could offer a free trial of its software, but considering that most companies take months to install, configure, test and run particular Oracle applications, Oracle wouldn't be served by offering a free trial for a few weeks.
And not to wander too far from the discussion, but companies like box.net, Dropbox, and YouSendIt are primarily targeting the end user. That's fine when the user is also the chooser (as in consumer and smaller business segments). But what happens in the typical enterprise case where the user, the chooser, and the purchaser are all different people? These different actors have different needs and motivations. To take the box.net example, suppose I want to set up a shared folder. As a user, it's easy to do. I get an account, create a folder, upload my content, and send a link to the folder to the parties I want to share it with. That's fine for the user, but what about the CIO, who's concerned with issues like keeping data private and secure? How does the CIO make sure that users aren't inappropriately sharing information?
This dynamic between the user and the CIO complicates the "freemium" model. But CIO's acknowledge that the days of controlling what applications (and devices—thanks BlackBerry and iPad!) the user can access are ending, if they're not over already. So it makes sense to treat the enterprise user more like a consumer (think: fickle, unwilling to endure training before using the application) and think of the software/service sales process as occurring in two distinct steps: convincing the user and then convincing the CIO.
The Open Source Software Development Model
Use of open source software is a trend that's been developing over a number of years (remember Unix, the OS before Linux?). It's easy to see why a startup would adopt open source: it's cheap or free, provides solutions to any number of base software problems, and lets the startup focus on developing software that delivers its unique value. In a world where time-to-market determines whether your company lives or dies, you can't afford to take time (or waste investment dollars) to solve problems that already have "good enough" solutions. At Daintree Networks, we used MySQL as the database engine for our energy management application because it allowed us to get a working application put together much more quickly than if we had decided to adapt or create our own database management system.
Open source software is not a panacea. Software developers aren't enthusiastic about taking on someone else's code. And if the software isn't well documented or tested, the benefits are more difficult to realize. Open source does require companies to work through issues such as ensuring adherence to intellectual property rights and the ability to maintain software libraries over time.
The Cloud-Based Delivery Model
The notion of delivering the service, vs. delivering the software that runs the service, has been evolving (and changing labels) for some time. More and more companies are adopting cloud-based services—storage, computing, human resources, media delivery, salesforce automation and mobile device management are just a few examples. Aaron's article repeats one of the common arguments for the superiority of cloud-based software over enterprise-deployed software: speed of software updates. Aaron paints the picture of software updates that happen daily or weekly, vs. updates that happen maybe twice a year in the enterprise-hosted model. Aaron doesn't account for software updates delivered via patch releases, which can happen frequently. But he's right in characterizing enterprise-hosted software as revolving around a multi-month delivery interval. There's no denying the rapidity of software updates in a cloud-based delivery model, but it's important to understand when such rapidity is beneficial, and what its limits are.
And before we go there, make no mistake—software delivered every week is not inherently better than software delivered every six months. Design is design, coding is coding, and while more recent approaches to requirements management and project management (Agile chief among them) are certainly valuable, these approaches don't inherently correct for mistakes in design and execution. I remember when I was an Engineering Manager at Nortel Networks, and asked one of my development managers about our adoption of Object Oriented Analysis and Design and use of the C++ programming language: what would it mean for our design productivity? "Dan," she said, "it just means we can make mistakes 30% faster than before."
The advantage of frequent software deliveries (say, once a week) is that you get updates into the market quickly, and get feedback quickly. For changes to user interface and user experience, this is fantastic. You can deploy the software (to all or a subset of your users) and measure patterns of usage—the best kind of feedback. If the feedback is great, you do more. If the feedback is not so great, you correct, and roll back your software if necessary. Users get access to new capabilities more quickly, increasing customer loyalty (presuming a favorable view of the latest changes) and building value in the users' minds.
Another advantage of frequent software delivery is that it forces the development team to appropriately size the work effort. Requirements can't get overly complicated before they're broken out for delivery in more than one "sprint". Likewise, the design has to be kept simple in order to be accomplished in time. It's the software development version of a woodworking axiom: "measure twice, cut once."
But some problems are just harder to solve, and harder to break into small weekly development "sprints". Designing the database that drives collection and processing of large volumes of data is a big effort. Not everything can be accomplished in a weekly design cadence. And (as I've seen), the decision to implement a "good enough" solution now in order to get into the market can come back to haunt you as your service grows beyond the scale that such a solution can accommodate.
We're Way Better Than Not Sucking
The gist of Aaron Levie's message was "box.net doesn't suck." OK, thanks for that. But a cloud-based service provider can make a much stronger statement.
Go Big or Go Home
Yes, the phrase is a little dated (sorry, JMac). But if you're delivering your service using a cloud-based model, you're fully committed. You either make it work or you go out of business. When Hernando Cortez landed in Mexico with his expeditionary party, he had his ships burned. The message to his troops was clear: we either succeed in our conquest or die trying. Retreat is not an option. Companies like salesforce.com and NetSuite have to succeed at the cloud-based delivery model; they have no other choice. Companies like Oracle, Siebel or Adobe don't have to make the same all-or-nothing commitment (which, some argue, means they'll never succeed with cloud-based services.)
It's Not Valuable Until It's Used
The value question for enterprise-delivered software—is this valuable enough to pay for—gets asked maybe once a year. For cloud-delivered software, the question gets asked every month. For the customer, the experience with the value delivered by the software is much fresher in the cloud-based model. This puts emphasis on continuously delivering value.
There are plenty of other selling points for cloud-based services that I won't review here… scalability, availability and so on. What's most important is that cloud-based service providers know that they have to build and sustain an emotional connection with their users if these providers want to succeed. And isn't that the strongest argument for partnering with one of these companies to run your business?