Making software is easy. You just collect the market data, generate a high-level technical specification, build the product, and test it. All marketing needs to do is put together some screenshots and sales can just kick back and wait for the orders to start flooding in. Right?

Unfortunately for software vendors, it doesn't quite work that way. It takes a long time - years in fact - to get software right, and the problem starts from the very beginning - understanding the market. Part of the issue is that the market does not understand itself. Go into any large company, and ask them to detail a business process such as order entry, and you will get a variety of differing responses.

The Process of Process
Management will describe the process as they think it is. Unfortunately, this utopian vision is rarely right and tends to ignore the inevitable trade-offs that need to be made in the real world. The user population will tell a different story. A small number of staff members can be counted on to provide a fair description, but many will innocently leave out critical nuances that are essential to effective outcomes, while others will deliberately conceal activities that are considered out of bounds. Unfortunately, workarounds, however necessary, are frowned upon by management, so they are often left out. The net of this is that the definition of the business process that emerges is often inaccurate and/or incomplete and any effort toward automation is bound to fail.

Even when the descriptions by the users are accurate, if the process itself was poorly designed, automating it will only make it worse. To put it mildly, many companies are uneven when it comes to the quality of their internal processes. They may have excellence in one department, yet only mediocrity in another. Automation of a poor process is bad business and only makes the situation worse by creating more efficient ways to fail.

A second problem with automating processes is that too often little weight is given to the value of flexibility. Allowing for a little bit of common sense can go a long way in addressing this challenge, but many applications err on the side of mandatory fields and aggressive input validation among others, which creates a great deal of user frustration.

I Know What I Want When I See It
A common alternative is to solicit feedback from a group of customers to specific vendor ideas; however, this often leads to disappointment as most people only know what they want when they see it.

That leaves the vendor with only one credible option: to build a series of prototypes, or pre-production versions, before settling on the ultimate product spec. This is, in a way, an application of "the wisdom of crowds." Of course, this takes time and is expensive. This often becomes the reason why this approach is not taken with predictable consequence. On the other hand, the vendor may be able to mobilize resources this way, in addition to producing a superior product outcome. Critical to all of this is customer engagement. It is at that point where the SaaS model wins because the process of rapid prototyping and rapid implementation is infinitely easier in a SaaS model than an on-premise model.

What You See Isn't Always What You Get
With Enterprise Software, what the customer thinks they are buying, what was demonstrated, and what is actually delivered are frequently different things. With SaaS, it's WYSIWYG (What You See Is What You Get). There is no need for a polished or customized demo, merely an actual demonstration of the functionality as it exists today. There is no special customer implementation, just a provisioning of individual users.

One problem with on-premise software is that the implementation and integration is often done by the customer's IT department with minimal involvement from the vendor. Even if the vendor's professional services team is involved, important customization lessons are rarely fed back into the product. Perhaps the area where there is the greatest misalignment between the customer and the vendor is that the software vendor frequently has little incentive to see to a successful customer implementation because shelf ware has no immediate detrimental effect on an enterprise software vendor. That stands in sharp contrast to a SaaS vendor whose revenue depends on the renewal of annual subscriptions.

The Reality of Shelfware
With IT organizations and analysts routinely quoting project failure rates of 30% and higher (http://www.it-cortex.com/Stat_Failure_Rate.htm), shelf ware is a fact of life for most on-premise applications. CRM is legendary in this regard: Gartner reports that 55% of projects fail to meet expectations and the Butler Group reported a whopping 70% of projects failed. So any rational person starting a CRM project would have to predict failure before they even started.

Renewal Rates Are the Real Gauge
As CEO of a SaaS company, I know the metric that the board keeps a sharp eye on is the customer renewal rate. That remains the single best measure of customer satisfaction. Customers can opt out of their contract once a year, and it's an unlikely customer who is going to continue a subscription if they don't use the system or if our service is poor. This gives me perfect visibility into customer satisfaction and is worth more than a thousand customer surveys. As the saying goes - people vote with their wallet.

With SaaS, where all your customers use the same implementation, you can have confidence in the dire as there are many voices pointing out ways the application can be improved. Of course, you will hear both good and bad ideas, but since we're in a market of ideas, the good ones win out. So over time, a SaaS solution begins to represent a consolidated set of best practices. The SaaS model has a built-in mechanism to favor the best ideas and providers for improving the product.

This same dynamic acts as the driver that improves software quality, simply because SaaS vendors can't operate for very long with a serious bug in their application. Not one, but hundreds or thousands of customers will be affected; as a SaaS vendor, you have to fix the issue now. Otherwise you will put your renewal business in jeopardy.

Repeat business is the bedrock of the SaaS business model. The startup costs for a SaaS business are high and it takes time to develop organizational discipline that the model mandates. However, once those milestones have been reached, the SaaS model is more predictable and friendlier to investors than the on-premise model. The real beauty is that the model perfectly aligns the goals of the customer and the vendor in delivering a quality, functional, and tested solution. Because SaaS operates in only a single environment, the need to support a multiplicity of different configurations doesn't exist. That means that engineering is free to focus their time on incorporating new functionality, using the constant stream of customer feedback that a large customer base will bring. In a way, SaaS customers are therefore not just subscribing to a service; they are leveraging the collected, concentrated, and distilled best practice of a whole market.