Service as a Service
Service as a Service is an idea I coined in my recent book to describe what software founders should do before they create a “Software as a Service” (SaaS) business.
It is a nice shorthand for both:
- how Indie Hackers should offer productized services before SaaS in the stairstep or ladder model
- how Y Combinator startups should Do Things That Don’t Scale before they do things that do.
It is also nicely aligned with the current conventional wisdom of how companies can be built by serving an audience first.
In the context of a software startup, Services mean writing custom software tailored to the needs of each individual customer, and Products mean writing one set of software that all customers use.
Products are more scalable, because every feature added is immediately useful to all customers (including future ones), whereas Services are more sellable, because you are directly addressing the needs of each user. Products (especially digital products) have higher profit margins and can generate recurring revenue indefinitely, whereas Services always have expensive humans involved, and customers churn much more frequently.
A lot of people get caught up in the idea that products are better than services, because they only want to do things that scale (and a pure Services business is basically a consulting shop that refuses to admit it - this is the heart of the debate on Palantir’s valuation).
The truth is that most tech companies are a mix of both. At the largest scale, every enterprise sale involves custom integration work done by “Forward Deployed” or “Implementation” or “Success” engineers. At the smallest scales, startups have to balance their long term vision with short term “just for me” feature requests from their early design partner customers.
Performing Services gets revenue in the door earlier, while making sure you are hyper attuned to customer needs. Instead of being off in your own world building product nobody wants, you can make money serving your desired customer first, then build your product internally to serve your needs, and then eventually let the “Services Facade” fade away and users can use your product directly.
The Services to Product transition can take a long time and will never quite go away: Chetan Puttagunta, a notable software startup investor, notes that at $60m in revenue, half the revenue of software startups are services, but even at $800m, services revenue is still at 20%.
In the vein of Gary Bernhardt’s Functional Core, Imperative Shell, you could frame this phenomenon as Product Core, Services Shell.
Once you see it, it’s hard to deny that for entrepreneurs still seeking product market fit, offering “Service as a Service” before investing in “Software as a Service” can lead to a higher probability of success, and that though the Product component may grow over time, the Services component may never quite fall away.