EAB Founding member Colin Kingsbury was taken by the piece called “SaaS Revolt”. Colin, who runs a SaaS Applicant Tracking System Company called HRMDirect, has a common sense view of the market. Here are his responses to the article.
- If the service is free, you’re not the customer, you’re the product, and will be treated accordingly. As an aside, this is arguably the primary tension that Facebook will have to deal with as it matures. Google-size traffic is simply not going to produce Google-size cashflow. Advertising on Google is like renting a storefront in a shopping mall; advertising on Facebook is like putting up a promotional tent at an event in Central Park.
- The real benefit of SaaS in change management terms lies in the ability to upgrade continuously in small increments, and avoid the pain and upheaval of a major upgrade every 2-3 years. I think it’s like fitness or housekeeping: it’s fun and easy to slack off, but when you need to catch up it’s a lot harder. Tomorrow always comes sooner than you think when it comes to things you’d rather put off.
- That said, if those small increments always add new half-baked features and never finish cooking old half-baked ones, your problem isn’t with SaaS, it’s with your vendor. We *never* remove or disruptively modify an existing feature in our product without asking how many customers will be affected, and how hard it would be for them to adjust to the change. If a vendor can’t make that process palatable for your users, then they either incompetent, ignorant, or uncaring (c.f. item 1 above).
- Regarding the “tsunami of the new,” I must cite Kingsbury’s First Law: Vendors build the products that people buy, not the products that they need. The product choices in a sufficiently-competitive market will reflect all of the primary reasons people actually buy. If you wished McDonald’s offered more healthy options, don’t complain while eating your Quarter Pounder, go to Subway. As a corollary to the above, the paramount challenge to offering simpler products is not designing them properly, it’s marketing them successfully.
- The vast majority of enterprise systems deployed today would be deployed with SaaS, if they were being implemented today. The chief obstacle to SaaS domination is not technical, but legal: companies cannot fully outsource the liability of failure to vendors, and no group of professionals is more resolutely ignorant of technology than lawyers. If I were a vendor with an enterprise-or-bust strategy, I’d be encouraging the proliferation of FASB/SEC/SOX-type compliance requirements around information systems.
* As a bonus question, assume that the federal government enacts a privacy law that places numerous difficult demands on social-networking companies. Would this law be more likely to hurt the growth of Facebook, or help it?
It’s pretty obviously a vendor-centric response to the concerns we heard expressed by HR Execs in the “SaaS Revolt” piece. Vendors rarely understand (in a visceral way) the real costs of ownership of a piece of technology. While vendors focus on the price tag at the point of acquisition, customers live with the implications of design and development in painful, moment to moment daily interaction with the system. The loudest complaint, that SaaS delivers unfettered change across the customer base, is overlooked. In fact, Colin does the standard “It’s not a bug it’s a feature” dance that vendors learn in their formative years. Customers can’t just “go to Subway” once the contract is in place.
The truth lies somewhere beyond the two extremes. By reducing the level of capital investment required to ‘own’ technology, the SaaS model reduces both acquisition cost and control of functionality. The only way a vendor can deliver SaaS profitably is by constraining development to the stuff that’s needed by the most. When customers buy SaaS, they become a part of a collective rather than the governors of their own fates.
At the same time, vendors who deliver low cost, high value services in the SaaS model shouldn’t be expected to deliver single installation enterprise software flexibility. It’s a ‘you get what you pay for’ situation. The reality is at the midpoint of the two polar views. So is the responsibility.