The Age of Disposable Software

I have a non-green confession to make: I love paper plates.

Paper plates, paper napkins, plastic forks and knives. They're always fresh and clean. Bring them outdoors on a picnic, no worries of losing or breaking anything. Blithely sully them with cheeseburger and chili dog, potato salad and watermelon — and then simply throw them away. No cleaning, no optimizing the dishwasher. It's an absolute miracle of modern living.

Now, while I've curbed my desire to use paper products for all meals — to protect the environment and my marriage — I still harbor a love for the Zen-like simplicity of disposability.

That carefree power of disposability came to mind as I've been preparing a Marketing in the Cloud webinar for MarketingProfs (Tuesday, August 31 at 2PM EDT, click here to register), a fresh take on my marketing in the cloud post from a couple of years ago.

In reviewing the pros and cons of software-as-a-service (SaaS) — contrasting the "on demand" model of SaaS to traditional "on premise" software installations — I believe that one of the biggest advantages of SaaS is the option to throw it away.

Throw it away? That might sound a little strange at first. What I mean is that if you choose a particular SaaS package, say Conductor for SEO monitoring and analysis, and then 6 months later you find a new package that you like better, say BrightEdge, it's relatively easy to drop one and replace it with the other. (Or vice versa, from BrightEdge to Conductor — I offer no value judgement of either here, just picking an example.)

There are a number of reasons why migrating from one "on demand" SaaS package to another can be easier than changing from one installed "on premise" software package to another:

• no "system requirements" to use the new SaaS
• no capital investment in the old SaaS or the new one
• no duplicate hardware needed for migration
• less investment in custom software extensions (SaaS generally discourages creating them in the first place)
• no inertia from your IT department ("if it ain't broke, don't fix it") — since they may be minimally involved in the SaaS acquisition or operation, if at all
• low contractual obligation: most SaaS packages let you cancel with 1-3 months notice

Frankly, the three things that are likely to hold people back from switching SaaS packages are:

• legacy asset mindset: we're still used to thinking of software as a semi-permanent asset rather than a disposable on-demand service
• historical data: we're reluctant to lose the historical data in one SaaS that may not port fully (or at all) to the new one
• institutional knowledge: we've learned how to incorporate the current solution into our work and worldview

I would contend that the first of these is an anachronistic psychological hang-up that we can choose to overcome. Jason Fried of 37signals wrote a great post a few years ago, Growing in vs. growing out, that advances the idea of temporary software:

It's ok for software to be "temporary." Everything else is temporary, why not software? You probably don't use the same computer you did 5 years ago. You probably don't live in the same apartment or have the same car either. And you may be in a different relationship too. Why are software companies afraid if people grow out of things after a while?

It's the age old bias we have for sunk costs that we constantly need to conquer.

As for historical data, while I agree that some has value, I also believe that much of it is wasted. It languishes in data warehouse silos, gathering cobwebs, without really being tapped in the missions of the present day. More often than not, it's not powering us from the rear, it's dragging us down.

Avinash Kaushik, web analytics guru extraordinaire, has a great section on "The Goodness of Not Worrying About History" in his Web Analytics 2.0 book:

If you don't worry about history, then you are not tied to the past. You can think smart and move fast. If your current data will have less value in the future, then you will cherish the now more and try to get something valuable out of it.

Letting go of history also gives you the freedom to sever ties to legacy systems, legacy tools, or legacy data. You can more forward to better systems, tools, and data much faster than our sisters and brothers in the traditional world.

You can have a lot more fun because you get to learn, adapt, get value, and move on. It is damn exciting and damn liberating!

The core data in your CRM is probably well-worth protecting (so choose your CRM wisely, even as a SaaS). But as you move outward to campaigns, analytics, web experiences, social media, and beyond, the data of the past — other than at a very high level of performance metrics — quickly loses value. Data suffers from a high rate of entropy because the context in which that data even has relevance is constantly in flux.

Last year's social media stats typically don't tell you much about what you should be doing today. So why let it hold you back in adopting a better software solution that was just released this week?

Avinash's quote also cuts to the heart of the hurdle of institutional knowledge. Here in an agile world, we probably have less of a problem with losing institutional knowledge than we do in lacking institutional learning and adaptation.

The market is evolving at breakneck pace, with new competitors springing out of bed every morning, with zero legacy hang-ups, eager to snap up your audience. The power of SaaS — and the age of disposable software — is that it makes it easier for you to harness the leading edge of innovation. But SaaS just helps with the plumbing and the economics — you still need to provide the activation energy to break free from the past and embrace the new.

To quote a line from a Kevin Smith movie, "You face forward, or you face the possibility of shock and damage."

Okay, paper plates and Kevin Smith — those are enough embarrassing revelations for one blog post. But to my main point, it's good to move on.

Comments

[Dharmesh Shah]

Great article, and I'm a believer in not resisting the natural process of customers outgrowing a particular software solution.

But, I'll push back on one point, and another metaphor to the mix. When I moved to Boston, my wife and I changed residences 4 times in 4 years. We were trying to learn more about the city before we committed to something. And, in a way, that was great.

