Do You Read the SaaS Curmudgeons? Do You Enjoy SaaS Schadenfreude?
Posted by Bob Warfield on July 21, 2008
Do you read the curmudgeons? I’m not exactly sure what else to call them, but these are the posts that tell you the new new thing is actually not very good at all. There is always a willing audience for these sorts of things that are the large audience feeling threatened by the new new thing who would like it to just go away. There is little downside risk of being found out wrong because they typically write about the new new thing early enough that there is still time for that new thing to screw itself up. Very often they do too. Every shiny new thing does not take over the world. But even if one does, by the time the new new thing is the established way of life, the curmudgeon’s post has faded from memory.
Playing the curmudgeon is a time-honored way to get traffic. It’s a link-baiting tactic that existed before there were links to bait. I bring this up having just read Sarah Lacy’s and Nick Carr’s posts about how terrible the on-demand business is. Yeah, that Sarah Lacy that didn’t do so well playing the curmudgeon face to face with Facebook’s Mark Zuckerberg. When you want to play the curmudgeon its usually important not to have too many representatives from the new new thing present, it’s best if they can’t take part in the dialog, and they certainly shouldn’t be as smart as the Zuck is.
Nick Carr has a long history of curmudgeoning too, although he swings his bat both ways and frequently attacks the status quo as well. He’s very comfortable attacking the on-premises world with an entire book (“The Big Switch”) and then writing a post like this one that proclaims, “Anyone who thinks the software-as-a-service business is a gold mine is wrong. The economics are fundamentally different from those of the traditional software business – and not in a good way.” Darn! Whichever way you want to deliver software isn’t going to work according to these conflicting views.
The Germans have a word for this curious phenomenon of enjoying the pain of others. They call it “schadenfreude”.
Let’s put the schadenfreude aside and ask, what would a Marc Benioff or Steve Singh be telling Ms Lacy if she was unlucky enough to be plying this “SaaS is a brutal slog” trade while personally interviewing one of them in front of a large audience as she did Zuckerberg? Let’s review the major points Lacy is making about SaaS along the way.
Software sold “as a service” over the Web doesn’t sell itself, even when it’s cheaper and actually works.
AMR is quoted as saying “The challenge is you have to spend 50% to 100% plus of revenue in sales and marketing cost,” he says. “You need this [limitless] amount of cash to forever feed the growth machine.”
There’s just one problem with this statement, and the argument that somehow the marketing and sales costs of SaaS make it “a brutal slog.” The problem is that on-premises software is an even worse slog, except for the very largest brands like Oracle, SAP, and Microsoft.
Think about it. Every quarter is a scramble to make the number for on-premises vendors. And when that number is made, the entire license is recognized and the next quarter the company starts over. At best, there is recurring revenue from maintenance that is perhaps 20% of the original license price.
SaaS, by contrast, has recurring revenue. If you didn’t sell a single additional license in a quarter, so long as your customers are happy, you’ll still get the recurring revenue coming in. Which one sounds like a worse slog to you? I can tell you from having talked to a number of on-premises companies wondering if they should endure the horrors of a switch (ask Steve Singh of Concur what that’s like) that they’d prefer to deal with the SaaS slog.
Don’t take my word for it, or even theirs. Take a look at what it costs public companies in terms of Sales and Marketing dollars to sell an incremental dollar of revenue:
Isn’t it interesting that the red squares, representing perpetual companies, are almost all to the right of the other symbols representing SaaS companies? And isn’t it interesting that the reds wind up even past the point where AMR said the costs were so prohibitive? It’s actually cheaper for SaaS companies to acquire revenue than similarly sized perpetual companies, and I’m surprised that Lacy and AMR didn’t do their research better to find that out. The data has been here in this blog for some time for anyone that wanted to look.
And vendors are continually tweaking their software, fixing bugs, and pushing out incremental improvements.
Lacy says, “Great news for the user, but the software makers miss out on the once-lucrative massive upgrade every few years and seemingly endless maintenance fees for supporting old versions of the software.”
Hold on just a minute there, Sarah! First of all, the upgrades are almost always included for free in exchange for paying maintenance. That massive upgrade revenue blip almost never hits, and when it does (for example with Peoplesoft 8), customers are so unhappy that the vendor dare not ever do it again.
As for all th e tweeking and bug fixing, let me tell you something about that. There is a huge overhead associated with on-premises. Engineering management colleagues whom I’ve hashed this over with estimate that overhead at about 40% of development cycles. Yes, Sarah, it will cost you 40% more in ongoing R&D to do on-premises than SaaS.
Building the first version may very well be harder for SaaS, but after that, you’re only paying the cost of bug fixing and innovation. Meanwhile, on-premises has those same costs, but it’s much worse. The reason? They have to support multiple platforms and versions in the field. Let me tell you, supporting Oracle, SQL Server, and DB2 simultaneously, a typical Enterprise makeup, is a lot of work. Add to that multiple app servers, web servers, and whatever else factors into your platform stack. With SaaS, it’s one platform all the time.
What about those bugs? It so happens I’ve surveyed a number of On-premises technical support organizations and asked a simple question:
How many of the bugs reported are already fixed in the latest version of your product when they are reported?
The number was staggering, and ranged from 40-70%. Imagine that your customers just never encountered 40-70% of the problems. That’s very good for customer sat. Even better, imagine you didn’t have to hot fix and patch any of those problems because customers were transparently upgraded in your data center. Further, imagine no problems due to new untrained IT trying to run the app. You run the app according to the best practices you’ve established. I can’t imagine a happier place to be from an Engineering cost standpoint.
Meanwhile Dare Obasanjo chimes in that Partners can’t take a SaaS switch
Dare comes closest to the real problem for on-premises vendors with this. Sarah Lacy appears to buy Larry Ellison’s claim that SaaS just isn’t profitable enough. That’s actually far from clear because no SaaS vendors have reached remotely the size of Oracle. We don’t know what effect total brand domination can have on their sales and marketing costs. We know there is a pronounced knee in the curve for on-premises vendors that starts at over a billion dollars. Those companies can sell more cheaply. We don’t know the effect when you’ve taken so much market share as the big guys have that you no longer are struggling to hit the kinds of growth numbers we see with Salesforce and other SaaS vendors. Most importantly, we don’t know the impact after 10 years of recurring revenues keep coming in.
What we do know, is that it is extremely painful to switch. There is huge channel conflict, both internally and externally. Businesses that want to switch have to endure a couple of years of brutal slog, to use Lacy’s words, to get there. But once they are there, they never look back.
I’ve seen a number of on-premises companies trying to get to SaaS. Have you seen any SaaS companies trying to convert to on-premises lately?
It’s becoming obvious that BusinessWeek just doesn’t get SaaS. Here is another blogger’s take on BW’s foolishness.