Scaling Lessons From The Fastest Growing SaaS Company Ever
5 min read

Scaling Lessons From The Fastest Growing SaaS Company Ever

An interview with Parker Conrad, the former CEO of Zenefits.

Zenefits is a 21st century HR company that’s aiming to be the one place to connect and manage all of your HR services. Despite being around for only 2 years, they’ve raised over $80 million in funding, and are currently valued at $500 million. As you might expect, the company’s had an unbelievable growth trajectory so far, and has been labeled the “fastest growing SaaS company ever.”

Recently, I had the fantastic opportunity to sit down with Parker Conrad, the founder and CEO of Zenefits. He shared with me some of the challenges that Zenefits has had with scaling at such an incredible clip, and the observations he’s had along the way. Here are five of them.

Note: The following interview excerpts are from my new book, Unscalable: Unorthodox startup growth stories.

Read more about Zenefits, GitHub, Codecademy, and a number of other companies.

Create automated processes one step at a time.

None of our forms were automated at first. What would happen is someone would go through online system and enroll in insurance and we’d get an email saying “so and so completed…,” and we would pull a DB extract of all their answers and fill out the form by hand. We originally hired someone to sort of deal with that, but over time it became mechanized. The PDF became automatically generated with all of the information filled out and signature attached to the bottom.
And over time this became more and more meta. At first we would manually fill the forms. Then we would automate form-filling but we would manually set up the automation. But every insurance carrier in every state has separate forms for all these different transactions. So they have their own forms, and you need to automate each of them separately in the system. It got to the point where we were spending all of our time automating forms. So we wrote software to automate form-automation, so someone non-technical could go in and upload a form, and just point out which point of the form to fill out with which information.

When dealing with established industries, expect things that don’t scale.

The most intractable area of [HR systems] — the hardest systems to deal with — are the insurance ones. They’re all stuck in 1986. And for companies with fewer than 100 employees, they don’t accept anything other than **faxes** to make changes to add or remove employees. It’s all on paper, all via fax machine.
And it’s actually even worse than that because not only are they using fax machines, but they’re unreliable in processing information. When you send them a fax to make a change, 90% of the time they do their job correctly, but 10% of the time the fax machine will come out the other end and whoever is in charge of processing that day had too much work to do and it got lost in the shuffle and it never happened, or they typed it in wrong and someone added employee A to company B and added employee B to company A, and you actually need to call and follow up and close the loop with every change that you make with the insurance company. You have to pick up the phone and make sure it was done correctly, and that’s the ultimate thing that doesn’t scale.

Sometimes you have to sacrifice scalability (and product) to get an edge.

At the time, we were actually racing another company in our Y Combinator batch. It was called Simply Insured. Originally it was fairly different from us, but about halfway through YC the founders decided that they wanted to do what we were doing, and the company pivoted into our market.
So we found ourselves sprinting to be the first ones out the door. Because the first company that launched would be summarized as “Company XYZ launches to make insurance benefits simpler for small businesses,” and whoever launched a couple weeks later would get “Company ABC seems to be derivative of XYZ and does the same thing and why are they doing the same thing as Company XYZ?” It wouldn’t matter that we had started our product first if they launched theirs first.
We wanted to just launch in order to get out the door. So when we had our launch article in TechCrunch, literally half the product didn’t exist yet. We figured that nobody was going to dive so deep into the product that they would actually get to [the end]. We reasoned that most companies would stop [halfway through] and want to talk to us. That gave us at least a couple of days after we launched to get the second half built.

Most people are caught off guard by exponential growth.

Even though we launched at the end of April in 2013, by January 2014 we had actually become the largest insurance broker in the state of California for new businesses.
This is interesting because insurance companies are not used to seeing their brokers grow that quickly. They looked at their top 20 or so brokers, and most of the those guys have been in that top 20 list for 30 years or longer. And we went from nonexistent to number 1 in 8 months. They couldn’t believe it, and suddenly we had a lot of VP-level people from all these different insurance carriers coming by our office and trying to understand how it happened. They asked us, “Hey, how can we work more closely with you guys, what can we do to get more business from you?”

Bottlenecks can come from surprising places…

With a lot of the things that scalable, you will find bottlenecks you never imagined that you suddenly need to find solutions for. For example, the way we were generating our list of companies to reach out to — there was a manual step in this process where someone had to copy and paste information into an Excel spreadsheet. We got to a point where that person could not physically do their copy/paste job fast enough and the growth of the company was literally constrained by this person’s ability to load the information into Excel and then our marketing software. Never in a million years did we think that would be a bottleneck for us. So we had to automate a lot of the process and build software around that.

…and premature optimization is still the root of all evil.

It’s a lot easier to figure out how to scale something that doesn’t feel like it would scale than it is to figure out what is actually gonna . You’re much better off going after something that will work that doesn’t scale, then trying to figure how to scale it up, than you are trying to figure it all out.
That’s what it comes down to ultimately — its so much easier to be focused on that once you know what works. And until you have something that is working, it doesn’t matter.

Interested in the rest of Unscalable? You can find the first chapter free at, along with paperback and ebook order links!