Founder’s Fumbles: The Most Common Mistakes

Recently, I’d been considering the successes and failures of many startups I’ve kept my eyes on, and the question I couldn’t get out of my head was that of — what made startups fail? After contemplating for a few seconds I realized this was kind of a trick question. It’s equivalent to asking how to make a startup succeed — if you avoid every cause of failure, you succeed — and that’s too big a question to answer on the fly.

Afterwards I realized it could be helpful to look at the problem from this direction. If you have a list of all the things you shouldn’t do, you can turn that into a recipe for succeeding just by negating. And this form of list may be more useful in practice. It’s easier to catch yourself doing something you shouldn’t than always to remember to do something you should.

In a sense there’s just one mistake that kills startups: not making something users want. If you make something users want, you’ll probably be fine, whatever else you do or don’t do. And if you don’t make something users want, then you’re dead, whatever else you do or don’t do. So really this is a list of 10 things that cause startups not to make something users want. Nearly all failure funnels through that.

What are some of the classic entrepreneurship and startup founder mistakes?

1. Multiple Founders

Have you ever noticed how few successful startups were founded more than one person, each with their own accompanying objectives and ideals? Even companies you think of as having one founder usually turn out to have more. It seems unlikely this is a coincidence.

What’s wrong with having more than one founder? To start with, it’s a vote of no confidence. While the entrepreneurial spirit at its core encourages innovation and individuality, the amalgamation of multiple egos, personalities, and goals cause a hodgepodge of corporate operations that tend to stymie the advancement of any corporate cause.

Most companies who have multiple founders tend to be comprised of a group of friends who see eye to eye on everything. What a business needs is a mix of different ideas that won’t necessarily clash with each other, but work together toward the common goal.

Working with your friends tends to cause a waste of time because you each have the same skills, hence why you were brought together in the first place. IF you do decide to have multiple founders, make sure you find those who are willing to add their ideas to yours to formulate solid, successful ideas.

2. Bad Location

Startups prosper in some places and not others. Silicon Valley dominates, then Boston, then Seattle, Austin, Denver, and New York. After that there’s not much. Even in New York the number of startups per capita is probably a 20th of what it is in Silicon Valley. In towns like Houston and Chicago and Detroit it’s too small to measure.

Why is the falloff so sharp? Probably for the same reason it is in other industries. What’s the sixth largest fashion center in the US? The sixth largest center for oil, or finance, or publishing? Whatever they are they’re probably so far from the top that it would be misleading even to call them centers.

It’s an interesting question why cities become startup hubs, but the reason startups prosper in them is probably the same as it is for any industry: that’s where the experts are. Standards are higher; people are more sympathetic to what you’re doing; the kind of people you want to hire want to live there; supporting industries are there; the people you run into in chance meetings are in the same business. Who knows exactly how these factors combine to boost startups in Silicon Valley and squish them in Detroit, but it’s clear they do from the number of startups per capita in each.

3. Marginal Niche

If you watch little kids playing sports, you notice that below a certain age they’re afraid of the ball. When the ball comes near them their instinct is to avoid it. I didn’t make a lot of catches as an eight year old outfielder, because whenever a fly ball came my way, I used to close my eyes and hold my glove up more for protection than in the hope of catching it.

Choosing a marginal project is the startup equivalent of my eight year old strategy for dealing with fly balls. If you make anything good, you’re going to have competitors, so you may as well face that. You can only avoid competition by avoiding good ideas.

I think this shrinking from big problems is mostly unconscious. It’s not that people think of grand ideas but decide to pursue smaller ones because they seem safer. Your unconscious won’t even let you think of grand ideas. So the solution may be to think about ideas without involving yourself. What would be a great idea for someone else to do as a startup?

4. Derivative Idea

Many of the applications we get are imitations of some existing company. That’s one source of ideas, but not the best. If you look at the origins of successful startups, few were started in imitation of some other startup. Where did they get their ideas? Usually from some specific, unsolved problem the founders identified.

Our startup made software for making online stores. When we started it, there wasn’t any; the few sites you could order from were hand-made at great expense by web consultants. We knew that if online shopping ever took off, these sites would have to be generated by software, so we wrote some. Pretty straightforward.

It seems like the best problems to solve are ones that affect you personally. Apple happened because Steve Wozniak wanted a computer, Google because Larry and Sergey couldn’t find stuff online, Hotmail because Sabeer Bhatia and Jack Smith couldn’t exchange email at work.

So instead of copying the Facebook, with some variation that the Facebook rightly ignored, look for ideas from the other direction. Instead of starting from companies and working back to the problems they solved, look for problems and imagine the company that might solve them. What do people complain about? What do you wish there was?

5. Obstinacy

In some fields the way to succeed is to have a vision of what you want to achieve, and to hold true to it no matter what setbacks you encounter. Starting startups is not one of them. The stick-to-your-vision approach works for something like winning an Olympic gold medal, where the problem is well-defined. Startups are more like science, where you need to follow the trail wherever it leads.

So don’t get too attached to your original plan, because it’s probably wrong. Most successful startups end up doing something different than they originally intended — often so different that it doesn’t even seem like the same company. You have to be prepared to see the better idea when it arrives. And the hardest part of that is often discarding your old idea.

But openness to new ideas has to be tuned just right. Switching to a new idea every week will be equally fatal. Is there some kind of external test you can use? One is to ask whether the ideas represent some kind of progression. If in each new idea you’re able to re-use most of what you built for the previous ones, then you’re probably in a process that converges. Whereas if you keep restarting from scratch, that’s a bad sign.

