Keys to SaaS Success

Creating and running a successful Software as a Service (SaaS) company or division isn't easy. That said, there are ten keys to increasing the chances of success as a SaaS provider. Following these tips won't guarantee your success, but at least you'll avoid the most common mistakes that have plagued the first generation of service providers.

1. Choose Off-The-Shelf Software Over Custom Software Wherever Possible

In most industries, buying from large, established companies is less risky than buying from newer, less established companies. In the software industry, the largest vendors are not only "safe" choices, they are also typically the centers of highly valuable "after-market economies" in which partner companies provide add-on and complimentary products and services. If I buy database software from Oracle, I can find thousands of add-on and complimentary products, can buy hundreds of books, can hire dozens of well trained, even certified, employees and consultants. If I buy database software from Joe's Data Hut, finding these products, services and people is much harder.

Consider a SaaS provider that wants to provide hosted sales force automation (SFA) functionality. Once choice might be for that company to strike a deal with a leading SFA software provider (e.g., Siebel Systems) and provide a hosted solution based on this software. Another choice might be for that company to write proprietary SFA software, perhaps "optimized" for their hosted offering.

The custom software approach involves all of the risks associated with writing custom software of any complexity: missing or incorrect requirements, delayed product releases, performance or scalability problems, quality problems, etc. However, these challenges can be overcome – after all, they are solved by hundreds of software companies.

The bigger problem is that the custom software approach means, well, software. And this means software engineering personnel, organizational structure, processes and culture. And a software culture is the last thing you want at a SaaS company.

2. Build an Operations Culture, Not a Software Culture

The world is full of jokes that provide humorous examples of how engineers are just plain different than people in other professions. These jokes are funny because these differences are real. Within the technology industry, of course, we know that there isn't just one generic personality profile for all engineers. Software engineers are quite different than operations engineers.

Software folks find challenge in figuring out how to solve each new problem. Once they've figured out a particular problem – or even just 80% of it – they lose interest and want to move on to the next problem. This isn't a bad trait; in fact, it's a really good trait to have in the software world. Generalizing a bit, lazy programmers are typically very good programmers. For example, any duplicated code that would cause them to have to tediously make a large number of repetitious changes will be naturally rooted out by this type of personality.

Operations folks are different. Their pride comes from polishing and perfecting. A good operations person will balk when a software engineer says, "It's done" just minutes after coding it for the first time. A good operations person will ask, "Where's the documentation?", "How do I administer it?", "How do I recover if it fails?" and so on.

To use the nations of the globe as an analogy, you can think of software folks like America and operations folks like Japan. The former are known for innovation and revolutionary ideas, while the latter are known for making evolutionary changes, ironing out difficulties, and making things work reliably.

A SaaS provider founded by and/or led by software professionals will likely have a software culture, which puts it at great risk. A SaaS provider founded by and/or led by operations professionals and with an operations culture will likely succeed at the most important thing that its customers are buying: reliable operations.

3. Hire Experienced Operations Professionals

To put it bluntly, software guys – most, anyway – think Operations is easy. Their "figure-it-out-once-and-you're-done" mentality – which makes them good software developers, by the way – keeps them from understanding the true benefit – and difficulty – of doing Operations well. Grinding out details is just not the style for software engineers.

Especially if you're writing your own custom software, you might be tempted to delay hiring Operations people until the software is (mostly) done. This is a mistake. Especially if you write your own custom software, you need good operations people on staff from the beginning; they can help define requirements for reliability, recovery, upgradability, scalability, performance, etc.

Hire experienced operations people. Given the importance of smoothly running operations to a SaaS business and its customers, it's not a place for junior, inexperienced people to learn "on the fly" and run "by the seat of their pants." Although the technical details are often quite different, hiring people with Telco experience can help set the bar in terms of world-class "always available" operations.

4. Understand Your Customers' Business Requirements

SaaS providers sell business solutions to business buyers, while many software vendors sell technology solutions to technology buyers. With technologists creating and selling technology for technologists, there is a better chance that the requirements will be more fully understood and met by early versions of the software and/or that engineering users will more likely "make do" or "kludge" any software that is lacking or incorrect in a limited way. But in the case of business solutions sold to business buyers, the buyers are typically very knowledgeable and very demanding, often in areas not fully understood by the provider. To be successful as a SaaS provider, you must fully understand your customers' business requirements.

5. Honor Your Customers' Need for a Development-Test-Deployment Cycle

All reasonably mature software companies have ironed out the kinks in their Development-Test-Ship cycle. Most software companies have a good handle on how software goes from the development team to the testers on the quality assurance team to manufacturing (in the case of CDs) and/or to the Internet for download.

But very few companies have figured out how the customer should move from development to test to production with the solution built with their software. That is, what support exists within the software for the customer to first work with the software in one or more development environments, then move it to a unified/shared test environment, and then move it into production use? This is not something that most software companies have figured out very well; it is generally left as an exercise for the customer.

