This may sound like evangelical cloud mumbo jumbo, but I’m actually alluding to the central importance of the ongoing customer relationship in the SaaS business model and its direct linkage to the financial success of a SaaS business. In the SaaS business model, the ongoing customer relationship is a continuous source of revenue, cost, business activity and risk. This contrasts sharply with traditional software where the short-term sales transaction has always taken center stage.

A traditional software vendor makes and sells perpetual license copies, whereas a SaaS business makes and sells ongoing service subscriptions. Each new SaaS customer brings a new thread of recurring revenue and cost which are woven into the larger tapestry of customers to create the total SaaS recurring revenue stream and associated SaaS cost of service. This fundamental shift in the unit of value from copies to customers turns the economics of licensed software upside down, and is still an elusive financial concept for the industry when evaluating SaaS costs, profitability, business valuation and capital efficiency.

Customers vs. Copies

In traditional licensed software, value is equated to the intellectual property of the code, and is monetized using copyrights in a fashion similar to books, music, and movies. Volume is measured in licensed copies and value is measured by the price of a license. But in the SaaS business model, volume is measured by the number of customer subscriptions and value is measured by recurring revenue. A software vendor invests in developing code, and then operates a sales and marketing infrastructure that scales to sell more licensed copies. A SaaS business invests in acquiring customers, and then operates a service delivery operation that scales to service customer subscriptions. Mathematically….

software profit = ( license price – transaction cost ) x copies – R&D costs

SaaS profit = ( recurring revenue – recurring service cost ) x customers – acquisition cost

Operational costs that are fixed relative to the number of license copies sold in the software business model are now variable relative to the total number of customers in the SaaS business model, such as product development which in SaaS becomes part of the recurring service cost and extends far beyond the initial source code investment to the entire business infrastructure (see note below: Breaking Down Total SaaS Cost of Service and SaaS Do #5 – Build the Business into the Product). Alternatively, sales and marketing costs that are variable relative to the number of license transactions in the software business model are suddenly fixed customer acquisition costs relative to the total number of customers in the SaaS business model, variable instead with the number of new customers.

Happy Customers Drive SaaS Business Model ROI

Capital efficiency is about achieving the highest possible return on investment (ROI). High ROI in turn is achieved by minimizing the up front fixed costs of a business and then maximizing margin by scaling revenue well in excess of variable costs. Like putting a down payment on a rental property, and then making sure the the rental income covers the operating expenses and interest payments. In the license software model, capital efficiency is measured by product ROI, but in the SaaS business model the best measure of capital efficiency is customer ROI, or the average customer rate of return (aka Joel’s SaaS Magic Number).

Where “ARR” is the average recurring revenue per customer, “ACS” is the average recurring cost of service per customer, and “CAC” is the average customer acquisition cost. Software ROI is achieved by selling more copies to cover your R&D investment. SaaS ROI is achieved by acquiring more customers and maximizing customer lifetime value through upselling and retention to cover your customer acquisition cost.

In the end, it all has to add up to happy customers. Service subscriptions are perishable. They can’t be copied and stored like a book or a movie or a software CD. A SaaS business without customers simply doesn’t exist—like the sound of a tree falling in the woods with no one around to hear it. In the SaaS business model, the customer really is king.

SaaS Do #8 Enable Mass Customization is a core principle for building SaaS applications. Salesforce.com, for example, has taken it to new heights with offerings such as the Force.com platform. However, do SaaS-based development platforms such as Force.com represent a fundamental shift in application development, or are they simply the SaaS equivalent of Microsoft Visual Basic for Access? How do they stack up against cloud computing platforms like Amazon Web services? This post examines the potential for competitive advantage through mass customization in cloud computing vs. SaaS.

The short answer is this…
Mass customization in cloud computing is more natural, more flexible, and offers more potential for competitive advantage than in the wildest dreams of SaaS, because cloud computing is built on Web services that are a) inherently abstracted, b) independent components and c) accessible at every layer of the technology stack.

Note: In a previous post, I claimed that the salient difference between SaaS and cloud computing is that SaaS has largely been about Internet applications used by people, whereas cloud computing is about Internet application components used by other computers. More succinctly, Websites vs. Web Services. Although everyone seems to have their own definition of all the cloud buzzwords, I’m going to be rather specific and equate them as such: Cloud = Internet, SaaS = Websites for human users, Cloud Computing = Web services for computer users. My intent is not to debate or define the industry terminology, but simply to keep track of what the heck I’m talking about here at Chaotic Flow.

