Insights from Paul Graham’s Essays

When I was in college, my economics advisor suggested that I write summaries of all of the nonfiction books I was reading in order to help the information sink in. I was doing an independent reading project with him and the summaries I wrote became the first posts on this blog.

Now that I'm a product manager, I'm doing a lot of independent reading again. It's not that I don't read regularly — I do. Reading is one of my favorite hobbies and I tend to read 1-2 books a week. But most of the books I'm reading now are nonfiction books I'm trying to learn from in order to be better at my job. I don't want to forget the information I've read, and so I figured I'd revive the practice of summarizing my independent reading here.

First up: Paul Graham's essays.

---

Paul Graham runs the start-up accelerator Y Combinator, which counts Dropbox, Airbnb and Justin.tv among its early-stage investments. He's also the former founder of ecommerce start-up Viaweb, which was acquired by Yahoo! in 1998 and may have been the first web application.

Graham's essays run the gamut from start-ups to public policy to programming languages to Silicon Valley culture to fundraising. Most of his essays are from the early-to-mid 2000s, so some of the specific technology trends he writes about can feel a bit dated now. But by and large his writing is evergreen, and his essays contain a surprising amount of career and life advice (and, let's face it: if you're working at a start-up, your career kind of is your life).

Here were my biggest takeaways:

1. “If you’re not embarrassed by the first version of your product, you’ve launched too late.” Actually, Reid Hoffman, not Paul Graham, said that. But while Hoffman coined the quote, Graham gives similar advice over and over again.
   If you release early, then you can start learning from your users. On the other hand, if you launch only after you’ve executed according to a grand business plan, then you'll find out too late that many of your original ideas were flawed.

2. Start-ups allow you to compress your working life into a few years. In a start-up, you work insane hours. But if you exit successfully after a few years, then you're set for life.
   Of course, to try this, you need a fairly high tolerance for risk. Typically, only 1 in 10 start-ups succeed. But there's no better time to try than when you're in your 20s and don't have a family to support (or other life commitments).
   Graham puts the turning point for most start-ups at "ramen profitability" — when the company is making enough money to pay the founders' meager living costs.

3. Maker’s schedule, manager’s schedule. Makers need long, uninterrupted blocks of time to do creative work. A meeting in the middle of the afternoon can make the afternoon unproductive even if the meeting is just thirty minutes long.

4. Webapps allow you to release quickly, i.e., multiple times a day instead of every few months. Building Viacom as a webapp allowed the team to stay ahead of their competitors. Customers also loved calling about an issue and then seeing it fixed later that day.
   (Side note on speed: Viacom was also built using LISP, a high-level and relatively obscure language. Graham writes how uncommon LISP was at the time — most software was written in C++ or Java. LISP's advantages as a programming language also helped Viacom outmaneuver their competitors.)

5. Put developers in touch with users. At Viacom, Graham and other developers would take support calls from customers. Most companies — even small, 10-15 person companies — don't do this and instead protect their developers with a dedicated support team. But I like the idea: developers in touch with customers have better insight into their customers' needs.

6. Don’t die. The best way to succeed as a start-up is to simply not die. Stay scrappy.

7. Graham also has lots of advice for fundraising, if your start-up is at that stage.