Catalyst Resources Blog

It is my understanding that the point of running a software or services business is to make money. But very few companies have done so yet in the SaaS space. Several recent articles have taken note of this “missing” profitability and pointed to the the costs of doing business using the Software as a Service (SaaS) model.

In SaaS and the Elusive Path to Profitability, the author looks at financial reports from some of the major SaaS players such as salesforce.com, RightNow Technologies, and NetSuite. He notes that these SaaS companies are pouring resources into sales and marketing and losing the battle for profitability. He speculates that they are essentially following a loss-leader strategy - lose money acquiring new business in hopes of becoming profitable over the life of the customer relationship through long-term subscriptions or up-sell.

Oracle’s Larry Ellison also recently dissed the SaaS industry with his now infamous quote “it’s hard to point to any Software-as-a-Service provider that’s doing a good job of improving its profitability.”

Admittedly, SaaS is still at a relatively early stage of market development and acceptance, and these big industry players have spent a lot of resources educating a market about a paradigm shift. But relying on long-term customer retention or up-sell to make a profit some time in the distant future seems a fragile strategy at best. On top of this, SaaS companies must contend with accelerating competition as more companies jump on the SaaS bandwagon.

Given these concerns, it is reasonable to ask: for businesses that are providing SaaS solutions to enterprises and SMBs, how can they be profitable?  What is the secret sauce?

In a previous post I described a measure for SaaS profitability using a simple (and obvious) equation:

Average cost structure per customer

However many SaaS companies seem to ignore this equation - throttling for maximum growth not maximum profitability. They build the core SaaS application well enough, but they conduct sales, marketing, and support using the same resources as they would with traditional on-premise applications (e.g. direct marketing, print ads, sales staff and SEs visiting companies, trade shows, etc). Sales do scale with these efforts, but so do the costs and expenses.

One of the often-promoted virtues/goals of SaaS is to achieve economies of scale so that the cost of acquiring and supporting 100 customers is just marginally higher than for 1 customer. Depending on your hosting solution, you can typically meet this scalability goal for the hardware and software infrastructures costs. But this is where most SaaS consultants or service providers stop.  It is the cost of human resources - the staffing - that does not scale well.

Since staffing is typically the most expensive item in any budget, incorporate automation and self-service at every possible point in the SaaS application that would otherwise require a team to handle.

While you can’t and don’t want to replace all human interaction, you can identify all of the points in a SaaS application where support staff would traditionally need to interact with the customer (e.g. early sales, marketing, demos, provisioning, configuration, billing, monitoring, renewals, etc). Then evaluate which of these “touch-points” can be handled as part of the SaaS application design. Where possible, let the technology (automation) or enable the customer (self-service) to do the tasks that would otherwise require support staff to handle.

This is the secret sauce for SaaS - design the application so that it can scale incrementally up to very large numbers without adding additional sales, support or back-end staff. This approach should be a key component of your strategic blueprint. Model the work flows, high value scenarios, and application touch-points and then design the SaaS application to incorporate and then take over selected services that would otherwise be handled by marketing, sales and support staff.

My post is already way to long, so I will stop here.  But in a future series of posts I will take a prototypical SaaS application, examine several phases in the customer life cycle that are traditionally a source of non-scalable costs, and then give examples as to how these services can be incorporated into the SaaS application and become scalable.

I’ve been arguing for a while now, that  creating a Web-based version of a desktop or server-based product is only part of the battle if you plan to deploy SaaS in the enterprise space. This core application is just one component from the array of user experiences that need to be addressed when deploying or selling any enterprise application. These “other” experiences include marketing, evaluation, configuration, support, monitoring, and feedback.

Just how important are these other user experiences? While I usually try to write things from the point of view of our enterprise clients, this time I thought  I would share some personal anecdotal evidence in the consumer space.

I have accounts with two large financial institutions (no names since both have divisions that are clients).  Both have web applications that offer comparable services,  but Firm #2 seems to offer better pricing for comparable funds. 

