Editor’s note: This is a guest post by Andrew Montalenti. Andrew is the co-founder and CTO of Parse.ly, a technology startup that provides big data insights to the web’s best publishers. He blogs at pixelmonkey.org, where this post originally appeared. You can follow him @amontalenti on Twitter.
Startups die due to a variety of causes. Over the course of the last three years, I’ve watched many of my friends pour their hearts and souls into companies that, for one reason or another, just fizzled out of existence.
New York, meet the world’s tech scene
5,000 Tech leaders are coming to NYC this November to learn and do business. This is your chance to join them.
In 2007, Paul Graham gave a variety of causes for startup death in How Not To Die. He wrote:
When startups die, the official cause of death is always either running out of money or a critical founder bailing. Often the two occur simultaneously. But I think the underlying cause is usually that they’ve become demoralized. You rarely hear of a startup that’s working around the clock doing deals and pumping out new features, and dies because they can’t pay their bills and their ISP unplugs their server.
The other major thing Graham advises startups not to do: “other things”. Namely:
[D]on’t go to graduate school, and don’t start other projects. Distraction is fatal to startups. Going to (or back to) school is a huge predictor of death because in addition to the distraction it gives you something to say you’re doing. If you’re only doing a startup, then if the startup fails, you fail.
In early 2011, I wrote a post, Startups: Not for the faint of heart, that discussed Parse.ly’s survival through a one-year bootstrapping period after Dreamit Ventures Philly ’09. Since then, I’ve witnessed yet more startup deaths, and especially extended “troughs of sorrow”.
As a result, I’ve had a kind of mild survivor guilt, and have started to look for patterns in causes in the deaths I have witnessed.
Marriage Trouble: It has become a kind of cliche that founding partnerships at startups are like a marriage. But it’s a cliche that refers to an underlying truth. You will see and collaborate with your co-founder more than anyone else in your life during your company’s startup period. If that relationship is tense — if you can’t work well together and co-motivate each other through thick and thin — then the startup will fail. Unfortunately, the best you can do to avoid this is to make sure you know your co-founder decently well before deciding to embark on the startup mission with him or her. I have witnessed startup failures that were due to predictable co-founder conflicts.
No Bootstrapping Plan: Many startups that come out of an accelerator program (such as YCombinator, Dreamit, or TechStars) simply do not get funding. If you have the mentality that “without funding, I can’t work on my startup”, then your startup will likely die. This seems like a straightforward statement, yet many founders I have met don’t seem to make the connection.
Let’s say that you just quit your job to work on your startup. I have heard many founders — even in the first few months of product development — expect to raise seed rounds, pay themselves salaries, etc. This simply is not the right attitude. Expect to spend a year or two without external funding. If you are not prepared for that possibility — no matter how grim, financially — then you are not prepared to survive.
Startup is a Career Move: It may sound lofty, but a startup is your life’s work. You have to think about your company as a ten year project. Your first three years you will get the startup off the ground, establish your core team culture, and fully validate your main product/market through rapid iteration.
Your next three years, you will establish your company as a force in that market, grow your A-team, and scale your business. The next few years may take you in all sorts of directions. You may become a fast-growing business, full of potential and ambition. You may end up a stagnating but still profitable business, looking for exit options. You may end up a company in the difficult position of having to scale back or become defensive, due to market evolution, management blunders, or any combination.
But it will still be your company. Will you still care about the company’s mission ten years from now, no matter what position the company ends up in? If so, you probably have what it takes.
But, if you are treating your startup as a “career move” — a way to move up in the “startup ecosystem” and end up a C-level executive at some other, VC-funded rocketship, then, in all probability, your current startup will fail. It’ll fail because after year two, you’ll start to get antsy and want to move on with your career, and you’ll realize you never cared about the startup mission in the first place. It was just a means to an end.
Refusal to Change Original Idea: It has become yet another startup cliche that “execution is more important than ideas”, even one I’ve repeated on this site. But I witnessed many founders who were simply too attached to their original idea.
You should be obsessed with your company’s mission, but willing to change your company’s approach given new data or circumstances. It’s OK — almost every startup changes its ideas several times, especially through its early founding period. An unwillingness to change your original idea can not only waste your time, but also kill your spirits.
Paul Graham recently wrote that a “a startup founder is in effect an economic research scientist.” This is the way you should view your company. It’s an experiment. You’re trying to discover a product that will work for some market, while also being a hugely motivating space for you and your cofounders to work in for (potentially) ten years. What is that thing? It could be anything. You have to try a bunch of different ideas, until something sticks. No idea is sacred.
Pre-Emptive Scaling: This happens especially for startups that are founded primarily by technologists. There is no doubt about it — startups offer some amazing opportunities to exercise Computer Science and Systems Engineering knowledge. Engineering friends of mine regularly marvel at the amount of data companies like Google, Amazon, and Netflix (who were once startups, alas no longer) have to process, analyze, and serve.
Here’s the problem: this opportunity doesn’t exist for early-stage startups, because, by definition, they have no users or customers. Worrying about “scale” in the early days of your startup is simply a bad investment. You may not have even discovered whether a product or market is worth pursuing, but you will have already invested in scaling that pursuit. Therefore, technical startup founders have to develop a craft in rapid application prototyping. They have to use lightweight tools and build quick-and-dirty prototypes that can be used to validate concepts. They have two choices: incrementally evolve those prototypes into working products or scrap them in order to quickly rewrite them. Only once they have validated a product direction does it make sense to invest heavily in technical infrastructure.
Founders don’t realize how bad an investment pre-emptive scaling can be. This may be due to watching the occasional downtimes of Twitter and Tumblr, and thinking, “I don’t want to be responsible for that”. What these founders don’t realize is that if Twitter and Tumblr had invested all their effort into scaling up front, none of us would have ever heard of them.
Growing Too Fast: This is, I think, the biggest killer of post-funding startups. It can be very tempting to take in a little bit of seed capital, and start to operate as if you’re a big company. Chris Dixon wrote a nice list of things startups do and don’t need which captures this.
Growing too fast can kill a startup in a number of obvious ways, like running out of runway. But it can also kill a startup culturally. The more your company starts to feel like a big company, the slower you will move, and the more you will spend. This, again, feels like an obvious statement, but one often overlooked. Bigger companies simply move slower. Bigger companies simply spend more.
In order to justify adding another employee to your team, you have to feel confident not only that you have an appropriate core role for that employee to fill, but also that this employee is worth the added weight he or she will add to your company. More people does not simply mean additional labor. It also means more disagreement, more communication overhead, and a new branch in your company’s cultural tree.
And consider this: when your company is three people (e.g. 2 founders + employee #1), the single employee at the company is a 33% partner in building the company culture and products. (Note: I’m not talking about equity. I’m talking about the amount of influence that individual has in shaping the overall company.) Adding a second employee reduces the first employee’s “weight” in the company to 25%. Adding a tenth team member reduces everyone’s stake to 10%. So, growing more not only has the effect of adding more weight to the company, but also of diluting each employee’s decision-making stake (feeling of overall responsibility) in the company.
It’s easier for bigger companies to fail because it’s easier for each individual to abdicate responsibility for failure. People don’t realize this while things are going well, but they realize it big-time when things go badly. Success has a thousand fathers; failure is an orphan.
Scared of Code: This applies mainly to non-technical founders. In today’s market — where technology talent is in high demand — it can seem very, very expensive to rapidly prototype ideas that you will throw away. After two or three of those (and especially without a good understanding of sunk costs) a mentality will settle into the team that “coding is expensive” and thus “must be avoided at all costs”.
Founders will start to use every other means at their disposal to avoid it: spreadsheet modeling, potential customer surveys, mockups, etc. Many of these techniques can gather some useful market information. But nothing simultaneously focuses your team in its mission and gathers the most useful market feedback like actually building software prototypes.
The other reason I think not writing code can lead to startup death is that without concrete, tangible progress toward a product, it simply becomes too easy to walk away. Startups are all about persistence, and building your product is the way you can rally the troops, even as forces of negativity start closing in all around you.
How to Survive
I’ve explored various causes of startups death. This is by no means an exhaustive list, but illustrates some patterns I have seen over the years. You may wonder if I have any positive advice to offer about survival, rather than just cataloging the diseases I see in autopsies.
Startups are unknown battlefields full of landmines. Studying failures is, in many ways, a positive instruction. It’s a map of the landmines. As for concrete advice, I can offer this one suggestion: Be persistent.
In other words, to survive, you must continue moving forward. I don’t think startups win because they have smarter staff, better ideas, or a clearer understanding of market trends. Surely, those things help, but they aren’t the main thing.
The way to win is to keep playing.