The Role of Meta-data in Mass Customization
Mass customization in SaaS is achieved by converting hard-coded application functions into meta data configuration settings.  For example, multi-tenancy converts hard-coded deployments of multiple customer databases into a single database infrastructure where each customer deployment is identified by a unique customer ID. All the technical miracles that distinguish one customer’s data from another customer’s data are abstracted to this single piece of meta-data to enable data-driven functionality like Customer[1].Name = “Company X” and “Customer[2].Name = Company Y”. Voila!  Mass customization = meta data abstraction of functional capability.

More Natural – The Inherent Abstraction of Web Services
Mass customization is more natural to cloud computing vs. SaaS for one simple reason: meta-data abstraction is inherent to Web services, but it is optional for websites. SaaS applications must be carefully architected to enable mass customization at all, i.e., it is a matter of good SaaS application design discipline to employ a multi-tenant database, configurable security settings, customizable page views, etc. In contrast, every function of a Web service is inherently abstracted to meta-data in the XML inputs and outputs of the API.

The Xignite stock quote Web service can return a wide variety of information
such as the current stock price, an intraday stock chart, and financial news
that varies by the stock symbol (meta-data) supplied to it.

For example, given a particular stock symbol (meta data), the stock quote Web service above can return a wide variety of information about a company such as the current stock price, an intraday stock chart, and financial news. Let’s say Company X above is a manufacturer that uses this Web service to create a website with detailed, current financial information about the company for potential investors. Now let’s say Company Y is a Web publisher that uses this Web service to create a widget that provides in-line stock quotes for companies discussed in its news stories. Here we have two completely different applications built from a single Web service. Imagine trying to architect this degree of mass customization into an end user SaaS application, i.e., a single Web application that can present anything from a detailed company financial profile Web page to a single stock quote widget simply by changing application configuration settings. Sounds like iGoogle to me. Not easy.

More Flexible – Independent Components vs. Monolithic Applications
The stock quote example above also demonstrates the flexibility of enabling mass customization through independent components over that of a monolithic application. Changing a single feature from hard-coded to configurable in a SaaS application can require modification and refactoring at every layer of the software stack from the database structure to the user interface, e.g., adding user-defined custom fields. Moreover, the introduction of  new configuration settings can have a multitude of known and unknown impacts on existing and seemingly unrelated features, e.g., changing an address format from a standard US postal structure to a configurable structure that better supports international clients. The result is that even the simplest modifications to a SaaS application must be carefully considered and become more difficult the more complex the application.

Web services are relatively independent, loosely coupled components. New functions can be added to current Web services, and entirely new Web services introduced with minimal impact on other Web services. For example, I use Google’s chart Web service to generate the charts on the SaaS Model Scorecard. If Google wants to add new chart types to this Web service, it simply creates new values for the “cht” parameter and any other relevant options. However, a SaaS charting application would require changes to the UI to select the new chart type, select the new chart type options, visually edit the new chart type and display examples of the new chart type. Depending on the architecture of the application, this could be a modest change or a monumental change.

Moreover, independence allows customers to assemble solutions from best-of-breed components more easily. The stock quote web service above supplies the data and charts, but the UI can be constructed using the customer’s tool of choice, including any SaaS application that supports Web services. Application integration across functional silos has proven to be a consistent challenge for SaaS companies. Most have turned to open APIs, i.e., Web services to address this challenge. The more a SaaS application opens itself through Web services, the more it acquires the flexibility for mass customization available to native cloud computing solutions. Pushed to the limit, it can become difficult to tell the website from the Web service.

Wildest Dreams – Morphing Applications and Infrastructure, not Just Features
Imagine building a SaaS application that could magically morph from CRM to ERP through configuration settings. The complexity of building such an application is staggering, not to mention the subsequent configuration. Again the Force.com platform comes to mind. Now consider cloud computing. Let’s say I store the respective CRM and ERP application executables on Amazon S3. And, I create a Web service with two calls: gimme CRM and gimme ERP. When I log in, I select ERP or CRM. This Web service automatically downloads the specified application and instantiates it on a farm of Amazon EC2 virtual server instances, where it can be accessed from the URL www.elastic_crm_or_erp.com. This neat trick is possible, because Web services allow mass customization at every layer of the software stack. In this particular case, the configuration reached down below the application layer itself to the O/S and swapped out the entire application. From the user point of view, I just magically see my website change from ERP to CRM.  This approach is really overkill for this simple example, but it makes clear the ability of cloud computing to handle meta data driven, ad-hoc modification at any layer in the technology stack.  It could just as well be accomplished at a much higher level in the stack using two SaaS applications and a single sign-on…uh, Web service.