But with a SaaS offering, the customer is developing, testing and deploying to production with the software hosted at the company's site. This makes it the provider's problem, not the customer's. And it's more complicated still, because just like the company itself, the customers must move from development to test to production repeatedly. This is always an iterative process; solutions are never complete and perfect the first time, just like software is never complete or perfect the first time. For example, an e-commerce site may wish to create a special look and feel and perhaps even a special product line for the holiday season, but needs to be able to develop and test the new "Christmas site" while continuing to run the "normal site" in the meantime. Ideally, the transitions from the normal site to the Christmas site and back (or to some new site) must be as seamless as possible.

A single, simple environment for customer development, testing and deployment won't suffice. It might be good enough to get a few early customers live with their first-cut solution, but customers will realize the limitations of this approach soon enough.

These are complex hard-to-solve issues, especially because each customer's development-test-production cycles are different from one another, and sometimes even depend on the development-test-production cycles of the SaaS offering itself (e.g., when new features are required in a new version of the SaaS offering's solution).

6. Carefully Define and Communicate Your Standard Offering(s)

Having a notion of a "standard offering" (or more than one) is critical. Communication of this standard offering throughout your organization and with prospects and customers is even more critical.

It is not sufficient for there to be some rough approximation of "what the service does" and what configuration choices the customer gets. It is not sufficient even for there to be a standard offering trapped in the minds of a few senior developers. There must be a fully defined, fully documented and fully communicated standard offering. In most organizations, the product management team responsible for each service in question is responsible for this.

The standard offering must be clearly communicated to the sales force and to the professional services organization, including any professional services partner companies. The sales force must restrict itself to selling the standard offering, unless it checks first with the professional services team and perhaps the engineering/product team.

Of course, the precise definition of the standard offering must be adjusted based on what the sales force is hearing and how successful their sales efforts are as well as on feedback from the professional services team. Finally, there should be a standard mechanism for folding any/all "generic" functionality added by the professional services team back into the base service offering.

7. Provide Clearly Defined Configuration and Extensibility Mechanisms

Your professional services group must have clear documentation on how they can configure and/or extend your standard service. They'll need to communicate all of these choices to the customer as part of the customer's implementation/deployment. Without guidelines here, the professional services team won't know what they can offer to the customer and what they can't – something that can only lead to customer dissatisfaction.

Having clearly defined mechanisms for your professional services team will allow them to efficiently provision your customers. This is critical, since from an organizational scalability perspective, preventing professional services from becoming a bottleneck is critical. Otherwise you will have to grow your professional services team (or partner) at a faster rate than is optimal. From an organizational scalability perspective, preventing professional services from becoming a bottleneck is critical. This is especially true if customers are not given self-service tools to make ongoing configurations. Without self-service tools

8. Provide Self-Service Customization Tools

Having well-defined mechanisms for customization will help keep down the headcount needed for provisioning initial customer deployments. But if your professional services team needs to be involved for most or all subsequent customer customizations, your headcount requirements will balloon quickly; the headcount needs for provisioning initial customer deployments is proportional to the number of new customers you acquire, while the headcount needs for provisioning subsequent customizations is proportional to the total number of customers you have.

For extensions, which require code modifications on the server-side, it is unlikely that you'll ever want to allow customers to make their own changes. This means that you will still need to staff at a level necessary to provide all professional-services-based extensions.

9. Don't Offer a Standard Offering Too Soon

Especially if you make the mistake of creating a software culture and/or the mistake of writing your own custom software, you'll be tempted to hone in on a "standard offering" right away. This is what software people do – they offer "products," not custom consulting-based solutions. Of course, this is exactly the right thing to do – eventually. The key is to make sure that you fully understand your customers' business requirements before doing this. Before that, you're much better off working consultatively with a small number of early adopter "development partner"-style customers.

These comments generally apply to traditional software as well. The reason that this is even more important in the case of a SaaS offering is that as a general rule, SaaS offerings sell business solutions to business buyers as discussed earlier. As with business software sold and delivered in the traditional, installed manner, business buyers are typically very knowledgeable and very demanding, often in areas not fully understood by the provider.

10. Go Slow

Get it right. Figure out – and practice! – your disaster recovery procedures, your upgrade procedures, your regular maintenance procedures, and so on before you take on customers or add significant new functionality.

Especially if you make the mistake of writing custom software, it is tempting to view your software as "Internet software" and your company as an "Internet company." This creates pressure to "get big fast" which interferes with providing high quality operations to your customers.

It is important to realize that most solutions provided via a service provider are quite complex, often on the scale of or near that of an ERP system, not a simple Yahoo! Horoscope page. This complexity ripples through the entire organization – development (if present), marketing, sales, technical communications, web production, etc. Simple Internet sites may change content or simple functionality every week or two, but this simply cannot be done with complex functionality.