Since both institutions deliver a very similar web application for trading,  you would think that pricing would automatically determine which service I choose. But the reality is that I almost consistently use the web application for Firm #1.  Why?  It offers a better user experience for all of those things that are outside of the core application of buying and selling funds.

For example, Firm #1’s web app lets me configure my screen so that I can view information that I use most frequently, including monitoring my activities and the fees I have paid.  I can get at the same information with Firm #2, but it requires me to use their menu structure and go through several steps for this high value task. 

Firm  #1 makes it easy for me to get support - both with an electronic help desk, and via email support.  Firm #2 offers these things as well, but they are not integral components of every screen - they are like separate applications.

On top of this, for the life of me, I could not figure out how to change my password for Firm #2.  I had to contact tech support via phone!

So to come back to the main point: the core application (in this case, fund investing) is only one component from the array of user experiences that need to be addressed by any web application. The other components help maximize the business value of the application. When they are not addressed,  you get customer churn.

The iPhone 3G and 2.0 software were released last week. As I perused the new App Store it struck me how much the iPhone and what it represents, will impact the strategy and design of web and SaaS applications at the enterprise level.

The iPhone is just the very visible beginning to an infinite variety of future form factors for internet-connected devices and applications.  There will be gesture-based iPhone clones of various sizes, tablets with or without keyboards, multi-screen large displays, MS “surfaces”,  as well as new laptops and desktops.  What this means for enterprise application design is that you cannot count on the guaranteed luxury of known screen real-estate, input devices, processor speed or server access speed.

Diverse form factors mandate particular strategies for the design of Rich Internet Applications (RIAs) and SaaS. The principals are not new.  But they are worth re-stating. Each point would be worthy of a dedicated blog entry, but in this post, I am only going to briefly point out a few.

Identify the high value scenarios, simplify business process and validate this with users

It is more critical than ever to identify and model the scenarios that are of highest value to the widest set users.  Then ensure that these scenarios/workflows are prominent in the software, easily understood, and require the fewest number of steps to complete. This likely also involves analyzing your business processes and streamlining them. The result is not a stripped down application - but rather one that is more refined, prioritized and elicits greater productivity. On smaller, low powered devices, the UI design should enable users to accomplish the high-value tasks in very short time. On larger devices you have the luxury to add in more options - but only when it makes sense.

Salesforce CRM for iPhone - high value tasks, integrated with email, phone and maps

Develop componentized, contextual interfaces

On-premise applications are typically dominated by the Windows OS desktop metaphor with drop-down menus, tabs, tables, combo boxes, modal windows, etc.  They require a lot of screen real estate and cram in a large number of options and settings to accommodate every imaginable choice and feature.  Applications on the web or mobile (where performance is constrained) need to surface just the components and data that are necessary for that device, at the moment.

Use agile design techniques to produce meaningful prototypes in a very short time

Internet-connected devices need to adapt to user feedback, new technology and real-time monitoring of user behavior (i.e. you can track what works and what doesn’t).  Agile development processes let you iterate quickly.  By using componentized design and user experience elements, you iterate prototypes with little wasted effort and are able to adapt to change throughout the development process.

Get your conceptual models right

Because you don’t have the real estate for sophisticated online help, or guaranteed ability of the mobile user to contact support, you need to make sure that users have the right conceptual models or previous experience models that users relate to high-frequency or high-value tasks. This will minimize training and support, and maximize adoption.  Validate with representative users.

Plan for information sharing and social media (aka Web 2.0)

Users on an iPhone are by definition, working on a communication device.  More broadly stated, user working on the web are likely involved in or familiar with some form of social interaction. Design SaaS and web applications to take advantage of the easy ability to share information.

Design for accessibility

People usually think of designing for accessibility as something for the visually or aurally impaired. But when you design for accessibility, you are by necessity also designing for devices that are resource constrained. Design for accessibility and you achieve several goals at once.

There are certainly many more strategic and design principals that I could cover. These are just a few that immediately jumped out at me when looking through the App Store.  What is clear, is that any enterprise developing a new web application or SaaS solution, must have a strategy to accommodate a wide range of dispersed users using a diverse range of devices.