Mass Customization and Competitive Advantage in Cloud Computing
Although cloud computing offers greater potential for mass customization than SaaS, cloud computing does not really compete with SaaS. Amazon AWS and Force.com are unlikely competitiors, because they segment the market into the high-end and low-end of mass customization respectively, and customers will choose one or the other according to their requirements.

Like SaaS, cloud computing competes against on-premise software, offering many of the same benefits such as lower TCO and mass customization. But unlike SaaS, cloud computing does not compete head-to-head for a final end-user applications. It competes for components at every layer of the technology stack from storage to user interface. As a result, the competition centers around architecture as much as outsourcing. While SaaS adoption is usually driven by functional executives, cloud computing adoption is driven by IT executives. Adopters of cloud computing must rethink how they build applications, employing interchangeable components that may or may not exist within their own firewall. In order to overcome this barrier, cloud computing vendors should leverage mass customization to offer their customers orders of magnitude improvements in functional versatility, deployment flexibility and infrastructure elasticity in addition to lower TCO.

Pure on-demand software-as-a-service businesses are difficult to build.  It is the rare B2B SaaS startup that masters all the Dos and Don’ts of SaaS Success from the beginning.  When the going gets tough, many find themselves falling back on traditional enterprise software approaches to product delivery and business operations.  However, there is a big difference between making the strategic decision to deliver your product in a hybrid model and stumbling into a hybrid model through tactical mistakes. In the first instance the market requirements demand a hybrid approach, in the second executive management is simply not disciplined and creative enough to avoid it.

In an earlier post, I presented the relationship between pure on-demand SaaS and it’s closest hybrid cousins: managed services, packaged software, and enterprise software. The four models differ along the dimensions of pure commodity product (SaaS and packaged software) and pure online delivery (SaaS and managed services).  When a business travels down the hybrid path, it is making a choice to deviate from pure on-demand along one or both of these dimensions.  The farthest deviation being enterprise software. Seems straightforward enough.  So, why avoid a hybrid approach?  Let me state up-front that there are markets that absolutely demand a hybrid model—-a great example is anti-virus software, which requires a fat client for rapid response (packaged software), Internet delivery of virus definitions, software updates and threat alerts (SaaS) and a semi-automated, labor-intensive process for collecting, analyzing and categorizing threats (managed service). However, it is much more often the case that complex market requirements provide the rationalization for poor management rather than the rationale for good business strategy.

The Perils of Hybrid Models
Competitive advantage in SaaS is built by leveraging the Internet to lower costs through economies of scale or to develop differentiation through network-native capabilities. Moving away from a pure commodity product (toward managed services) breaks economies-of-scale, while moving away from pure online delivery (toward packaged software) breaks network-native capabilities.  Deviation due to a lack of discipline without compelling market requirements results in the textbook failure of competitive strategy:  getting stuck in the middle.

“The firm stuck in the middle…is almost guaranteed low profitability
…probably suffers from a blurred corporate culture.”

Sound familiar?  This is the primary reason that some of today’s most well known SaaS companies have yet to attain profitability.  It has nothing to do with the so-called up front investment costs of building a SaaS business (seriously…do NetSuite, Omniture and Success Factors ever plan to stop posting losses?).  They have given up too much competitive advantage in pursuit of revenue from markets where they are not competitive or from customers that they cannot serve profitably (as evidenced by this nice little financial analysis by Bob Warfield).

The Right Way to Go Hybrid
Many markets present challenges along both the dimensions of product uniformity and online delivery.  Unique customer processes,  complex technologies and heavy integration requirements for example can all create serious strategic hurdles.  To overcome them successfully, it is essential to be clear about exactly the business you want to be in and exactly where your competitive advantage truly lies.  If your competitive advantage comes from Internet-based innovation, but you have very unique and demanding customers that require you to customize your product or services, then mixing SaaS with a managed services approach might be the right choice, because the premium you can charge will cover the hit to your cost structure. If you are a low cost, commodity SaaS player, buy our product requires lots of configuration and integration to be useful, then having some offline software components and on-site professional services for on-boarding and account management might be the preferred solution as long as they are highly standardized and don’t undermine your fundamental cost advantage by breaking the uniformity of your primary SaaS infrastructure.  But, don’t get stuck in the middle by chasing revenue that forces you to give up your core competitive advantage and results in the loss of long-term business profitability.