Fortunately there’s someone you can ask for advice: your users. If you’re thinking about turning in some new direction and your users seem excited about it, it’s probably a good bet.

6. Hiring Bad Programmers

I forgot to include this in the early versions of the list, because nearly all the founders I know are programmers. This is not a serious problem for them. They might accidentally hire someone bad, but it’s not going to kill the company. In a pinch they can do whatever’s required themselves.

But when I think about what killed most of the startups in the e-commerce business back in the 90s, it was bad programmers. A lot of those companies were started by business guys who thought the way startups worked was that you had some clever idea and then hired programmers to implement it. That’s actually much harder than it sounds — almost impossibly hard in fact — because business guys can’t tell which are the good programmers. They don’t even get a shot at the best ones, because no one really good wants a job implementing the vision of a business guy.

In practice what happens is that the business guys choose people they think are good programmers (it says here on his resume that he’s a Microsoft Certified Developer) but who aren’t. Then they’re mystified to find that their startup lumbers along like a World War II bomber while their competitors scream past like jet fighters. This kind of startup is in the same position as a big company, but without the advantages.

So how do you pick good programmers if you’re not a programmer? I don’t think there’s an answer. I was about to say you’d have to find a good programmer to help you hire people. But if you can’t recognize good programmers, how would you even do that?

7. Choosing the Wrong Platform

A related problem (since it tends to be done by bad programmers) is choosing the wrong platform. For example, I think a lot of startups during the Bubble killed themselves by deciding to build server-based applications on Windows. Hotmail was still running on FreeBSD for years after Microsoft bought it, presumably because Windows couldn’t handle the load. If Hotmail’s founders had chosen to use Windows, they would have been swamped.

PayPal only just dodged this bullet. After they merged with X.com, the new CEO wanted to switch to Windows — even after PayPal cofounder Max Levchin showed that their software scaled only 1% as well on Windows as Unix. Fortunately for PayPal they switched CEOs instead.

Platform is a vague word. It could mean an operating system, or a programming language, or a “framework” built on top of a programming language. It implies something that both supports and limits, like the foundation of a house.

The scary thing about platforms is that there are always some that seem to outsiders to be fine, responsible choices and yet, like Windows in the 90s, will destroy you if you choose them. Java applets were probably the most spectacular example. This was supposed to be the new way of delivering applications. Presumably it killed just about 100% of the startups who believed that.

How do you pick the right platforms? The usual way is to hire good programmers and let them choose. But there is a trick you could use if you’re not a programmer: visit a top computer science department and see what they use in research projects.

8. Slowness in Launching

Companies of all sizes have a hard time getting software done. It’s intrinsic to the medium; software is always 85% done. It takes an effort of will to push through this and get something released to users.

Startups make all kinds of excuses for delaying their launch. Most are equivalent to the ones people use for procrastinating in everyday life. There’s something that needs to happen first. Maybe. But if the software were 100% finished and ready to launch at the push of a button, would they still be waiting?

One reason to launch quickly is that it forces you to actually finishsome quantum of work. Nothing is truly finished till it’s released; you can see that from the rush of work that’s always involved in releasing anything, no matter how finished you thought it was. The other reason you need to launch is that it’s only by bouncing your idea off users that you fully understand it.

Several distinct problems manifest themselves as delays in launching: working too slowly; not truly understanding the problem; fear of having to deal with users; fear of being judged; working on too many different things; excessive perfectionism. Fortunately you can combat all of them by the simple expedient of forcing yourself to launch something fairly quickly.

9. Launching Too Early

Launching too slowly has probably killed a hundred times more startups than launching too fast, but it is possible to launch too fast. The danger here is that you ruin your reputation. You launch something, the early adopters try it out, and if it’s no good they may never come back.

So what’s the minimum you need to launch? We suggest startups think about what they plan to do, identify a core that’s both (a) useful on its own and (b) something that can be incrementally expanded into the whole project, and then get that done as soon as possible.

This is the same approach I (and many other programmers) use for writing software. Think about the overall goal, then start by writing the smallest subset of it that does anything useful. If it’s a subset, you’ll have to write it anyway, so in the worst case you won’t be wasting your time. But more likely you’ll find that implementing a working subset is both good for morale and helps you see more clearly what the rest should do.

The early adopters you need to impress are fairly tolerant. They don’t expect a newly launched product to do everything; it just has to do something.

10. Having No Specific User in Mind

You can’t build things users like without understanding them. I mentioned earlier that the most successful startups seem to have begun by trying to solve a problem their founders had. Perhaps there’s a rule here: perhaps you create wealth in proportion to how well you understand the problem you’re solving, and the problems you understand best are your own.

That’s just a theory. What’s not a theory is the converse: if you’re trying to solve problems you don’t understand, you’re hosed.

And yet a surprising number of founders seem willing to assume that someone, they’re not sure exactly who, will want what they’re building. Do the founders want it? No, they’re not the target market. Who is? Teenagers. People interested in local events (that one is a perennial tarpit). Or “business” users. What business users? Gas stations? Movie studios? Defense contractors?

You can of course build something for users other than yourself. We did. But you should realize you’re stepping into dangerous territory. You’re flying on instruments, in effect, so you should (a) consciously shift gears, instead of assuming you can rely on your intuitions as you ordinarily would, and (b) look at the instruments.

In this case the instruments are the users. When designing for other people you have to be empirical. You can no longer guess what will work; you have to find users and measure their responses. So if you’re going to make something for teenagers or “business” users or some other group that doesn’t include you, you have to be able to talk some specific ones into using what you’re making. If you can’t, you’re on the wrong track.