Having worked with a significant number of organizations on SaaS strategy and design,  I see a pretty clear picture emerging of factors that define the winners and the losers.

It is rare that a company comes up with a completely new and inventive SaaS product that drastically changes the market landscape.  On these rare occasions, the new SaaS product wins because the product or service is so revolutionary in an of itself.

For the rest of us, SaaS applications are primarily either an extension of existing products to the web or pure-play SaaS applications developed from the ground up for the web. For these clients, when I talk about winning, I am talking about profitability. (Note: for enterprises launching SaaS for internal use, usability and performance are key success metrics rather than profitability.)

Designing for profitability is related to, but not a requirement of, designing for good user experience.  Many of our SaaS portfolio clients choose Catalyst simply to design a SaaS application with the best possible user experience for the service. We do a workflow analysis to determine the functional requirements, we analyze user behavior to simplify workflows, we refine the visual appearance,  and we develop an interaction design systems with reusable visual and UI components.  This is all well and good and these clients are very satisfied.

But our more sophisticated clients ask us to take things to the next level.  Not only do they want great user experience, they want to know how to make their SaaS have real business value.

So what makes a winning vs losing SaaS when it comes to profitability?

The basics are pretty simple: you need a stable cost structure that is below the subscription revenue stream.  You achieve this in two ways: 

1) Provide a set of services that can’t be duplicated using on-premise software so you can charge premium pricing and avoid commoditization.  This comes from the ability to use the internet to link together data, services, and people, all in real time and from the ability to monitor customer behavior in your application to rapidly adapt services.
2) Lower the cost of sales by automating the marketing, trial, purchasing, configuration, support and social referral processes and integrating it thoroughly into the product itself . This is the life cycle approach - taking all of the costs that are typically handled by people to support the core application, and building them as an integral part of the SaaS design.

The SaaS that is less likely to achieve profitability is the one that simply offers an on-line application as an alternative to on-premise software.  It may indeed be a good on-line alternative (presumably at least RIA-enhanced).  But offering an application on the web without offering a value-add that takes advantage of the real-time data/services integration or without using automation to lower cost structures, means it will be difficult to make substantial profit through a subscription revenue stream.

In late spring of this year,  I received an email from M.T. Hoogvliet, a student of Interaction Design in the Netherlands.  He was writing a thesis on SaaS Interface Design with a goal to develop a set of user interface guidelines for Software-as-Service web applications.  He was proposing to answer some interesting questions:

• How to define a SaaS application?
• What are the key elements in designing general web-based software?
• How does a SaaS application differ from general web-based software?
• On what points does a SaaS application typically need to appeal to a user?

Hoogvliet noted that “SaaS and web application design falls somewhere in between existing guidelines for designing interfaces because two previously separate disciplines (desktop and web) are merging together in SaaS.” He also lamented the dearth of articles or literature on the topic. He contacted Catalyst Resources to ask us to identify the best practices we use for designing SaaS applications.

We shared some of our initial work around the customer life cycle approach to SaaS strategy and design. Hoogvliet integrated this with his other research to produce a comprehensive thesis offering a set of web-based design principles along with specific guidelines for designing a profitable SaaS.  As a real world case study, he also developed a SaaS application to design, develop and use a CMS.

Mr. Hoogvliet has given Catalyst Resources permission to make the thesis available for download. I strongly encourage user experience and interaction designers, as well as ISVs and enterprise application developers, to review this work. The thesis will be a valuable component for a strategic analysis of your own SaaS applications plans.  (Note: I recommend that anyone with an MTV-generation attention span, should jump straight to chapter 4.5 - around page 35 - to begin).

Download SaaS Interface Design - Designing web-based software for business purposes (336 KB pdf).

Feel free to comment about the ideas in the thesis or offer extensions to Hoogvliet’s analysis.

Several years ago, we developed a web collaboration application, primarily for use by our own distributed teams and a few select clients.  This application allowed us to share project files, and coordinate team activities online. One immediate benefit was that it cut down on the volume of email back-and-forths.  All documents that required review or approval were simply posted online in a team or project workspace. This also made it feasible for employees to telecommute.