Since it’s inception, software-as-a-service has labored under an identity crisis. What truly distinguishes SaaS from software? How should it be priced, sold and serviced? Is it possible to succeed with a hybrid approach where a vendor offers both SaaS and software versions of a product? Recently, Jeff Kaplan reported that Google will be offering Gmail as an installed service–flying in the face of the current conventional wisdom that SaaS players should stay true to their model. Alternatively, Oracle is finally making a serious challenge to salesforce.com with its Oracle CRM OnDemand (I know because their sales reps keep calling me, but I’m still not buying it).
What does it all mean?

First and foremost I would like to say that IF YOU ARE A STARTUP, it doesn’t matter if you are offering enterprise software, B2B software-as-a-service, online games, or even hardware—STICK TO ONE BUSINESS MODEL!!! Handling multiple business models almost always entails increased organizational complexity and heightened internal politics. It is often essential to separate organizational functions (e.g., sales, marketing, engineering, etc.) or even entire P&Ls (e.g., divisions, spin-offs, etc.) in order to achieve the right cost structure and culture required to be successful in each line of business. In short, it is death to a severely resource constrained company.

The most common software technology distribution models arise naturally from the economics of information goods. Computer software does three basic things: copies data, transforms data, and moves data. But, the unique thing about software (unlike hardware) is that it just happens to be made up of data itself. Why is this important? Because the costs of copying, transforming and moving data around is decreasing everyday, and in many circumstances it is economically equivalent to zero. This is why so many Internet applications are free! The more a software application lends itself to this sort of self-referential automation, the lower it’s cost. Pretty theoretical, so here it is in plain English. Custom applications are hard to deploy (copy and transform) and fat or data-intensive applications are hard to deliver over the Internet (move). And, here is the picture.

How costs give rise to different software distribution models.

The more you can align your business model with the underlying economics of the technology, the better off your will be. Perfect alignment is rarely achievable, because your customers will pull your business in one direction, while your technology will pull it in another. So, choose your customers and your technologies wisely! However, here is how the most common software business models line up with the technology choices above.

Aligning the business with the technology distribution model
increases competitive advantage and profitability.

Now let’s say you’ve done everything right. You’ve built it, but will customers come?  Ultimately, it is the alignment between your offering and your customers’ needs that should determine your business model. Even if you follow all the Top Ten Dos and Don’ts of SaaS, if you offer an on-demand product that no one wants to buy or use over the Internet, then you still have a clear recipe for failure. Alternatively, selecting the approach that best fits your customers’ needs, but then failing to execute cleanly on key business or technical dimensions of your chosen model can lead to an inferior competitive position and poor profitability. Success depends on first choosing the right customers, then choosing the right business model for those customers and finally achieving coherent alignment between your customers, your business and your technology.

Short list of customer needs that align well with each respective business model,
e.g., Does the customer’s business derive competitive advantage from the application?
Does the application automate a process unique to the customer?
Can the customer transfer risk associated with the application to the vendor? etc.

Confusion usually arises when you start with the technology, but it doesn’t align coherently with your chosen business approach or your chosen customers, i.e., we have this cool new technology, let’s find someone who needs it, and then see if we can get them to pay for it. It’s OK to start with the technology first, that is the nature of innovation, but the customer need and business model economics should be vetted prior to writing a single line of code if you want to maximize your chances of success.  But, it’s usually a lot clearer when you can start with the customer need and work your way back to the right business and technical approach.

Finally for the SaaS and software zealots alike. As the costs of data replication, transformation and distribution continue to decrease, the technological pressure to move everything online will become more and more irresistible. But, when customer needs are intractably unique, risky and complex, on-site software will remain the preferred alternative.

At the end of 2008, I promised a special new year post on SaaS Model Economics 101, so here it is.  Introducing the SaaS Scorecard, an online test to estimate the competitive advantage of your software-as-a-service business.

Click on the image above to go to the SaaS Scorecard and take the test.

The SaaS Model Scorecard is designed to help software-as-a-service entrepreneurs and investors evaluate the competitiveness of their businesses relative to licensed software and other SaaS competitors using the principles of SaaS Model Economics 101 and the Top Ten Dos and Don’ts of SaaS Success. Every attempt has been made to create a test that accurately reflects these economic principles, however, the goal is simply to provide feedback as opposed to analysis. That is, it’s really just a game. Have fun!

Scores are calculated across 20 key business dimensions that impact low cost advantage, differentiation, adoption costs, switching costs and network effects. For each dimension, a score is calculated for the potential competitive advantage that can be achieved, the current performance of the SaaS vendor in achieving it, and the combination of potential and performance resulting in the actual competititive advantage that is realized.

I’ve recently been asked a lot of questions like the following:

• Are there some applications that don’t fit the SaaS model ?
• When is the SaaS model appropriate ?
• Is it possible to have a “mixed” SaaS model ?

