SaaS is the acronym for Software as a Service, and it is popping up everywhere. SaaS is software delivered as a service usually in a hosted environment where users pay a monthly subscription for as long as they want to use it. SaaS started out as a consumer focused model but over the past few years it has moved into the enterprise market. It is the natural evolution of software.
I spent that past 12 years working for great software start-ups (Forte, AltaVista, Napster, Bowstreet, and Groove) delivering leading edge software. I learned that there is a natural evolution of software companies in terms of how and when they deliver software. I marveled at how a start-up could deliver a new version in 3 to 5 months while Microsoft took 3 to 5 years between versions. There are very good reasons why this is true, and they are often overlooked by the casual observer.
The start-up product delivery cycle evolved something like this. Four releases in the 1st year, three releases in the 2nd year, two releases in the 3rd year, one release in the 4th year, and then it took two years to deliver the next release. Hmmm…what happened?
Let’s look a little closer. The first year we would deliver 4 releases, one major release and three “dot” releases. For example’ V1.0, v1.1, v1.2, and v1.3. The first release would basically demonstrate the concept and do a few useful things but was missing many features. The “dot” releases fixed lots of bugs, refined existing features, and maybe added a new capability or two. We didn’t have many customers and the ones we did have were early adopters who enjoyed living on the edge. They would take every release and give us great feedback on what worked and what we were missing. We didn't worry about backward compatibility or data protection. Just delete everything and do a new install of the software. Life was great!
The second year we would ship 3 releases, V2.0, v2.1, and v2.2. Version 2.0 would work well for a very focused set of features, but was still missing some core features, performance didn’t scale well, and it lacked integration capabilities. Customers started to use the product in real production environments but not in “mission critical” applications. We would learn how customers really used the product and what feature set was really important to them. This is the point where some start-ups lose their way and get painted into a corner by demanding customers. They end up with a product optimized for a particular customer or market segment, and lose the bigger opportunity. But, this is also the point where you learn about real customer usage scenarios.Critical decisions are made based on early feedback. We would adjust the product road map and gear up for the critical third year.
The third year determines success or failure for most software companies. By the third year you have a growing set of customers using the product in production environments. They expect more new features, better quality, and higher performance. They also want the product to integrate with the rest of their infrastructure and business applications. You start getting larger customers with much higher demands than your early adopters. These customers thoroughly test a product before rolling it out, and they only update their computing environment once a year, or even longer. In the third year we would deliver two releases, V3.0 and a “dot” release. The features get bigger, the code base gets larger, the integration gets harder, and the platform test matrix gets more complex. And, most importantly, your big customers will not accept more than one release a year anyway.
By year four, the trajectory of the company is pretty clear. Everyone hopes to reach “escape velocity” on the way to the moon and avoid the death spiral that is so common. By year four you have an installed base of customers to worry about. New releases must be backward compatible. You can’t just blast out new features like you did in the first years. Quality becomes critically important. The test matrix for operating systems, hardware platforms, network environments, browser versions, etc becomes mind boggling. International markets want localized and translated versions. The installer code needs to be able to install from any prior release point. The sales people are constantly coming back with big deals that require “just a few little features” that we don’t have on the road map. Engineering wants to go back and fix quick hacks and old architectures that were developed on the fly in the first few years. These things must be done to achieve the quality standards and performance requirements of our new F500 customers.
It is the natural evolution of a software company and I have seen it happen many times. This is how a company goes from delivering 4 releases in a year to 1 release in four years. It is unavoidable, and in fact necessary, in the traditional software business. Multipy this evolution by 30 years and millions of customers and you have Microsoft. Releasing a product is analogous to planning a space mission to the moon.. Incredibly complex...truly rocket science.
SaaS is changing the way software is built and delivered. Microsoft is getting in the game with Windows Live and Office Live, both as a SaaS provider and as a platform for SaaS application developers. The Emerging Business Team also has a SaaS Lighthouse program that will support 20 start-ups building SaaS applications on Microsoft platforms.
Start-up companies can take advantage of this natural evolution by identifying opportunity areas and innovating quickly. It doesn’t have to be “The Next Big Thing”. It can be the next obvious thing that they can be delivered in months while the larger company will take years.