How a vendor performs sales, marketing, development, and support differs greatly between whether the vendor delivers the solution through SaaS or software. This is important to understand, because it means that a great software house doesn’t necessary field a great SaaS solution–at least not in the beginning–and vice versa.
The parts that don’t differ are the knowledge underpinnings: the vertical industry or horizontal solution knowledge, what makes a great marketing message, how to write software code efficiently, and so on. Things that are different between SaaS and software include:
- Data Center Competence: This is a huge difference between the two delivery models. A SaaS vendor will live and die based on its ability to run a large-scale, secure, and efficient data center–the back-end for its SaaS service. A software vendor has no such requirement: it just needs for the software to install correctly on an enterprise’s machines.
- Product Management: It takes a different set of skills to ship SaaS vs. software. I know; I’ve done both. I was a product manager of software (operating systems, utilities, middleware) for eight years and of a SaaS solution (content portal) for nine months (the startup went belly up). When you’re managing software, the drill is to get hundreds of features on the bus, so the big software release can go out on time. At the end, everyone (e.g., Development, Marketing, Customer Support, Training) crowds into a Release Meeting, documents what the release contains (both features and bugs), and agrees to support the listed set of capabilities. In contrast, with SaaS, the features leak out every couple of weeks. It’s a continual stream of small modifications. From a product manager’s point-of-view, the product is continually morphing–unlike software, which stays stable for months or years at a time. If you’re used to managing Big Bang software projects, moving to managing a series of Small Bangs takes some adjustment.
- Sales and Licensing: Historically, sales and licensing of enterprise software has been both high-touch and expensive for vendors. Highly paid sales reps call on enterprises multiple times; complicated contracts are drawn up that take months to iron out. However, SaaS is a commodity business–for a SaaS vendor to get profitable fast, it needs a lot of companies running the solution without a lot of up-front overhead. Rather than a huge direct sales force, SaaS sales goes online or is done by telesales; rather than a custom contract each time, SaaS vendors are inclined to say, “Here’s the service description and the affiliated contract, take it or leave it.” The vendor impact here is that a sales force and licensing staff that is stellar at selling software is often suboptimal at moving SaaS solutions.
- Support: Support for SaaS solutions is typically less high-touch than it has been for software. Again, it’s the commodity nature of SaaS rearing its head. If an enterprise can solve its support problem by poring through some support forums rather than calling the vendor, the vendor views that as a good thing. Google has been slow at improving its telephone support for Google Apps Premier Edition not because it can’t, but because it doesn’t want to. Rather than hiring support people to answer the phone, Google would rather hire support people who can write FAQs and monitor the forums.
So what does all this mean? For vendors, it means that it takes time and a lot of process re-engineering to move from one side to the other. Both IBM and Microsoft, long-term software providers, are having to learn new skills as SaaS providers. For enterprises, it means that SaaS solutions from software companies will be weaker compared to their software predecessors (e.g., Microsoft BPOS vs. Microsoft in-house servers; IBM LotusLive vs. IBM Lotus Notes, Connections, and Quickr) for awhile. The vendors not only have to modify their software, they have to modify their internal processes, and that takes time.