Mostly these are asked by startups that are struggling for growth or profitability and having difficulty actually achieving my Top Ten Dos and Don’ts of SaaS in practice.

To answer these questions accurately, it’s essential to have a strong understanding of how the SaaS model creates economic value over in-house, licensed or home grown software.  If you can create value, then the model is appropriate.  If you can’t, then in-house software is an equal or better choice.  And, as a SaaS vendor you will have no competitive advantage.

Be warned, that there will be few fluffy marketing tips in this post and the saas model economics series to come, and you are likely to encounter some very specific economics terminology.  This is SaaS model economics 101! It’s going to get a little heavy.

The only difference between software and software-as-a-service is that SaaS is delivered over a standards-based network called the Internet.  Therefore, all new economic value and competitive advantage must flow from this difference.  SaaS model economic value over software comes in two Web-enabled flavors:

1) A lower cost structure from economies-of-scale that derive from aggregating customers via the Web onto a single, vertically integrated infrastructure i.e., hardware, software, maintenance, etc. This cost savings is generally passed on to the customer through a low subscription price and is generally referred to as the SaaS model lower total cost of ownership (TCO)

2) Reengineering business processes by leveraging network automation e.g., online trial, integrating local offices, support chat, etc. and network effects, e.g., crowdsourcing, support forums, revenue-sharing monetization, etc.

Both of these sources of value can create sustainable competitive advantage for the SaaS vendor, 1) is a low cost advantage and 2) is a source of product differentiation.

However, when the nature of your customers, application or technology limit your ability to create value from either of these sources, then you have reached the boundaries of the SaaS model for your business, because beyond these limits there will be no competitive advantage over in-house software.

Some markets have customer’s whose needs are so unique and applications that are so complex that they are intractably fragmented and customers cannot be aggregated onto a single, uniform infrastructure. For these customers, the SaaS model would simply be a foolish choice.  Alternatively, a market may be appropriate for software-as-a-service, but the SaaS vendors may not be building their product to leverage the potential of customer aggregation and the general principle that their SaaS offering is part of the Internet.  In either case, the only possible business result is failure.

If you read between the lines of my Top Ten Do’s and Don’ts of SaaS, you will see one or both of these economic truths shining through.

This will be the first post in a (thankfully) short series where I try to hone in on the economics of competitive advantage in the SaaS model.  The next three posts in this series will dig deeper into each of the following economic factors that can determine the long term success or failure of a SaaS business.

• Aggregating customers for a low cost advantage
• Leveraging the Internet for differentiation
• Reducing adoption and switching costs

Expect a new SaaS Model Economics 101 post each week in December (minus the holidays)
…and a surpise final post right after the new year!

JY

It has taken almost a decade for the software industry to absorb all the ramifications of moving from perpetual license pricing to SaaS subscription pricing. The longer payback period for investors, the headaches of high acquisition costs, and the upfront pre-revenue investments in infrastructure being just a few of the issues with which SaaS entrepreneurs and VCs have had to wrestle.
So, why go out on a limb looking for new revenue and higher margins by experimenting with even more unconventional monetization models? Won’t this just make a bad situation worse?

To temporarily borrow a well known trademark, the reason is simple: it’s the network. If there is a common theme emerging from this short list of dos and don’ts then this is it. It’s the network. It’s the Web. SaaS is not software. New business value arises from the characteristic that your software-as-a-service offering, unlike licensed software, can become a network hub that can connect any business entity, user or system it touches to any other: your prospects, your customers, your partners, your customers’ customers, your customers’ vendors, your customers’ partners’ customers, and so on all the way out to the edges of the Web. Given that value is created by the network, it follows that new network-based monetization opportunities are also created. Here is a quick (and very incomplete) list of new monetization opportunities open to software-as-a-service businesses.

Network-enabled services

• Advertising
• Syndication (content/applications/data)
• Benchmarking and market intelligence
• Integration
• Cloud services
• Marketplaces

Revenue models beyond subscriptions

• Referral fees
• Transaction fees
• Consumption-based pricing
• Performance-based pricing
• Reseller margin
• Revenue sharing

The monetization opportunities open to you will depend on many factors, including the nature of your business, the attitudes of your customers and the sophistication of your product. But most importantly, it will depend on your own creativity.

In the first post in this series, I presented a somewhat trick question in the hope that anyone who digested the entire series would have no difficulty coming up with the right answer.

Quiz: What is the most successful enterprise SaaS application to date?
Hint: It’s not Salesforce.com

For those of you who have read all 5 posts in this series, thank you for your patience. And, if you haven’t guessed it already, the answer is…

Answer: Google Adwords