But, in a way, it was a horrible waste of energy. It seems we spent more time searching for places, moving into places and settling in than enjoying our new city.

So, I like the idea of temporary software, but I think it's important to watch that we're not spending more time "moving" than getting actual business value.

[Scott Brinker]

Hi, Dharmesh -- thanks for the comment! You make an excellent point. If you're spending too much time moving, you're probably not spending enough time doing.

On a continuum from staying stuck with one software package for a decade to switching packages every month, there's many a happy medium along that curve -- exactly where depends on you, your organization, your market, the application domain, etc.

One of the great things about SaaS is it lets people move further down that curve than on premise software had. But I agree that switching should only be done if it's likely to generate actual business value. The problem with getting too hung up on legacy attachment to software is that it can bias you against the value that new software can provide. If you can ignore sunk costs (always hard to do) and simply weigh the options of staying or moving, I think you're actually able to better capture business value.

Hopefully you're happy with the place you and your wife finally settled in, and that the investment you spent in experimenting with different locations ultimately paid off. And if a better house comes along that inspires you, who knows, maybe you'll move again?

[Seth Besmertnik]

Hey Scott - thought provoking post, thanks for taking the time to write it up. There are different levels of pain, imo, when switching out of SaaS products - depending on which they are. However, from a financial perspective - you typically are committing less on a contract basis then in the enterprise model...but this can be a material sum. Most major SaaS co's like Salesforce.com, Successfactors & Omniture - all require a year minimum and in some cases longer...so there is a pure cash burden to drop something in the middle of a contract.

But going beyond pure dollars & cents, there are many points of stickiness/switching cost in a great SaaS product beyond historical data. I'll take a stab at outlining a few, for thought:

1. Integrations - our customers integrate Conductor with various other vendors & internal reporting systems - and these integrations take time, work & money to get right. It's not that easy to just rip them out and switch to someone new. Some of these processes are critical to making their marketing operations function and they would need to buy two solutions in parallel, do all the integration, then cancel the other - to make a switch work. This could take a long time and the new product would need to be 2-5 times better to make this work.

2. SaaS product that get smarter based on historical data. We configure forward looking scores and algos based on customers historical data, so in effect, the product becomes better over time. Going to a new system can lose this benefit.

3. Curation of data - customers spend a lot of time curating and imputing privileged data into a system. This can happen slowly over months and years. Very difficult to just stop and switch to another application - and start this all over.

I can think of several more and I guess this is what separates the best in SaaS from the transient players.

Great post and thoughts.

[Stuart Crawford]

Scott, I have been following your blog for quite sometime now and this post is spot on. The technology world is evolving. I was just at the CompTIA Breakaway event a few weeks ago and most of the talk was on the cloud and how IT providers are going to respond to the ongoing threats of cloud computing or how they are going to embrace the cloud. Many of scared because they risk losing significant revenue and the ones who understand it are jumping up and down because they are getting their share of the revenues by delivering software as a service.

Cheers

Stuart Crawford
MSP Marketing Professional
http://www.mspmarketing.ca

[Scott Brinker]

Hi, Seth -- great comments.

First, let me say that in my hypothetical example of someone switching from Conductor to BrightEdge, I just grabbed two names almost at random. I regret that, as it implies a statement on the competitiveness between those two packages which wasn't my intention. Everything I've heard about your product has been great, and as far as I know people are just as likely to switch in the other direction. I probably should have just used generic "Product A" and "Product B." I've added a sentence to that paragraph to clarify: Or vice versa, from BrightEdge to Conductor -- I offer no value judgement of either here, just picking an example.

You illustrate great examples of how even SaaS can have "sticky" incentives. I think we agree that they're generally less than the old "on premise" enterprise model -- think back to those ERP systems from the 90's that are still firmly embedded in their host companies. SaaS may have custom integration and configuration, but the scale of such customization seems much more in check.

Granted, that still may fall short of being "disposable." But I think the trend is shifting in that direction. Part of this is being driven by the tremendous change in the overall digital marketing space. Part of it is the explosion of competition in marketing SaaS. And finally, I think part of it is (slowly) changing expectations of SaaS buyers.

Hey, the more sticky your product is because of the value it delivers -- smarter performance based on legacy data, better ways of leveraging that historical data to generate real present day value -- all the better! But in those scenarios people are sticking with you because of conscious choice, weighing their present options. They're not staying because of obligations or sunk costs.

I know, the year-long subscription contract is popular in enterprise SaaS, and for good reason. But I think that's a dimension of stickiness that is highly vulnerable to competitive pressure, so I wouldn't want to count on it.

Ultimately, the best SaaS providers will have high retention rates because people simply love using their software. In fact, they will benefit from the ease by which people can switch from lesser products to theirs. I know that's my company's mission -- and it sounds like yours too.

Thanks for the comment!

[Scott Brinker]

Thanks, Stuart -- greatly appreciate the positive feedback!

Aye, disruption is a wonderful or terrible thing depending on which side of the blade you're on. I've been on both at different times, so I have a lot of empathy for those who are on the pointy end. But stepping back, it's hard not to get excited about where the big picture is headed.

[Arpit]

