True SaaS

I was recently on a call with founder who reached out about me potentially investing in the company. As we started to dig into the product it became apparent to me that the product was not truly a SaaS product and I said as much to the founder. I was surprised to hear I was the first person to tell her that her product wasn’t a SaaS product.

I told her that my definition of a SaaS product was that a customer can find, begin using, and pay for the product seamlessly, without any intervention required. I believe any product that falls short of meeting this definition, isn’t truly a SaaS product.

There are countless web products that aren’t true SaaS products. Does this make them bad products? No, but are they true SaaS? No.

To fit the definition of SaaS, this product would need to function on its own without human intervention. When discussing this product with the Founder I learned that most of the company’s time with customers was spent on onboarding and setup. I asked her if she ever considered making the onboarding process self-serve for customers to use the product without needing support. She said no. She said the nature of the industry and the way the data and logic work is such that every customer needed some upfront help to setup their account and make use of the product. At this point it was clear to me that her product wasn’t true SaaS, it was an application running in a browser, but not SaaS.

I shared with her the story of a founder I met a few years that had a web product that she also believed was a SaaS product that wasn’t. This product was in the healthcare benefits space and the founder said that customers sent her paper files of the company’s employee’s pay rate and hours worked. The software managed and tracked who worked enough hours and who was pay rate eligible for federal health insurance coverage. I asked her how many paper files she would receive from one customer and she said oh, “Boxes and boxes.” She pointed to some in her office, and she had even more at her home. Not only did she have a major customer onboarding problem, but she also took on a huge liability by having these employment files in her possession in a very insecure manner. She then had to go through each of the files to enter an employee's information into the software. But that wasn’t the end of the data entry. She also had to get updates from customers periodically to record any changes to an employee’s pay rate and number of hours worked. 

If a company needs to manually enter data into a software product as part of onboarding a customer, the product is not yet a SaaS product. Might it become a SaaS product if the onboarding can be streamlined and made customer self-sufficient? Maybe. But having to manually setup every customer is not true SaaS.

The obvious downsides of a product not being true SaaS, like the time it takes to onboard a customer manually and the inefficiency associated to it, is just the tip of the iceberg. Web products that aren’t SaaS are less investable because of the services component (often for free) required to get customers onboarded thereby meaning the product will be harder, if not impossible, to scale. Products that aren’t true SaaS also can’t leverage product led growth strategies that help to drive a product’s customer acquisition volume while decreasing customer acquisition costs. Products that aren’t true SaaS require a more direct sales model too, which means a larger sales team from the beginning and higher sales cost throughout the life of the product. Products that aren’t true SaaS have higher costs to market, sell, and support, while being less scalable which is not a terrific combination.

Companies with web products that aren’t true SaaS that can charge customers for the onboarding services can soften the blow by generating revenue and profit from the services work, which may help in the early days of a company and product, but the revenue and profit from these services isn’t likely to be significant enough to overcome the friction caused by the manual onboarding.

Friction is at the core of the difference between a web product and a true SaaS product. True SaaS products still have a lot of friction points for a customer using their product, but the reason SaaS is so valuable as both a product delivery and business model is because the major points of friction are removed. With a true SaaS product, a customer can find, use, and pay for a product with relative ease and low friction. With web products that aren’t true SaaS the friction points are more plentiful and consequential for both customers and the product owner.

To be fair, not being a true SaaS product doesn’t equal failure. Sometimes products must, or should, start out non-SaaS to get aspects of the product correct. The onboarding experience in a product, for example, might need to be done manually at first to understand the data, logic, and process requirements for a customer to be able to start using a product. The problem is when customer onboarding can’t be made self-service or when a product team gives up on trying to make it self-service. Once a product team adopts the mindset that onboarding or other aspects of a product can’t be done in a way to empower customers to do it on their own, the product team is now accepting the product won’t be a true SaaS product, while still believing it is.