Had a recent conversation with @arinewman about our SaaS experience during the Filtrbox days and it reminded of this blog post that I wrote last year after I counseled a local company on the SaaS delivery problems it was experiencing (unfortunately, like most posts, I started writing the post and it has remained the “Drafts” folder ever since)
As CTO of Filtrbox, I found myself primarily responsible for service delivery and customer experience instead of the traditional CTO responsibilities. That was as a result of a progressive lessons that I learned along the way about running a SaaS company. With the help of mentors, @slcaruso and @sether, I grew to appreciate good practices of running a successful SaaS offering (we were not always successful in reaching reach our goals but we a made a concerted effort to run the company using the the best SaaS practices). Many a blog posts have been written about SaaS from a technology and architecture point of view; in this blog post, I would like to share some fundamental aspects of SaaS that are often overlooked and often lead to unsuccessful SaaS implementations regardless of a solid technology or architecture.
Its a “Service” stupid
The following is a screen-shot of the description of the “Service Delivery” responsibility for my role as the CTO of Filtrbox:
The most important part of delivering “Software-as-as Service” is not the “Software” but the “Service”. In order to deliver SaaS successfully you have to first recognize that your service is essential to someone (if it was not, they would not be your customer). To your customer, you are just like the telephone, power or water company. There is a level of expectation that we have for the services delivered by these companies (disclaimer: this example may not be relevant in all parts of the world). When we turn on the faucet we “expect” water to come out regardless of the time day or holiday, we do not expect to check Twitter for service “updates” or explanations and in the event that there is service interruption, it is of the highest priority to the service company and is quickly resolved. When you analogize your company with these tried and true old school service companies and when you think of yourself that as a service company first, then the notion of “service first” becomes ingrained in the DNA of your company, your team, your products and your processes.
If you are a SaaS company and the goals of your offering do not include the words “customer” or “service”, then you should not be delivering a SaaS offering. I would even go as far as saying that if the the description of roles on your team do not include the word “customer” and, “service” or “experience” , you are headed for the Deadpool. Understanding customer experience is of fundamental importance to SaaS delivery. Before you embark on a SaaS offering, go through the exercise of mapping the the experience that you want your customer to have when they use your service. What do you want the customer’s experience to be at every touchpoint with your company? While some touch-points are not necessarily directly tied to SaaS, it is important to account for them as well if you are to get the notion of “service first” ingrained in your company’s DNA. Out of this will come your service warranties (availability, service response times, customer response time, security etc)
If your service was not valuable to a customer, they would not be using it. Therefore deliver it like its valuable to someone. Users of a SaaS offering expect it to be “always on” (think of the phone, lights and water). Frankly I don’t really care about the technology and efficiency of how the water company gets the water into the pipe, they could be using a bunch of people pouring buckets into the pipe for all I care, my expectations is that when I turn on the faucet, water comes out. Your SaaS users have the same expectation. As an engineer, it pains me to say this, but SaaS users don’t really care about the beauty of your code, its cyclomatic complexity or any of that engineering stuff; they just want your product to work and meet their needs when they use it. That is all they expect. This is not say, you can get away with crappy code, in fact recognizing this has the opposite effect, it leads to better software, hardware, hosting and operations choices.
You are a “Service Delivery” Company
In order to deliver a “service” that is “always on”, the whole company from the top down has to have buy in into the the notion that you are actually a “Service Company” more so than a “Software Company”. The buy in is important because it leads to structuring the organization for service delivery right from the beginning. Recognizing that you are a service delivery company forces the company to provide adequate resources to service delivery related functions. It forces resource planning that values customer service, product development, hosting/operations resource equally.
Because most companies do not see themselves as “service delivery” companies, they often find themselves well staffed in engineering but severely understaffed in hosting/operations and customer service – a recipe for a short-lived SaaS operation. Once a SaaS offering is operational, if your company has engineers only, there is going to be very little engineering and innovation to be done because you engineers are going to spend their time supporting the system and the customers (I say this from experience). I’d recommend hiring a service administrator or service support person instead of an additional engineer because that they free up the engineering team to innovate and make progress on the product. Balance your resources accordingly, you are service company now.
Rather than be obsessed about the “software” aspects of SaaS, I strongly recommend that companies thinking of delivering SaaS offering undergo a midshift and think of themselves as “service” companies first. The above-mentioned aspects allow you to build the “service first” mentality into you company’s DNA. When you do that all the other software aspects will fall into place.