Because B2B SaaS roots are in enterprise or office software which have traditionally been delivered on a CD, i.e., like any offline commodity that is physically seperate from the business itself, the opportunity to change the game by building your business into the product is one of the most overlooked by SaaS vendors.

When you move your software product online into a software-as-a-service delivery model it enables you to connect the product directly to your customers on the outbound side and directly to your internal systems on the inbound side.  I’ll dig deeper into how you can leverage this for your customers to create disruptive economic shifts in the market in another post, but for now I want to focus on how this enables you to reengineer your fundamental business processes by building them out from your product.

Perhaps the best role model for building the business into the product is one of the earliest Internet success stories: Amazon.com.  Although most of what you can buy at Amazon is a physical product, the fact that it gets shipped to you is almost an afterthought–you could achieve the same purpose by ordering through an offline catalog.  What you are really buying when you shop at Amazon is convenience and credibility, and these capabilities are fundamentally features of Amazon’s SaaS application.  It includes affiliate referrals, product search, offers, recommendations, one-click checkout,  order management, support and nurturing. More specifically, it automates the buying process. Amazon’s affiliate programs spread points of entry (links!) all over the Web, and when you reach the Amazon website you are naturally led through every stage of the purchase cycle. These are the automated business processes you want to build out from your SaaS product.

Chances are that your business is different from Amazon’s in some fundamental ways, e.g., target customers, product complexity, community involvement, etc.  and you will need to tailor your approach to your market.  But, I’ll bet if you study this success story and fully understand the implications, you will find analogies that you can apply to your business. For example, crowd-sourcing has become a very popular approach to international translations, but Amazon was crowd-sourcing automation of the decision stage of the book purchase process10 years ago by encouraging customers to create reviews and top 10 lists.

This is post number three in a series of five.

For more on how to build your business into the product, check out…

• Software as a service is all about the product
• Build for the long tail and get the rest for free

Building a successful software-as-a-service business requires an extreme cultural focus on the product that has more in common with consumer packaged goods than enterprise software.  In my last post, I provided a summary contrast between SaaS and enterprise software business models.  If you look down the SaaS side quickly enough, you should see a tight correlation of ideas around the product itself.  In fact, if you can get your head around two fundamental assumptions about SaaS products, pretty much everything else follows.

1)    There is only one instance of the product…it is a commodity
2)    The product is tightly coupled to operations, because EVERYTHING happens online (ideally).

I believe almost all significant SaaS failures can be attributed to violating one or both of these product fundamentals.  Here are some absolutely deadly mistakes that are a direct result of failing to adhere to these tenets.

Business plan failure – Insufficient demand
Typical Cause
Designing the product for a niche market that is too small and too demanding

Launch failure – High cost per lead and low conversion
Typical Cause
Failure to master online marketing and to build it into the product, e.g., ignoring SEO because it is some kind of black art and prioritizing advanced product features over the ability to provision a trial account and buy online

Adoption failure – Poor organic growth
Typical Cause
The product was designed for the sophisticated buyer, not the long tail.  So, it is too complicated and the purchase process has not been automated.  Prospects cannot find you online, understand the value from your website, try your product, buy your product and start using your product…all without your assistance.

Growth failure – Inability to keep up with demand
Typical Cause
Building an incomplete product with lots of features, loose ends, poor quality and an architecture that wasn’t planned to scale from day one

Maturity failure – Inability to turn a profit because labor costs are too high
Typical Cause
Adding labor BEFORE self-service automation, e.g., hiring too many sales reps instead of developing website content, trial and online purchase or hiring dedicated support staff without full leveraging blogs, forums and instructional video

Overcoming these obstacles requires the realization that SaaS businesses are product-centric, and that the product itself is a living, breathing member of the Web.  The operational implications of this are dramatic, entailing a shift in investment from high labor sales, marketing and support processes to business automation and innovation through the product.

In many ways, marketing a software-as-a-service (SaaS) application is more like marketing packaged software, computer hardware or consumer electronics than enterprise software.  Failure to make this paradigm shift has meant the death of many a SaaS startup.  The reasons are simple.  First and foremost, enterprise software is usually delivered in an unfinished state.  The so-called product is delivered and then configured, customized, integrated and QA-ed onsite to deliver a unique solution–a product of one.  This is more akin to the artisan products of a cottage industry than to manufactured commodities.

The fact that SaaS is a commodity delivered via the Web entails a shift in business model that affects everything from product design to organization design.  Below is a summary of characteristics that contrast the traditional enterprise software business model to the new SaaS business model.

