What is a SaaS Mindset?

And how to navigate the change from Software to SaaS

I was recently asked by a friend to give a talk on how to build a SaaS-centric mindset, and that really got me thinking. For some of us born in the SaaS-first world, this seems like a no-brainer but this transformation is fairly complex for large software companies. We know, of course, some of the biggest success stories (Microsoft, Adobe) but there are many others where a complex business model transformation had to be achieved. I have tried to distill here what I thought were the biggest mindset shifts — however, given SaaS businesses themselves can be all over the map when it comes to ACV, GTM strategy, etc., I'm sure there's a lot of nuance and mileage may vary.

Customer Success is a Core Product Requirement

Perhaps the single biggest difference is that in a SaaS model, the cash register rings are directly contingent on the customer's enjoyment of the product. What that means is that the entire product, as well as the customer experience, has to be tailored to ensuring that the customer gets instant gratification. For instance, back at Capillary, the customer engagement company I co-founded, we tried to get the customer to start showing a substantial growth in their customer list within a few weeks and a 3X ROI within three months. This wasn't easy — but it took a lot of work from every part of the organization to make it happen. However, over a three year period, we charged a lot more than any of our "pure software" competitors - so it paid off :-)

There's a lot of great reading material out there, starting from how to measure metrics (the AARRR framework popularized by Dave McClure) as well all of the material around calculating your SaaS metrics and magic number (LTV > 3X CAC, recover CAC within 12 months, keep your churn net negative) so I won't hammer it on, but it shows a key aspect of the business. In the old software world, the "activation" is taken for granted, but in the SaaS world, there are entire growth/customer success teams dedicated to this effort. Most SaaS companies find that they are doing a lot more pilots (learning: never do free pilots esp if you use inside/field sales) but the pilot to win ratio is lower than traditional software.

I should add SaaS companies come in all flavors: some are like Slack or Zoom - start with a free trial, and put in your card - and there are the ones like Salesforce and Workday, which have a long sales cycle just like enterprise software of yore. It's a wide spectrum, so the funnel and how to apply the metrics vary a lot - but ultimately, subscription generates a far higher LTV and the organization has to be geared to justify that LTV to the customer through a corresponding increase in CAC/CoGS.

SaaS Development moves at flash-speed, but the Baggage adds up

This brings me to another part of the SaaS journey: its a lot easier to get a basic MVP in the hands of the customer, and I have found a lot of SaaS stories I have worked with have a really barebones story at the beginning. The fact that the customer doesn't care about "how you achieve things" is a major plus, since you can start with something basic (even flawed) but you can replace the engine under the hood while the plane is cruising at light-speed. Most times, as we build the product out, the product value levers end up being different from what we anticipate at the beginning, and it’s a good idea to anticipate having to make some architectural changes along the way.

There are several other advantages inherent in SaaS development: upgrades are a lot easier (since you are pushing out smaller payloads all the time) but they are expected to be completely seamless, and you have all of your customers likely on the same version. The code to deployment timeline is shortened from years to mere weeks.

However, while this sounds great, it also requires a lot of planning and infrastructure for enabling this magic to come to reality. QA cycles are expected to be much shorter, and infrastructure bloats up really quickly. In most SaaS environments, there are ways to enable the customers to customize and configure their product — and this makes testing all of the scenarios much harder esp. when all the customers are running on the same infrastructure in a multi-tenant setup. QoS across tenants ends up being a major issue in my past experience since tenants may have completely different profiles and expectations from the product. Multi-Tenancy ends up being much more complicated than most companies anticipate when they are signing up for it :)

This all sounds like Consumer Tech.. but is it?

SaaS is definitely closer to consumer tech-free pilots, rapid iteration, metrics, focus on retention, etc. but there are still a lot of differences from a pure technology standpoint. One of the biggest differences is how well you manage to expose features and deal with a lot of unique customer environments. Consumer Tech emphasizes homogeneity and simplicity in the customer experience — fewer features are better than more — but in a SaaS company of any size, features create lock-in, the number of environments you support and enabling the complexity of integration with other systems significantly helps retention, and it’s a great plus. In the consumer company I had started (Taro), we routinely cut features, but we never did so at Capillary :-)

In a consumer product, all the customers are more or less very similar. Yes, there are "whale" customers all the time who may be responsible for disproportionate monetization, but in an enterprise company, the QoS variations between tenants can be substantial.

The other major factor is that most SaaS services help companies cut some sort of headcount (a lot of it in IT) — no more people to manage all the infrastructure. This simplicity is one of the major reasons enterprises love SaaS solutions. However, that also means that there's a much smaller team at the customer's end to manage all of these systems. The vendor really has to adopt the "service-first mindset" vs the "software-first mindset". For instance, upgrades, feature adoption, deployments, integrations — a lot of this is something the vendor has to own in some form or the other, rather than the customer's internal team. This can mean a much stronger emphasis on "services revenue", consulting and business reviews from the product as well as the customer success function. All this can reflect negatively on the gross margin, and on the LTV, so the vendor has to play an intricate dance between retention and gross margin.

Ultimately, for companies navigating this change, there are incredible opportunities for problem-solving, making this a really fun and challenging experience.