July 2, 2009
Why “SaaS Sucks”… From The Vendor’s POV
No, I haven’t gone over to the darkside and abandoned the Software-as-a-Service (SaaS) movement.
But, I just gave a keynote presentation regarding the state of the SaaS and cloud computing market at SoftLetter’s latest SaaS University in Chicago, where the challenges of developing and delivering successful SaaS solutions were once again brought home in the discussions among the software executives and SaaS professionals attending the event.
Despite it being scheduled on the last day of the quarter and first week of many people’s summer vacation, the event succeeded in attracting about 70 CXOs from a cross-section of established independent software vendors (ISVs) and SaaS start-ups seeking insights about how to succeed in this rapidly growing industry.
Like past SaaS University sessions, the attendees were treated to a variety of tutorials from industry practitioners with a minimum of self-promotion. And, this group of attendees distinguished themselves by asking very pointed questions from the opening bell about specific operational issues associated with the SaaS model.
But, it wasn’t until we got to the working lunch session on the second day of the two-day event that their anxieties came to head. It was during the session focused on the latest accounting rules governing revenue recognition in the SaaS model that frustrations among the established ISV executives began to boil over as they learned that:
- After making significant investments in (re)architecting their applications to be delivered as an ‘on-demand’ solutions,
- After building hosting facilities or selecting a hosting partner to deliver their services,
- After determining how to package, price and promote their solutions,
- After developing a service level agreement (SLA) or comparable legal agreement that clearly outlines the company’s contractual obligations,
- After convincing a committee of IT/business decision-makers to try their solution,
- After determining how much ‘customization’ they can do for specific customers without breaking the common SaaS application and underlying service delivery model,
- After accepting a fraction of the value of application in an initial subscription fee agreement,
- And, accepting all the responsibility for the availability, reliability, security and performance of their SaaS solution…
- The aspiring SaaS vendors then discovered they would only be able to recognize their subscription revenues on a month-to-month basis, decimating their traditional software revenue recognition models.
This harsh reality is what has kept the CXOs of the legacy, on-premise ISVs up at night hoping that the SaaS and cloud computing movement would disappear or be derailed by a major outage that would send customers fleeing back to the comfort of their on-premises software and systems safely hidden behind the firewall. Of course, the opposite has been true and SaaS/cloud computing market growth is accelerating as a result.
No, from a vendor point of view, SaaS isn’t as easy as it looks.
It can be disruptive and painful. And, the rewards can take a while to be realized.
But, unless a major service disruption or ongoing service failures occur, the SaaS/cloud computing services market isn’t going to go away because it offers customers too many business benefits. And, ultimately it’s the customer point of view that really counts.
And, by the way, there are a growing number of SaaS vendors, and established ISVs as well, who are figuring out how to be successful in this deceptively difficult business.
Subscribe to my feed
This is so right on Jeff. But I’d add that the only vendors for whom SaaS “sucks” are ISVs looking to make the transition. For eveyone else, SaaS is no better or worse than the software model, it is just different.
And its not only the economics that are different; although they definatively are. It is also the key success factors of the business, which have very little to do with the key success factors for running a software company. The skills, organizational design, sales/channel strategy, customer management approach, funding strategies, etc. required to be a successful SaaS operator are all different from those it takes to run a successful software company. So much that I think there is a legitimate question of whether or not executives steeped in the software model can make the transition succesfully.
Derek Pilling — July 2, 2009 @ 11:30 am
Great article by Jeff and excellent insight by Derek. The traditional ISVs are having the same problems as the horse and buggy people had when cars came along. We are also seeing this with the newspaper business. When an entire organization is designed to create, sell and service something, it is very difficult to change. Companies like Salesforce started from scratch, so they designed the whole company around the SaaS business model. ISVs need to rethink their businesses and change. Think of how Toyota, Nissan and Honda created luxury brands. They didn’t abandon the old models, but created a business to serve a different market. This approach may work, but it takes a major overhaul of thinking.
Ron Arden — July 3, 2009 @ 9:09 am
http://seekingalpha.com/user/440464/comments
This is a very well written article. I think that the metrics and variable one need to understand and monitor in Saas delivery model are becoming very clear. Any vendor who is not fully aware of these metrics or has not fully bought into the timeline/constraints posed by these metrics is sure to feel the pain of Saas business model (Why Saas model sucks))
1. Cost to serve is a major factor in the lifeline of the business: Cost to serve customers has to be significantly low (compare to the monthly revenue) or has to reduce continuously to its optimal levels over a period first few years (2-3). Architecture and customer engagement details matter the most in this category.
2. Time to break even or profitability: It has taken over 6-7 years for well established vendors to be cash flow positive or breakeven in Saas industry (Look at the history with market leading Saas Vendors like salesforce.com, Netsuite.com or Successfactors.com). It also takes significant capital investments to reach breakeven point (by some counts up to $100 Mil). Vendors need to plan the timeline and capital capacity commensurate with these metrics to be successful.
3. Critical Mass: To achieve business goals in Saas delivery model, one needs to absolutely reach critical mass of customers aggressively in first few years of operation (Ideally first three or so). I compare Saas business model to Fast food chain operations, you need to have critical mass of customers to achieve necessary revenues and profitability. Given the lower price points, one has to absolutely play the number game and achieve the customer numbers.
4. Customer Satisfaction: Saas business model is totally dependent upon customers renewing their service towards the end of the contract. If you cannot be fanatic about customer satisfaction (organizationally), you are in trouble. You need to have organizational culture and religion to make your customers happy and take care of their needs.
There are several other factors which will impact Saas business model (like accounting rules, revenue recognition rules etc…) over days to come, but vendors absolutely need to be aware of and bought into some of the metrics mentioned above to be successful in Saas business model.
VishAgashe — July 5, 2009 @ 8:24 pm
[...] the transition to a Software-as-a-Service (SaaS) model isn’t easy for incumbent software vendors [...]
THINK IT Services » Blog Archive » Callidus Bets on the Cloud — July 30, 2009 @ 2:45 pm
[...] painful journey down the SaaS path is just the most prominent example of the many reasons why established ISVs are suffering in today’s environment. A strong leader is necessary to withstand today’s [...]
THINK IT Services » Blog Archive » SAP Needs Strong Leadership to Stop Sinking — February 8, 2010 @ 4:18 pm
It’s really important to have some in-house or outsourced expertise to help navigate through the process of building a Cloud/SaaS application. Implementing multi-tenancy in the correct way requires a fair amount of experience. There are so many problems that can be avoided.
Matt — May 22, 2010 @ 4:17 am