In the world of SaaS multi-tenant architectures and bargain basement prices, the entire business model hinges on having a single commodity sold at high volumes.  Moreover, SaaS is marketed and delivered primarily within a single channel, the Internet.  This creates incredibly tight coupling between the product, business strategy and operations.  In particular, there is an unusual itermingling of the product itself with the other 3P’s of marketing:  price, promotion and place.  For example, a change in pricing model will usually entail simultaneous changes to both your Web ordering code and your license management code.  And, search engine optimization (SEO) is likely to impact how your product is designed and delivered over the Web, not just your marketing website and landing pages.

I was recently asked the question of what is the ideal cost structure for an on-demand software business.  There are very few benchmarks out there of successful mature SaaS companies, so I’d like to propose the following as the cost structure to which on-demand software companies should aspire.  Whether you can actually achieve it in your business is likely to be a result of market demands, technology and sadly enough company culture (as many SaaS business are still saddled with enterprise habits)

Below is what I would characterize as the typical enterprise software company cost structure.  This model is no accident, and it has proved to be immensely profitable over the last 20 years (just ask Oracle and Microsoft).  It is characterized by drivers that work synergistically to create the whole: perpetual license pricing, feature competition, solution selling and customization.  All of these characteristics (and their ensuing complexity and costs) derive from the underlying buyer belief that the system will deliver some level of competitive advantage.  While this may have been true 20 years ago, and may still be true for some fundamental business processes, it is patently untrue for 90% of most IT infrastructure today.  Hence the rise of SaaS and Open Source.

Unfortunately, the preceding paradigm is a self-reinforcing business model that naturally evolves toward this equilibrium.  It is incredibly difficult to break out of economically and culturally.  Below is what I am proposing to be the natural equilibrium cost structure of a well run on-demand software business.

This SaaS business model is equally self-reinforcing and composed of a number of drivers that work together synergistically:  subscription-based pricing, product simplicity, and the continuous automation and integration of marketing, sales and service processes throughout the product and the company’s overall Web presence based on catalytic learning. By catalytic learning, I mean that while sales and marketing still have the tactical role of closing everyday business, they also have strategic role of structuring the purchase process, identifying roadblocks and eliminating them through product-based and Web-based automation.   There should be very little division between the product and the company’s overall Web presence–they should be seamlessly integrated into a single, highly-automated customer experience.  For example, if a customer is forced to pick up a phone or send an e-mail to talk to a person in order to try, buy, deploy, integrate or maintain your product, then your business is not truly on-demand will be bleeding cash from the higher labor costs.  I will also propose that a company is better off starting with this cost structure from the get-go and resisting the urge to chase revenue by adding excessive direct labor resources to the sales and marketing process.  Doing so merely undermines the culture required to build a successful on demand business.  Labor should be highly leveraged through product and the Web automation, so before adding a high-touch resource to hold a customer’s hand directly, you should look for Web/product-based solutions to remove roadblocks to demand generation, trial, close, and use.

Henry Ford once said: “Any customer can have a car painted any colour that he wants so long as it is black.” Then, in 1923 Alfred Sloan of General Motors came along and changed the rules of the game by offering a tremendous variety in colors and models. But, GM didn’t do it one customer at a time. GM redesigned its manufacturing line with the required flexibility to produce a multitude of models and colors without compromising the inherent economies of scale of Ford’s assembly line innovation—a practice that has evolved into the concepts of flexible manufacturing and mass customization.

The primary enabler of mass customization is the elimination of setup costs. Setup costs occur from the labor, time and tooling it takes to switch a production line from one product to the other. High setup costs encourage long production runs to cover the expense incurred in switching over. By reducing them, production runs can be shortened. If they are eliminated, production runs can be reduced to a single unit. That is you can make the variations A, A1, A2, … An of a product (think GM models) for the same costs as making n units of A (think Ford Model Ts). If you apply this idea to enterprise software, taking each customer installation as a “unit” and the associated, customer-specific implementation, configuration, customization, and ongoing maintenance time and effort as the setup costs, then the roadblocks to mass customization in the SaaS model become clear: eliminate, automate and generally squeeze the cost out of your ability to handle unique customer requirements.

This business need entails an architectural requirement that is as essential to an SaaS vendor’s success as system security and the scalable, single-instance, multi-tenant architectural imperative. It requires automated deployment that consumes minimal resources, extensive, easy-to-use, self-service configuration and complete interoperability built on open, standards-based APIs. It cannot be off-loaded to VARS or customers. This shifts the costs downstream and undermines competitive advantage, because from the customer’s perspective, total cost of ownership is not reduced relative to installed software.