In the last year or so, we have been making an active effort as a company (and individuals) to go green and reduce our impact on the environment. We are working to be certified by the City as a green business, doing the standard reduce/recycle/reuse things including using CLFs, buying recycle paper, composting, using low-toxic cleaners, encouraging public transportation, etc.

As part of this green effort, we started tracking how our our web collaboration solution was reducing our carbon footprint by replacing the need for air travel and local commuting. The initial results, based on just our own staff and a few clients, were so encouraging that we decided to enhance the web collaboration solution and provide it to our entire client base.

We knew that our clients would be intellectually supportive of a green initiative. But reality was that they were already familiar and comfortable with email, face-to-face meetings and hard copy documents. If we were going to be successful at getting them to adopt web collaboration as a preferred way of doing business with Catalyst, we would have to provide a better user experience and enhanced productivity as compared to the incumbent solution.

We redesigned the application as a multi-tenant SaaS giving each client their own team space, with 24-hour, anywhere access.  We also developed a user-validated RIA interface that minimizes the training requirements, provides high performance, and is natural to use. Clients can configure their team space to incorporate their own branding, as well as their own industry-related terms and language.

We deployed this to seven clients located throughout the US, as well as our own employees. Then we tracked our travel, monthly expenses and billable hours compared to previous months.

After implementing the new SaaS RIA web collaboration solution, Catalyst was able to reduce business travel and commuting across seven clients to achieve an average CO2 reduction of 21,000+ lbs per month. (roughly the amount produced by 3 US households in one year). In addition, in one month alone, Catalyst saved 70% in travel costs and increased billable activities by 20%.

We are excited by this initial data and will continue to enhance our web collaboration/team space solution.  Needless to say, we will use it automatically with all new clients as well as our growing staff.

There was plenty of coverage the past week about the new SproutCore HTML/JavaScript framework that was used by Apple to develop their MobileMe site.  “A SproutCore application is a JavaScript application that runs entirely in the web browser. It can often run on its own, without even needing support for a web server except when it makes sense for the application. This frees the server developer to focus on the things the server can do very well such as saving, restoring and aggregating data and performing expensive operations. Meanwhile the ‘thick’ client running in the web browser can handle the task of presenting the user with a friendly interface that is fast and intuitive,” from the SproutCore Web site.

What is interesting is that the description of SproutCore applies to any RIA stack - HTML/AJAX, Flex, Silverlight, Curl or any new flavor that comes along.  RIA is now the defacto standard for web application deployment.  This applies to applications ranging from simple e-commerce sites, to desktop widgets, to full blown enterprise applications delivered as SaaS.  The particular application develop platform an organization should choose should depend on two things:

1. The core technology for your application (typically .Net or Java). The core technology is driven by a much broader set of issues than just the presentation layer. If you already know what the core technology will be, put a stake in the ground to constrain your evaluation of RIA platforms. We have seen very few teams be successful in delivering an application within the required scope and schedule requirements when the team had to change to an entirely new technology base.
2. The primary device and platform where you plan to deliver your application (e.g. public web, in-house, iPhone, desktop widget, combined off-line and on-line interaction)

Lately we’ve done a lot of work with Adobe Flex because it met specific client needs (e.g. bidirectional network sockets), it is very good at media handling, it is fast to prototype and develop, and it is scalable. For SaaS, we can build smart, adaptive, and reusable interface and data handling components. These can be used in the core application as well as with all the supporting services delivered in software (e.g. billing, provisioning, configuration and support).

Most of our financial services, insurance and banking client work has used GWT and BackBase.

As we develop more applications specifically targeting mobile devices in the enterprise, we will be adding SproutCore to our list of AJAX/HTML solutions.

Regardless of the platform or technology, this is an exciting time to be developing enterprise applications.  The business value of user experience is no longer a hard sell.  Companies get it!  The success or failure of an enterprise web application or SaaS deployment is dependent on using RIAs to deliver compelling, addictive and productivity-enhancing user experiences.