Previous month:
June 2011
Next month:
August 2011

July 2011

Taking Cloud-Based Services Beyond "We Don't Suck"

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:

  1. The "freemium" go-to-market and revenue model
  2. The open source software development model
  3. 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?


Hot Tip: A Discontinuity in...

... the Toaster market.

This has been bugging me for a while, which should tell you all you need to know about my bizarre mind:  what's up with electric toasters?  As I popped the bread out of our toaster this morning, I realized that I've been putting up with its state of non-functionality for maybe three years now.  To be honest, I'm just happy it doesn't catch on fire while toasting my English muffins.

We have one of those low-priced toasters (I won't mention which one, but it's on the chart below).  All we ask is that it toast the bread adequately, pop it up when it's done, and not catch on fire in the process.  You might say we've set the bar rather low in the requirements department.  Heck, we were delighted that it had a "bagel mode".

Of course, within about a year of buying the toaster, the dial that controls how light or dark you want your toast stopped working.  You can set it to whatever  you like, but the toaster will toast your bread to whatever level it deems appropriate.  It's kind of French that way: "No, monsieur, I will bring your croque-monsieur like so."

Fast forward to today.  I was on a culinary parts website, ordering replacement parts for our Cuisinart food processor.  Once I finished up my ordering, I thought I'd see what they had to offer for toasters.  I searched for two-slice toasters.  I didn't get any fancier than that--four-slice models just encourage overnight guests, and we haven't had a toaster oven since we got married.  What I found is in the chart below.

Toaster Prices

What you see is that there are a number of manufacturers and models to choose from in the sub-$50 price range.  And there a couple of choices in the (incredible) $250 price range. (Side note: are the super-expensive ones really that good? Or should I just buy five of the cheap models and replace one every year?)

But, except for one Krups model, there is nothing in between the $50 and $250 price points!  Clearly there's a gap in the market here, ready to be exploited by some socially-networked, ad-supported, iPad-enabled product.  I'm calling on entrepreneurs everywhere to address this gap in the market.  Take my idea and run with it, I ask for nothing in return... except for a working toaster. Or five.


Make Sure Your Product Launches Don't Fizzle Out

Yesterday being Independence Day and all, we decided to drive to a spot in the hills above Gilroy, where we could watch the fireworks without getting stuck in any traffic jams.  And while we weren't the only ones with such an idea, we were still able to view a number of different fireworks productions off in the distance.

Somewhere along the way, my mind began to wander (a common occurrence), and I began to think about product launches that are like fireworks shows.  There's a lot of noise and light, tons of excitement, inspirational words and music, and then... nothing.  The fireworks are over and we all go home.  Sometimes a product launch feels like that: a big party to celebrate the completion of a product or service, and then we all go home.

But a product launch isn't supposed to be the end of something, it's supposed to be the beginning... the beginning of sales; the "return" that balances out the "investment" in some positive manner.  So how do you make sure that your product launch is the beginning of a campaign, and not an event soon to be forgotten?

DSC00026

Companies that fall short in their product launch usually do so because they've only worried about what they have to do internally to be ready.  They worry about things like order procedures, manufacturing readiness, PR campaigns and so on.  What they sometimes overlook is what happens in that magical space between the factory shipping dock and the customer's loading dock.  And while a company's own sales team can be given short shrift as part of a product launch, it doesn't happen more than once before the VP of Sales starts to ask for someone's head on a platter.

Having been a reseller and "channel partner", I've been on the receiving end of new product rollouts and have seen the good, the bad and the ugly.

  • A service gets launched with no foreign currency support--and most of my business is with customers outside the US.
  • A product is announced in the trade press, but the demo kits aren't ready.
  • A company rolls out a mobile virtual network operator service, but the network resale restrictions have not been worked out and communicated to the company's reseller partners.

What's the answer? It's a simple game of "what if".  What if I wanted to sell this new service...

  • Do I know (or can I easily find out) what it does? how it works? what are its benefits?
  • Do I know what "sweet spot" in the market this service is intended to address? Is the manufacturer helping me develop leads in this market segment?
  • Do I know how the service is priced? discount levels? bundling opportunities? What if I have a smoking hot deal but need a price concession... can  I get it?
  • Are my reseller incentives set up? Do they make sense? Are they consistent with similar services from similar companies I do business with?
  • What other services will I be competing against when I go out and sell this service? Do I have the tools I need to deal with competitive issues a prospect might raise?
  • Am I selling to the same people I usually deal with in the customer organization? Or is this a new set of people, with different concerns?
  • Are my support people trained on the service? Do they know how to install it? service it? upgrade it? troubleshoot it?

Try this out with one of your friendlier channel partners.  Ask them the question above, and see if they have what they need.  If they look like they're ready to go, tag along on a couple of sales calls (or follow up afterwards).  See if things went as well as everyone expected.

And if they don't seem to have what they need... get busy!