If you buy into the idea that on-demand software is the next evolution of software into an industry characterized by mass commodity markets and interchangeable parts. Then, your next concern must be “How can I make money in a commodity market? How can I create a sustainable competitive advantage?” This post is the first in a series that attempt to address this question.

In a nutshell, competitive advantage for vendors choosing the SaaS model will not come as easily as it has in the past for enterprise licensed software vendors and it will not come from traditional methods such as creating wiz-bang features, protecting source code, obfuscating product information, or arbitrarily locking in customers with unique customizations. The main reason B2B SaaS providers are struggling today—while their B2C counterparts are thriving—is that as commodity suppliers, B2C SaaS vendors are much more in tune with the traditional sources of competitive advantage. B2B SaaS has as much in common with computer hardware, telecommunications, financial services, and consumer packaged goods as it does with the old craft world of enterprise software. Maintaining a cost advantage, cultivating brand loyalty, network effects, service quality, mass customization, reduced time-to-market and continuous disruptive innovation are the keys business success. And, they are much harder to achieve.

Simplicity and cost efficiency come first in SaaS

A word of warning before you attempt to be different, make sure you have your cost structure in line. If you are competing against traditional licensed software, lower cost is your competitive advantage. If you are competing against another SaaS player, product complexity and higher cost will eventually kill any other advantage you try to achieve. Why? Because there are (or will soon be) many other choices just like you. Change happens, consumers are fickle and expect their software for free, and business buyers have even less loyalty when it comes down to price.

There, I said it. Difficult customers with highly specific requirements who expect to derive competitive advantage from your offering need not apply. If your target market consists of a list of fewer than 500 control-freak customers with sophisticated IT organizations, and lots of unique requirements, then you are wasting your time thinking of the SaaS model as the underlying approach to your business model. At best, you are a “managed service” where the underlying cost structure is identical to customized, licensed software, i.e., it really doesn’t matter if you run it or they run it, it will take the same number of people, the same number of servers, and the same number of lines of code.

It is important to note that the term “commodity” refers to the fact that the SaaS model is a mass market, high volume business where by and large “one size (read code base) fits all.” We don’t have to look any further than Google search to demonstrate this. How much more “one size fits all” does it get! Type in what you want to find, push button. Also, I am not precluding the possibility that you can attempt to overlay another competitive advantage on top of the inherent cost advantage SaaS entails (see below). But, your efforts will be visible to all your competitors and often short-lived. The proposed idea is that cost efficiency trumps product differentiation, and you deviate from this principle at your own risk.

Fundamentally, the SaaS model is the further commodifation of software achieved by freeing it of physical distribution and increasing interoperability through interchangeable parts (services) to create a disruptive software delivery model with new economies-of-scale and business models that achieve a significant cost advantage—not a functional advantage—over traditional licensed, installed software. It is typicially characterized by the following attributes:

• Commodity capabilities
• Remote, network-based delivery
• Massive economies-of-scale
• Easy adoption
• Interoperability
• Usage–based revenue (subscription, transaction, advertising, etc.)

The closer you get to achieving these requirements, the stronger your cost advantage over licensed software vendors and the greater the opportunity for success under a SaaS model. These basic requirements include a much wider set of applications than most people think of when they think SaaS. It obviously includes salesforce.com, the poster child for SaaS, but it also includes Google, eBay, Amazon, MySpace, web hosting, social networks, syndicated widgets, and seemingly all things your borrow or rent over the Web. But don’t be deceived, these businesses are successful, because they meet these criteria. The truly successful ones often combine the fundamental SaaS cost advantage with some other source of strategic advantage such as a proprietary “secret sauce” to your service offering, brand loyalty, mass customization (one of the many concepts here that I am un-repentantly borrowing from the manufacturing world), or or a first-mover advantage. So, here’s the SaaS elephant in the room: It is already here!! There are hundreds, if not thousands of successful SaaS companies. It is the essence of the Web. The small set of struggling B2B enterprise software wannabe replacements comprise but a handful of vendors in the SaaS landscape. And, they would do well to look to their successful B2C counterparts for creative solutions to their problems.

One might argue that this definition encompasses such a large variety of companies and business models that it loses its value. I don’t believe this is the case, because it recognizes the underlying essence of these businesses and provides a framework for creative thinking and rigorous analysis when considering the myriad strategic and tactical options for building your own SaaS business. For example, when the first challenge you face as the developer of a B2B on demand scheduling and collaboration platform is “How do I build awareness and draw leads to my Web site?”, you are just as likely to find the solution to your problem by looking to vendors like eBay or Amazon, in addition to the obvious salesforce.com.