Using Google Docs to scale a lean startup

By Darrell Silver , written on August 5, 2013

From The News Desk

When my co-founder, Dan Friedman, and I started our company in October, 2012, we had no idea Google Docs would drive our product past a $500,000 run rate. As an engineer for the past 15 years, I depend on code to solve problems. But the last nine months have proven that the most important skill an engineer working in a startup can have is knowing when not to build technology.

This is counter-intuitive because we are a technology-centric company with an online adult education school. When we launched, however, we had no curricula, experts, product, money, or students.

“No biggie,” I remember Dan saying. “Let’s just start a class.”

By the second week in November, we were furiously seeking friends of friends who wanted to learn programming. We started with programming, because it’s a skill best taught through apprenticeship, which is core to our thesis about the future of online education. After a few dozen student interviews, we learned that successful adult learners are looking for career advancement over everything else. While Dan reached into his alumni network (even though he wasn’t technically a graduate), I called companies that wanted to interview our aspirational students after they finished the program. The two of us worked together building “Unit 1” of a curriculum in a Google Doc titled “Front-end Web Development -- prototype.”

The Tuesday before Thanksgiving, we sent invitations to eight precious (meaning they were paying) students who’d entrusted us with their education for the next three months. That students were willing to pay on day one was crucial to our customer validation. We used Lore as a community platform (another off-the-shelf tool) while splitting the mentorship of each student between the two of us.

Six companies, mostly in New York, were on board to interview students after graduation. That I was able to sign up businesses without any evidence we’d have anything to offer is a testament to how open the tech community of New York has become, and an indication of the tightness of today’s tech labor market. The faintest opportunity to hire qualified engineers was enough to get hiring managers on board.

In December, Citibank laid off 10,000 people across their technology divisions. I had just spent the better part of two months (not to mention the previous 10 years as a hirer) hearing how difficult it was to hire for technology. And that’s when lightning struck. As Dan and I were pitching an investor via phone, we were simultaneously mocking up a page enticing former Citibank employees to transition from finance into technology. Within four hours, our landing page neared the top of Hacker News, and other outlets picked up on it.

By the end of the week, more than 100 people had applied for our program, and a week later we started our second class with nine students. We had been using Google Docs in place of any product we could have created as quickly. It was painfully embarrassing, but students were succeeding and not complaining, so neither did we. We had plenty of other things to occupy our time.

For example, a lot of problems emerged, but this is when our tech strategy started to pay off. No custom software meant no technical debt. Virtually everything we had was a human-driven process, which at our early stage is easier to change than software. In hindsight, we were doing things that don’t scale, just as Paul Graham recommends. Not building technology was essential to how fast we were moving, and how agile we were, despite having “launched” a business from 21st St and 5th Avenue in Manhattan. Of everything else in the last nine months, this strategy for building an MVP is the one I most often repeat to new teams.

The problem with this iteration, as with many new products, was that we were trying to do way too much. The model was that students would learn with us, and we’d be paid recruiting fees by companies hiring engineers. But recruiting is a different business than education, and to be successful at it, we could only accept students that were already close to being ready for a job. This was both a major limitation for our growth and went against something we care about deeply: Learning on the Web should be about access to education, not exclusivity.

Also, application processes just didn’t feel right. The final nail in the coffin for our fledgling recruiting department was when Andrew McCollum, a member of the founding team from Facebook, asked during a partner meeting at Flybridge how many people there could possibly be who were almost ready for a job, but all they needed were three more months of part-time education.

All good insights are obvious in hindsight, and this was one of them. We don’t believe anyone can become a job-ready engineer in just three months. There are so many schools with just this promise, but not a single engineer at a hiring company that we spoke with actually believed it. Similarly, none of our students thought it was possible to learn so quickly either. Every successful learner of hard skills -- like building websites -- works at it for a long time before he or she becomes proficient.

Having both of these perspectives into our market (most business are two-sided markets in disguise) led directly to the next iteration of the company, which is basically where we are today. We’ve simplified our education to focus on exactly the type of learning we believe is the most successful: Long-term, at your own pace, helped by experts. It’s how I’ve always learned.

By March our “tech,” such as it was, really started failing, and that’s when we knew it was to build software. It was getting embarrassing to tell friends about our “stack,” which consisted mostly of a splash page on a $30 heroku site and about 20 Google Docs with email addresses and notes from each students’ mentor sessions. I swear, I’m an experienced engineer and this is the company I’m helping lead. We believed, and still do, that if we know what to build, we can do so quickly and for the long-term. But if we don’t, or aren’t sure, we shouldn’t build anything, or should build only as little as possible. It’s still embarrassing to talk about, and it’s still the best way to develop software for a company our size that I’ve ever seen.

When we announced our $1 million seed round we gained 400 prospective students over two days. One week later, we started using a customer relationship management to manage the now thousands of people who’d expressed interest in learning with us. This is the opposite of the “gear up” mentality of many startups, where tools and processes are put in place before an expected spike in traffic.

Most CTOs dislike press coverage, because it distracts from product development, which is a better long-term growth driver. Sometimes they’re right, but often they should rely more on human processes behind the scenes, which can be much more easily reassigned to coincide with unexpected (and positive!) events. Again, there’s really no such thing as technical debt for the members of a nimble founding team.

We’re only now replacing Google Docs with our own educational product. Still in the early days, many potholes lie before us, I'm sure. But when we roll out a new product, we'll  know exactly what technology we must address, and thus how to measure its success.

I challenge any startup engineer to come up with a better and more efficient technology strategy.

Image: Google