TL;DR
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.
Context
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.
Product Core, Services Shell
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.
Top comments (1)
They need not be at odds. If one customer is asking for it, it's worth taking a step back to see how you might implement both the fulfillment of their request as well as the groundwork for a larger product feature (set). This is why I recommend sending user feedback directly to product backlog (refined through ongoing dialog with the user submitting it as needed).
This is similar to the "step back and look for common threads" approach I recommend to those with multiple product ideas instead of following the (usually VC-driven) mindset of focusing on one thing and dropping everything else. If there's enough overlap, working on or even just planning one product may improve another.