The beauty of SAAS is that it not only empowers the user but also SAAS provider as well as he would always have power to turn off the services due to non-payment or after the on-demand contract expires.

[Tracy Thomsic]

Thanks, Scott! This article is a revelation to me, and none too soon, as I'm dealing with this very situation: deciding between on- and off-premise options for a new CMS and other marketing technologies and services. The hurdle we face with SaaS, PaaS, or IaaS solutions is the traditional CAPEX/OPEX accounting model, which often argues for on-premise solutions because they can be capitalized. The CAPEX/OPEX paradigm needs to change to support service-based solutions in today's technology-dominated economy.

Do you have any insights on how corporate marketing/digital experience teams can overcome the capital expense hurdle to adopt SaaS solutions?

Thanks again; great post!

[Scott Brinker]

Hi, Tracy. I'm glad the timing of this was fortuitous for you.

I'm glad you asked this question, since throughout my post I assumed that people would prefer *not* to have to deal with software as a capital expense. But since capitalizing software investments has been such a mainstream enterprise practice for so long, that assumption needs better explanation.

Here are three reasons why SaaS as OPEX should be better than on premise as CAPEX:

1. COST. The economics of most SaaS solutions should be such that if you took a comparable on premise solution, added in all the hardware and installation, then divided that over your depreciation period (5 years?), and then to those monthly costs add maintenance and operational expense, support contracts, upgrade fees and overhead, etc., the SaaS solution *should* be equal to or less than the costs of the on premise solution. There's a lot of hidden costs in on premise operations that you have to be careful to account for. When you account for these, the focus of the SaaS provider -- their dedicated mission is to operate their software in a highly optimized environment -- should give them much better economies of scale, a good portion of which is passed along to their customers.

2. SPEED TO ADOPTION. Typically, capital expenses require a longer decision-making process than operational expenses (within reason). As soon as you add a "CAPEX committee" into the mix, it's hard not to slow things down. And then, even once the purchase is approved, you still have the physical installation, which now invariably involves IT infrastructure. With SaaS, as soon as you've found that right solution that makes sense at certain price/monthly expense, you can switch it on as fast as your team can move.

3. EARLY EXIT. While you're still depreciating a capital expense, it's usually a lot harder to say, "let's write this off and go with something else." Even if it technically might make sense from an economic perspective -- and may not, depending on far upside down you are on the investment -- it meets a lot more organizational resistance. With SaaS, you don't have to worry about this dimension at all. You can turn off one subscription expense and switch on another with minimal impact on accounting.

There are certainly other reasons to go with SaaS that aren't just accounting, such as always having the latest version in operation, minimizing support finger-pointing (the vendor is always fully responsible), etc. But breaking free from the chains of CAPEX is a big one in my opinion.

If you hear counterarguments to this, I'd love to discuss them.

Thanks for the comment!

[cleve]

Thanks for the post Scott. A great article that has resulted in even more thoughts from community.

I think the earlier comments pick up the issues around data and software. I feel that a company's data is a snapshot of your business at any moment in time. SaaS (software) is just a means to move it from one state to another. With that in mind, companies do get a little edgy around someone else managing that data on their behalf. I've heard of companies that realise that they have so much data in the cloud that it does not make sense to store it anywhere else - i heard the term 'cloud bound' somewhere. Others, periodically test that they data can be managed by other SaaS providers, just it case their current provider disappears for one reason or another.

The stumbling block I have is always around SaaS vendors provide adequate integration strategies and/or the means to import/export data they manage. Scott, is this something that you have come across?

PS: I'm a SaaS fan, but as always its a easier sell to marketing but an uphill struggle at times for IT.

[Scott Brinker]

Thanks, Cleveg.

"Contingency planning" for SaaS solutions is important. Mission-critical SaaS, such as CRMs like Salesforce.com, are possibly in a different category than "nice to have" SaaS solutions. For instance, if PostRank went away tomorrow, I would miss it terribly; but I could pick up with something else relatively quickly. Evaluating SaaS vendors along that continuum -- and periodically revisiting your own continuity strategy for the functions they provide to you -- is a good idea.

I do agree that SaaS vendors typically provide less integration options. I'm torn though, as this in my opinion is as much a plus as a minus. The advantages of having fewer integration touch points -- particularly custom integration touch points -- is that it's easier to stay in the flow of the latest feature upgrades and/or switch pieces in your ecosystem (either that SaaS or one of the other pieces). The downside, obviously, is less custom integration tailored to your unique business operations.

Ideally, I think SaaS vendors should offer as many standardized API and import/export features as necessary to make their solution open and interoperable -- but that SaaS customers should resist the urge of getting too customized on top of that. "Light customization" or a "loosely coupled architecture" if you will.

Customization has value. But agility has value too. And for better or worse, the SaaS playing field shifts the balance towards the latter.

Agreed that IT has issues with SaaS. But, to quote The Matrix to my IT compatriots, "This is the sound of inevitability."

Thanks for the comment!

[Maria Tseng]

Pricing has always been a tool to increase stickiness. MBA-schools will have to improve the curriculum for pricing strategies. One can get pretty creative and 'rapacious.'