A Services Firm Makes A Great Startup
I believed the wrong thing for a long time
I’ve always been under the impression that building SaaS products was a better path to success than building services firms. That assumption was likely because it was also the overall consensus among many people building tech startups. SaaS products have large fixed costs (e.g. developers), but the operational costs (e.g. AWS infra) are minimal. You can grow revenue without necessarily adding more developers. Customers are mostly self serve so headcount does not need to grow as more are acquired.
Contrast that with a services business where every new customer needs a certain number of human staff hours allocated to service that customer. Your margin is set by the multiple you can charge for those staff. If I pay a staff member $100/hr, I need to charge a client $500/hr to get an 80% margin. While some larger consulting firms manage to get 5x-10x their staff’s hourly rate, most smaller firms are at around 3x. That caps your margin at 67% assuming you have zero overhead. A SaaS product is usually expected to have a 90-95% margin.
This mindset gave me tunnel vision for what I wanted to build. I spent several years attempting SaaS product after SaaS product. To bring in an income, I was consulting on the side. The consulting was going so well that I was turning away quite a bit of work, but that never felt like success because it wasn’t a SaaS product.
Fast forward to the end of 2023 where my business partner and I are struggling to get sales of our SaaS product. Our product was solid. We knew it was solid because my business partner was using it for his accounting firm. Tasks that took hours now took minutes. He switched from billable hours to a fixed monthly cost, resulting in clients paying less and him making more per hour. Despite that win-win, making the switch takes effort and we could never convince anyone else to make that effort. We, like many SaaS products, wanted customers to change how they did things in order to use our product.
Some startup advisors chastised us for solving our own problems instead of talking to customers to learn about their actual problems. The most obvious solution was to go back to the drawing board and talk to all those accounting firms to see what they would buy.
The other option was realizing that our target customers had clients with a problem that we could solve: their accounting firms. We decided to pivot to being an accounting firm instead of selling software to accounting firms. I overcame my hesitancy to build a services firm for two main reasons:
Most SaaS products are built on also providing human services or relying on third parties providing those services
Building a services firm is the best product research you can do
B2B SaaS products are services firms in disguise
When thinking about SaaS businesses, it’s important to separate consumer products from business products. Consumer products *have* to ensure extremely low friction. A user must be able to come to the application and know what to do almost instantaneously while also getting some joy out of that use. The tech behind a consumer product may be extremely complex, but the use case is simple. Building a streaming service? A user needs to be able to watch videos. Building a game? A user needs to be able to play it without reading a manual (no one has the patience that gamers had back in the 1990s). There is a singular action that users want to take with a particular product and the developers have to optimize the UX for that singular action.
Business use cases are a lot more varied and a lot more complex. Most users can’t just start the software and know what to do. Developers can’t just focus on the UX for one use case because every customer will want to start off somewhere different. Using JIRA as an example, a small team starting to use JIRA may just want to start creating tickets whereas a larger team will want to plan out systems ahead of time. JIRA is also relatively simple compared to a lot of other B2B SaaS products. With Datadog a new user could be running their systems on prem, in a cloud service, or have a hybrid cloud setup. That user could be buying Datadog when setting up a new system or trying to insert it into a legacy system. That user probably also has the networking and firewalls set up in a very different manner than other users.
Because of this complexity, one of three things end up being a prerequisite for starting to use a B2B SaaS product:
there is someone on staff who has previous experience with the product
a services firm is hired to provide their expertise with the product
the company selling the product has a services division to help customers onboard
Regardless of where the source of that human labor is, users will only be successful with that SaaS product if human services are provided with the software service. That means the SaaS product is also only successful if there is a complementary human service to support that product.
I’ve often seen a lot of startups provide “data” in an abstract manner with the expectation that their customers will figure things out for themselves. These startups made the same mistake we did. Business customers are pre-occupied with building their own business and dealing with their own problems. They don’t have the time to do your work for you and figure out where the value in your SaaS product is. You need to do the work to make that value clear for each customer.
Providing services is incredibly effective product research
Consumer software often has a significantly better UX than B2B software. Part of this attributable to the simpler use cases. A big part though is also attributable to the fact that the developers on consumer software applications are also users of those software applications. Someone working on an e-commerce application likely also buys things online. Someone working on a streaming service likely also watches videos. Someone working on a search product likely searches for things on the internet.
Being a user means that the developers have some intuition of what makes that product good. No one would ever consider having a user make 2-3 clicks to pause a video. Lower quality video is also more acceptable than choppy video. This intuition smoothes out the development process significantly. When there is ambiguity in requirements, and there is ALWAYS some ambiguity in requirements, the developers will likely resolve that ambiguity in a reasonable manner.
In B2B software however, the equivalent of having a user make 3 clicks to pause a video happens all the time. Developers are not salespeople. They are not accountants. They are not doctors. They have no intuition about the needs for professions that their software is used by. The results of ambiguity in requirements are a lot more bothersome to deal with:
the developer sends an email and waits for a response
the developer waits to bring up the issue in a meeting
the developer makes an intuitive decision that is based on bad intuition
The first two scenarios slow down development, but the third is a lot more consequential and more likely to happen when tight deadlines are enforced on a team. The resolution of the third outcome happens when a release build is being reviewed by stakeholders. There is also usually more than just one intuitive decision made. The time to rework all of them (assuming there isn’t yet more ambiguity) could be days or weeks. Do you delay the release? Or release anyway and then put the revisions on a backlog that the team will never get to? Odds are the latter decision will be made and will compound with subsequent releases that have the same problem.
Building intuition is a difficult problem. The solution is simple on the surface, but the execution is difficult.
I once worked on B2B software for K-12 schools. It should go without saying, but we did not have any K-12 students on staff. Having a developer be a user is not feasible here. The best thing I could think of was to have the developers on my team take turns pairing up with the support team every week. Instead of hearing user feedback through a long telephone chain, they worked with that feedback directly. It wasn’t perfect, but the team did start to make better decisions such as spending a few minutes improving the error messaging which meant support could resolve an issue themselves without having to put in a ticket with the engineering team.
There are situations where having a developer be a user is possible and in those cases it should be done. One of the more well known examples of this is Basecamp. 37Signals started off as a web design firm. They built Basecamp out of necessity in order to manage their projects. Whether you like Basecamp or not, it was built with real use cases in mind and it works for those use cases.
I also worked with an IoT data startup that started off as an IoT consulting firm. They took the knowledge they gained from every contract and started building a product that they could eventually sell.
We’re doing something similar now at Eight One Partners. I work closely with the accountants on our staff. I do the books for our firm. I’m building intuition on what accountants actually find useful. The result is better product built quicker. Example: there are many lease applications out there. Most of them had an entire development team work on them for years. I built ours in a week. That has little to do with programming ability. I guarantee that the code would fail any technical interview at a big tech company. It is an example of good intuition at work. It also results in a better user experience. Our staff can see an amortization table instantly after inputing the lease information. Most other lease applications require you to wait a minute or so for a spreadsheet export. I can only assume that those applications took into account 1 million year leases whereas ours performs just fine up to 100 year leases.
The only thing that differentiates us from other companies that have built products on their services business is that I’m not convinced I would want to stop being a services firm.