Thread by @JaredSleeper

A few weeks ago, I published my public SaaS framework. Here's the third of five threads diving deeper. When is it right to worry about obsolescence risk? I'll cover the "product model superiority" of SaaS and discuss which categories are vulnerable to obsolescence. 🧵👇

1/ First off, obsolescence is rarely a meaningful risk in SaaS. Investors often trumpet SaaS's "superior business model" given how much they love ratable recurring revenue. Even more important is the built-in anti-obsolescence- a sort of "product model superiority."

2/ A useful analogy here is comparing software to physical real estate. Traditionally, one might buy a corporate headquarters up-front (perpetual license!), build it out/move in (implementation!) and pay a recurring fee for the occasional update/repair (maintenance!).

3/ Of course, over time, the office starts to look old. Tastes change and that sweet burgundy rug suddenly doesn't ignite creativity the way it once did. Even the internal layout might fall behind the times (death to open floorplans, please!)

4/ This happens gradually, but at a certain point, one realizes it's time to make a change. Now, a conundrum: leave the office for six months to let a renovation happen or move to a new one? Either way, it's a major event, and that means committees, budgets, debates, etc.

5/ As the incumbent building, that whole process is bad news. Often there's a new building nearby that's just nicer: glass facade, white marble, grey herringbone wood floors. It might even be cheaper to build a new building from scratch than to renovate the old one to keep up.

6/ It gets worse, though! Imagine the new building is also magic. Every weekend, forever, it would get some subtle upgrades: a new carpet here, new fixtures there, an office removed to make way for a creative lounge area, a slightly more modern facade, a soft-serve machine.

7/ This is what SaaS did to our virtual "living spaces" (and let's be real, we spend as much time in them as we do in the real world). Multitenancy and the browser model make it dramatically more efficient to keep software looking (and acting) modern with incremental updates.

8/ So what used to age poorly (see: your local government's software) now does the opposite- most SaaS gets better with age. Not only does it keep up with the times, but a huge team of engineers listens to customers and adds features.

9/ Yes, there is still technical debt! It's actually the most important liability on the balance sheet of any SaaS company. But it can be mostly hidden from users and paid down gradually over time, without kicking users out of the building for a full renovation.

10/ In short, SaaS companies are dramatically less at risk of obsolescence than their on-prem predecessors were. As long as they stay nimble, customers can stay happy forever. Look at products like Salesforce, which, while not youthful, has defied aging better than Paul Rudd.

11/ I'm still searching for the way that the SaaS product model will go obsolete and lead to chronically inferior products that customers actively flee. It could be that AI and other tools change the nature of our interactions too thoroughly, or maybe there's a crypto angle. 🤔

12/ This isn't to say there aren't public companies we consider to be SaaS companies that have obsolescence risk. I put them into two buckets: middleware/infrastructure companies and desktop productivity app companies.

13/ Middleware/infrastructure companies are tied to (and usually priced on) some measure of compute or storage, often on the server paradigm. We all know that compute and storage are becoming both more abstracted and exponentially cheaper, each of which can create a sort of debt.

14/ Many public "SaaS" companies in this layer still have large businesses running on on-prem hardware: Splunk, Elastic, MongoDB, Confluent, etc. Each has developed a cloud-native product to future-proof. In short, they have (or had!) meaningful technical debt.

15/ Even cloud-native companies can still be tied to infrastructure costs in a way that adds risk. Datadog charges per host. Snowflake per unit of compute. This introduces a new form of debt: pricing debt.

16/ For instance, say your company charges $20/GB ingested (this is a made-up, stylized example), but gradually the underlying hardware/infrastructure cost of a "GB" falls 40%. All of your customers are paying yesterday's price, but a competitor pops up charging today's price.

17/ Do you bite the bullet and cut pricing 40% for everyone? Sucks! Do you adjust pricing for only new customers? Inconsistent! Your pricing model has gone obsolete, and you have an innovator's dilemma on your hands. The longer you wait, the more painful fixing it will be.

18/ The other category at risk is apps that live on desktops where a browser-based alternative is possible (cough, all of them, cough). Alteryx, Tableau, UiPath, Bloomberg, etc. ⇒ they all need to navigate very carefully as the world moves cloud-native.

19/ In each case, there's a great reason for the app to live on the desktop today (data access, automating desktop tasks, etc.) but that reason will gradually fade over time. If the cloud product needs to be entirely net new, that's a mountain of technical debt.

20/ If the shift to the cloud in this particular category is slow and the pre-existing moat is deep, that debt can be paid down over time. If not, allocating engineering resources is a huge struggle: hasten the demise of the core by underinvesting, or build the future?

21/ So, when do I worry about obsolescence risk? Not often, but when I do it is because the company's product/pricing paradigm is exposed to disruption due to a well-understood secular change. I watch out for both technical debt and pricing debt.

22/ The test is if either debt is big enough that in five years, the company will be seen as obsolete. I look for canaries: forward-leaning companies (like VC-backed startups, nimble corporates) that show where the new equilibrium is. Crossover investing is 👌 in this regard.

23/ If there's a mountain of debt, a forcing function for movement (competitor, new infrastructure paradigm, open-source adoption, etc.), and a clear pattern among first-movers, alarm bells ring. Otherwise, I sleep well.

24/ Happily, my next threads will be more optimistic, focusing on the two big ways scaled SaaS companies outperform over time: TAM tailwinds and product extensibility. Each is more fun (and more common!) than any of the three pitfalls.🙂