What does SaaS actually mean? … and can it be on premise?
A few weeks ago I received an interesting question from Raman Gupta, CTO of www.redock.com:
I am the CTO of reDock — we are an early stage SaaS B2B startup aiming to reduce the time people spend searching for past content. We take a different approach to the search problem: rather than focusing on the search itself, we focus on the content — we analyze and break up the content into re-usable pieces and primarily search for those pieces rather than entire documents.
We are finding lots of customers see value in this approach, including very large ones. However, therein lies our dilemma: many / most of these large customers very early on in the discussion are telling us the data they want to put into our system is very valuable, and therefore our solution has to be on-prem or its a no-go.
The situation is not so untypical, and we discuss this regularly with our portfolio companies and potential investments since they often introduce a new product type to a market. Raman was so kind to allow me to publish the discussion we had because it nicely consolidates the Senovo thinking around this topic:
Of course, from a purely academic perspective, it would be best to be cloud only, but as a VC fund and as an entrepreneur we are not out to prove a theoretically optimal solution but to build great companies which can scale. Which means that the product and business model need to be accepted by the market at scale. For a mid-market to enterprise play this usually means you need to analyze a couple of dimensions:
Customer Type
The first question which always comes to mind is: are we going after the right customer? Geoffrey Moore establishes the “Technology Adoption Life Cycle” as pictured below in his book Crossing the Chasm and I think it’s very instructive. It basically says there are different type of customers with different needs. Some want to deploy “bleeding edge” products, i.e. the Innovators, and some will be the last parts of a market to jump on a certain product — I’m sure someone in this world is at this moment still evaluating to deploy Lotus Notes 😉.
So when you get the feedback that this product can’t be run in the cloud you should ask yourself first if this is an Innovator / Early Adopter type of customer or is it a Laggard which is trying to avoid buying the cloud solution from the other vendors who are probably going to capture the 80% of the market which is more attractive (faster decision cycles, mostly faster growth and often this means “more pressing” and thus willing to accept higher prices).
Stage: Effectiveness vs Efficiency
The second big area to assess is what stage are you in? If this is one of your first (i.e. <10) customers (speaking about mid-market to enterprise customers), then I’d do whatever it takes to sign them. At this stage you need to prove effectiveness which means that you are solving a relevant problem for real customers and they are willing to pay for it. This will enable you to make first adjustments to your strategy, get the first financing and build out the team a bit.
If this is about customer 10+, then I’d try to be more assertive in terms of finding the right customer who is willing to accept a business and delivery model which provides the biggest potential for you as a company. Our VC colleagues at Notion have recently written a post on that recently https://notion.vc/resources/ideal-customers-profile-template/ and called it “uncomfortably narrow customer profile” and I think it also fits really well in this context. Once you have your first customers the goal changes to prove that you can get into an efficient (and therefore scalable) go to market model. This means you have a clear business model, pricing strategy, customer profile, ways to reach this customer etc. and thus to decrease variance and the need to get creative during a sales process.
Looking forward, between 1 and 10m ARR you should develop a sales process which works like a machine — I call it the one trick pony. It has a very clear sales process, selling to a very homogenous customer group (and is therefore very predictable) and generates extremely exciting KPIs. As a result, the next challenge becomes the recruiting pipeline to feed this machine and internationalization so you can scale within this super lucrative customer group as long as possible.
Business Model vs Delivery Model
Lastly, since life and entrepreneurship are about being pragmatic and making the right compromises, you should differentiate between your business model and your delivery / product model. I don’t think you should compromise on the SaaS-business model: this means that you are providing an OPEX and not a CAPEX solution and you are generating a continuous cash flow which you can use to further improve your product. This predictable and stable cash flow will enable you to grow your business better than the unpredictable “one-off” cash flows of CAPEX solutions.
On the product side I see more flexibility. Of course, being a pure cloud vendor has significant advantages such as limited technical debt because there is just one version of the code running, easy deployment of updates, fast iteration cycles, good product telemetry… But for the right customer and right economics these are solvable problems (e.g. supporting only 2 product versions at the time and sunsetting older ones).
Also, besides of the extremes pure cloud and complete on premise with operations run by the customer, hybrid operating setups are also possible solutions: e.g. you can have a managed solution where the customer deploys a Docker container or a private cloud setup.
Summary
In conclusion, we very rarely see companies where there simply is no market and customers truly just wanted a pure CAPEX product. Usually you find this deep in an industrial setup where a machine is used 10–30 years, it’s clear what the functionality of the machine is going to be (no new features needed, no changing landscape at the customer) and when the customer switches to the next machine generation they usually want to run a price competitive RFP process on a fairly well standardized product. In this case you’re simply out of luck.
In all other cases the real question is what the clients wants and how to frame the solution so he understands and values the benefits that he can get from a SaaS solution since it optimizes for the long term.
