Mistakes That Kill Startups (2006)
paulgraham.com
paulgraham.com
1 (Single Founder) - people just ignore this one, more or less.
2 (Bad Location) - this one became a horrifying monster that devours everything it touches.
3 (Marginal Niche) - probably the biggest killer, then and now.
4 (Derivative Idea) - meh. People worry about this too much. Is there an unserved market?
5 (Obstinacy) - on point. Serve the market.
6 (Hiring Bad Programmers) - This one also became a horrifying monster. Graham says "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." Darkly hilarious in hindsight.
7 (Choosing the Wrong Platform) - meh. People use fucking backend Javascript now.
8 (Slowness in Launching) - Pretty valid.
9 (Launching Too Early) - maybe, I guess.
10 (Having No Specific User in Mind) - absolutely important. You have to be serving a market.
11 (Raising Too Little Money) - this pendulum has swung way over the other way now.
12 (Spending Too Much) - Yes. (Hiring too much. Stop trying to feel like an important funded company.)
13 (Raising Too Much Money) - Something of a subtle point, but still an important one - especially now that you can get too much money thrown at you more easily.
14 (Poor Investor Management) - of course.
15 (Sacrificing Users to (Supposed) Profit) - I'll just note that Graham writes that Google puts users first. Hindsight!
16 (Not Wanting to Get Your Hands Dirty) - Graham means with sales work. Very much true.
17 (Fights Between Founders) - This is why you vest, I guess. Graham was still down on founder vesting at the time.
18 (A Half-Hearted Effort) - I mean, why put in more of an effort if you have a route to fail upward?
Also guilty of number one, kind of. But that is more due to family /economic situation than a lack of a co-founder.
Regarding programmer and platform. There are so many cloud solutions out thereby now, unless softwareis your product, there is no need to develop it in-house. Take warehouse management and transportation management. Unless you want to built a new WMS or TMS, but build a service, just use the stuff that exists. Which make the programmer a guy able to appraise and implement said software. And like the programmer, one of the founders should be good at doing that.
An example: I once worked for a company that was successful in the translation space. Most freelance translators were using Word with some expensive plugins, but the company made the choice to use an app made in-house tailored to translation and that gave them a competitive advantage (faster iteration, less mistakes), so they basically replaced Word with an in-house solution. And their "product" was still the translations, not their hidden software (Of course this was back when Translation Management SaaS weren't popular).
Of course I've seen the opposite happen as well: I know a SaaS company that were in the business of selling blogs and CMS software. They had built their own blogging/CMS from scratch in the span of two years, but after six months launching, they pivoted to be a Wordpress host. Whoops, looks like customers just wanted a Wordpress anyway. They're doing ok now btw. (btw: I know that's a terrible example, since they turned out to be a service company rather than a software company).
Point is, writing a WMS or TMS would make sense for a non-software company if (and only if) it had completely novel ideas that would put them ahead of the competition. Of course that's a rare thing but still a good space to be explored!
Interestingly, that's probably another lesson on mistakes that kills startups: thinking that the only thing able to replace X is an exact replica of X.
20 Listening to anecdotal stories of others just to find excuses for the failures you made in 1-19.
20 is just awesome!
Lol. Pretty much by your definition all advantages are "unfair", but absolutely, yes, if you don't leverage your network and contacts you'll likely fail. But more importantly, I think if you think of "network and contacts" as some sort of shady underworld, you're already screwed.
Your network is mostly people you want to work with, and more importantly people who want to work with you. Heck, one major purpose of YC is to give the benefit of an amazing network to folks that otherwise wouldn't have access.
Though #1 (Single Founder), in my opinion, they still care unless the founder had the previous success startup, or had a team working with him/her.
> 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
Please don't shoot yourself with this suggestion. From my personal experience Academia is so distant from what is relevant or practical to the industry.
The big difference between the US and Europe, however, is that universities in the US depend on grants to fund PhD students. Many (most?) European countries have national funding programs for their PhDs, which frees up both the students and their advisors to work on whatever fancies them regardless of practicality. France is particularly notorious for this. US academics do not have this luxury.
In my field, by far the lion's share of impractical (Fun! I love it! But impractical) work comes from Europe.
Personally I've worked on a half dozen global research network projects bringing together both public and private funding and 10-15 organisations, mixed universities, research institutes, and small to behemoth companies.
The target is always some wide ranging new radical technology platform and they spawn a bunch of startups and spin off projects.
Some targets can turn out to be too difficult, or simply wrong, but I've never seen a project that hasn't lead to at least one startup / product / new technology.
Eg: Work on autonomous air sensor, then find simple off shoot application for tuberculosis using a completely different technology.
Eg: Build a medical laser for transdermal drug delivery then find applications in dental work and scar tissue removal.
Eg: Design a flexible heterogeneous compute cluster for hpc application, then get customers who want it for the low administration cost.
You start by bringing some very competent and diverse people together to tackle some tricky and new problem. Then after a while you'll have found a bunch of peripheral questions and applications for one thing or other you create in the project.
People talking and sharing experience and knowledge will almost always find new stuff out in the dark. If you're working on the edge of knowledge there is almost always interesting stuff hiding just outside the light of your personal flashlight. Bringing people together in multidisciplinary projects is amazing.
wonder how the two ideas square up.
Anecdotally I see a variant on this a lot. Many times I've seen programmers get hired based on pedigree. "You worked at [xyz company or on abc project] you must be an amazing programmer!"
Google seems to have more “smart people” (tm) who don’t “get things done”.
Starting something new is quite rare, and if it's done, it needs to integrate into a whole bunch of existing stuff one way or another; whether it's builds, deployment, auth, database, payments, UI stack, whatever - large chunks of the design space have been explored before and are pretty much set in stone unless you have a lot of political capital to spike something new, or the company is dysfunctional and doesn't standardize on anything, so that it doesn't present consistently to its users and its developers are less swappable between projects.
In a startup, you usually don't have the time or resources to play with tech and learn cool new things. Instead, you're hastily producing another simplest thing that could possibly work, using predictable tools you already know in and out. You're lucky if it's RoR or Node; you could be stuck with Go or PHP.
In an early-stage startup you work long hours, and are preoccupied with two things: how to divinate what the users actually want (usually nebulous and contradictory), and how to quickly make it work this way. You can easily lose track of what's interesting in the broader landscape, instead of enjoying new hotness as it gets released.
If you want some leisure, join a large established company, work efficiently, and you'll have plenty of paid time to fiddle with the cool stuff developed inside it, and elsewhere. Or become so advanced that a large company will task you with solving something actually novel, not amenable to off-the-shelf solutions.
What the heck? My strong sense nowadays is that most junior-mid engineers would be excited to use Go and disappointed to touch Rails.
Plus all the things @cosmodisk said on the sibling comment.
For a startup, you want wide and somewhat shallow experience. Since everything is an experiment, you want to crank out features and see what sticks.
I.e. you want a programmer that can do some UI / some app logic / some data science / some database / some infra/ops, (Not unlike a special forces person).
If you come from a big company, most roles are very specific / very deep - for example, a person works for 2 years on a file system kernel.
In addition, for your customers, the UI IS the product. Especially for the CxO level. So most of the "go/no go" decisions will be done based on the quality of the demo UI.
They needed to hire people to mentor and to help them implement better processes but at the same time being a hands on developer.
But, I have seen plenty of times where the company had an in house designer to design mockups of the UI and hire either a contractor that worked on site or a junior boot camp grad that knew $frontend_framework_of_the_week to save the heavy lifting for the senior devs/FTEs.
On one hand it seems like competent front end developers who can do “good enough” front end development and design are a dime a dozen and you can pay them peanuts. On the other hand, while I know HTML/CSS well enough to do some ugly internal site and I know JS well, I could never go from empty git repo to a well designed single page app on the front end. There is some type of mental barrier when it comes to me being a modern front end developer.
But if you give me a budget, time, and admin credentials to an AWS account, I can go from empty repo, no infrastructure to a fully baked backend solution with a full network infrastructure, database, cache, CI/CD solution easily (been there done that).
I can't figure out whether you mean that location matters or that it doesn't.
And in the first case, whether you think SF Bay Area is devouring everything it touches due to insane living costs and salary expectations, or whether being elsewhere means losing out on certain perceived network / opportunities.
re. 1), fun, since very young I was always told to never ever ever make a company with a friend or any kind of associate as all the experiences in/around my family of people making companies as associates failed spectacularly, while all the 1-person things worked out fine. Wonder if it's a cultural thing.
VCs love multiple founders because it partially mitigates the bus factor and creates a pressure point for the investors to exploit
With a single founder, it's very easy to go in the wrong direction. Because the person is stubborn, won't consider the alternatives, and has no "equals" to confer with, it often stays that way...
Obviously there are exceptions.
It was probably still a good decision and maybe we wouldn’t have spaceX or Tesla without that change, but still hilarious!
If you haven’t read PayPal Wars, it’s a great book.
Another good point he brings up is that you could find a lot of smart engineering talent, who is working on games, by using their tools/language of choice. SpaceX uses a similar tactic on a more subject matter level. People that can understand 3D game programming are probably a great pool of talent for writing rocket software.
a) They figure out how to get it to scale well enough to succeed. b) Musk learns he was wrong and they lose only a few cycles.
1. Not solving a real problem - Product / market fit
2. Raising Too much money - Growing beyond ability for the market to support
3. Hiring the wrong people
4. Too much founder ego
5. Too much founder inexperience combined with a lack of a desire to learn
6. Focusing too much on investor needs vs. customer needs
7. Spending too much money
8. Perfect is the enemy of good - Start small, think big, iterate often.
I think single founder issues, so-called "bad location" issues, derivative ideas are not really issues at all. The top 7 will kill you even if you have great locations. And there are many examples of great business started by sole founders outside the high expense "prime" locations.
B2B companies may be better off located in one of the top areas for the business vertical. For example, non-consumer FinTech startups may be better off in New York or London than SV.
If you ran a lean startup, would location be as much of an issue? Or asked the other way around: should all startups outside of the valley be lean startups?
It may just be the horizontal versus vertical question. A lot of the work I do, when to have the autonomy to do it, is to make sure that every developer can get more done, or be more certain that the work really is done. I’m trying to vertically scale developers.
In systems design, when communication is cheap you scale horizontally. When it’s expensive, you scale vertically. What have we really done as an industry to improve the effectiveness of human communication? I mean, really? Most of those improvements were made in the 90’s, a bit more in the 00’s, and everything since has been refinement (or regression.)
It’s pretty funny to see that in 2006 Elon Musk didn’t even deserve a mention of his name. How things have changed...
A new manager at Google wanted to shift Adsense (I believe) to Oracle Enterprise from MySQL. Some favorable MySQL benchmarks stopped that.
Responsys was all-Windows for quite a while. They eventually migrated their server farm to Linux. Almost certainly a combination of performance and an internal license audit (using Microsoft server products to scale a SaaS is brutally expensive.)
I'd love to find the source as I can't find it right now, bit I thought that was bc Apache could only fork back then, etc
Shit, nobody tell the Postgres folks that fork-only parallelism doesn't work...
The best way to figure it out is through a vigorous investigation of references I think, but even then, the past projects they worked on may have been better suited to their skills that what you're hiring them for.
The idea that you have to build first and monetize later has barely worked for some and forced many many many others to sell at no gain or close. We mostly saw the successful ones, but what happened recently with the likes of wework is causing that perception to shift.
#16 though is super important, and not just from the programmer direction. A good founder needs to understand the moving pieces of their startup, regardless of whether they have the training for that or not. I’m not saying they should be the ones to lead the effort on something they have no clue about, but they should be able to understand it. This is critical for single founders and important for multiple founders who make decisions together.
I’m not sure if I’d agree with that point. Google were not the first search engine, Facebook was not the first social network, etc.
I mean, for a user perspective, Google literally worked like other search engines at the time. You enter your phrase, see results.
Of course the results were better than Yahoo, the user-interface cleaner, etc. But that’s definitely incremental value for the user, not a whole new category of product.
Similarly, there were loads of dating apps before Tinder, but they solved a very specific problem: how to let either partner indicate interest withOUT letting the other partner know unless there was a match, in an intuitive way.
So yes, there are not many startups that are bold ideas that are completely new (for exceptions see Elon Musk), but they mostly DO bring something fundamentally new to the table.
https://www.roderick.io/feed/pg
This is the rss(xml). In most podcast apps you can add a podcast by url.
1. Single Founder: Plenty examples of successful bootstrappers on Indiehackers. There are also plenty of failed bootstrappers, but you likely won't hear about them obviously. The reasons pg listed for single founder failure is still valid for a bootstrapper though - it's a very lonely journey.
2. Bad Location: this is important for a different reason: as a bootstrapper relying on their own savings, I'd say location with low cost of living and fast Internet is the most ideal.
3. Marginal Niche: bootstrappers target niches since they're not focused on hyper-growth like conventional startups do.
4. Derivative Idea: not that big of a deal. Derivative ideas are pretty common amongst bootstrappers. You spend less time finding product/market fit if you work on popular/derivative ideas - but of course you'll also run into plenty of competitors.
5. Obstinacy: yeah, big killer. Be willing to adapt is sound advice regardless of your situation. The question is when do you know things aren't working well, or you just need to push a little more? Talk to users.
6. Hiring Bad Programmers: Definitely a killer. For bootstrappers who work alone, the question becomes am I skilled enough to build the product within a realistic scope and timeframe?
7. Choosing the Wrong Platform: people tend to use whatever they're most skilled at/comfortable with. It's still important that you do a survey of what's available out there before you commit, and always have a realistic migration plan when your success outgrows your initial scope.
8. Slowness in Launching: bootstrappers are big on the idea of MVPs and launching fast, but in practice, this is hard. Perfectionism is the bane of those who failed to launch.
9. Launching too Early: valid, but I imagine this is less of a problem for bootstrappers since you likely don't have much attention at the initial launch anyway.
10. Having No Specific User In Mind: totally valid.
11. Raising too little money: irrelevant.
12. Spending too much: I can't speak for all bootstrappers, but if you're bootstrapping from your own savings you're likely to be more careful with your spending.
13. Raising too much money: irrelevant.
14. Poor investor management: irrelevant.
15. Sacrificing Users to Supposed Profit: bootstrapped companies have to be profitable from day 1. There's no investor money to keep you going. I believe a good trade-off can be achieved here.
16. Not Wanting to Get Your Hands Dirty: yeah, arguably the most important one. Only way to deal with this is to constantly reach out to people and talk to them.
17. Fights Between Founders: totally valid, but irrelevant to single founder bootstrappers (plenty of these).
18. A half-hearted effort: a killer, for sure. But you don't necessarily have to quit your day job. Ideally, work part time as a consultant/contractor, and work on your business the rest of the time. It comes down to self (and time) management.