Interesting to see how this aged. By my reckoning:
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?
> 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.
Somewhat related, most academia is not focused on source code quality or its suitability for posterity. If you absolutely need to mime or plunder academia to succeed in your startup, pair that with a software industry veteran who can scale and secure your technology operation.
I have the opposite opinion. US funding sources for science and engineering tend to be very government-heavy rather than industry-based; but in my experience those government grants, particularly DoD, emphasize research with specific practical ends. The obvious exception is NSF, but Europe also has similar obvious exceptions at about the same rate.
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.
Yeah this is specific to Europe, in particular Germany, where companies such as BMW would send engineers to work on a defined research project at a university, and then adopt the research if it pans out. In the US there’s far more leeway, and part of being a good PI is stealthily inserting yourself own agenda into the DOT grant proposal, and those in the DOT will give you the leeway knowing that’s “how it works”
I guess this varies a lot. To my shame I don't have hard numbers (! I really should have.)
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: Start out looking at nanoparticle functionalisation, then stumble on a very useful sensor application or targeted molecular delivery.
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.
> 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.
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!"
The amazing programmer at xyz company on abc project may have a lot of infrastructure and support teams boosting their stats. Start ups can't afford the overhead that makes a programmer amazing. Visa versa, a start up programmer may languish in xyz company.
On the contrary, the amazing programmer at xyz company may have a lot of skills that they developed from working on a large number of different projects, systems, teams and so on, because the large company has provided them with the chances to practice all those skills.
Roles at large established companies are not normally like those at startups. They tend to be on smaller areas of functionality, more specialized, and with little variety unless you swap teams (and that's almost like getting a new job).
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 have to make things quickly, and not necessarily well. What you are building today may need to be retired in 3 months, if not earlier.
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.
It's about using the simplest thing that could possibly work, not about excitement. PHP is pathologically uncool, but it does work and it is fast for building new stuff. (God forbid you get stuck maintaining it though...)
I'll have to disagree. Having worked at a "large established company" during my career, I'd say that I've been given the chance to experiment with plenty of new things and projects are also started more often than you'd think, even though not all of them make it to a release. I understand your point, that just because you've worked at a large company it doesn't mean you have the right skills for a startup, however I will still hold my point: it highly depends and I wouldn't discard the opposite situation.
I’ve never worked in a large company where I would be doing everything from front end, middle tier, databases, CI/CD design, creating cloud networking infrastructure, dealing with vendors, designing operations, and talking with customers in the course of a month. This was me last month. Admittedly front end design is a major weakness of mine even though I do know JS well.
Might or might not, in my experience in about any team it is usually some of the people really understand the system, can develop etc. Then there are couple ones that mostly just slack off and enjoy the salary and benefits. Maybe even smart but just not willing to put in the effort. For outside interviewer it might be very difficult to tell which one the interviewer is talking to, both might have very similar CV.
If one has business sense.
Understands that projects can't run forever and they have to be either completed or killed by a certain date.Has a concept of cashflow. Isn't arrogant with ' the customer should know better' or 'Why would anyone do that?'. Knows the balance between 'this needs to be improved long term' and 'we need sales today' and how to keep both running. Doesn't get involved in idiotic keyboard wars about spaces vs tabs,etc.
Agree, didn't think of a lot of the points you make. However from my experience, "this needs to be improved long term" will stay exactly as is, forever, in favor of business requirements and it will be improved only when the business absolutely demands it to be.
"this needs to be improved long term" isn't really something you can put on a quarterly roadmap though. I think a good startup engineer knows how to keep track of these things themselves, and knows when and how hard to push on project leaders to get something done about it. Imo, most of the "UGH why doesn't the business side care about this!?" is really a lot of engineers failing to properly communicate in business-speak with the rest of the company. If we can barely explain the bounds of what "technical debt" means and how we handle it to ourselves within our domain in software, how can we possibly expect people involved with business requirements and money numbers to ever meaningfully understand this concept?
I'd argue that not all experience is equal. Sometimes developers with deep big-company experience have a skillset and habits that is great for big-company but terrible for a startup environment. The opposite is also true.
Plus all the things @cosmodisk said on the sibling comment.
No. It depends on where their experience lies and the balance of their skills.
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.
Except for UI - which I avoid like the plague - this describes me. UI is the easiest thing to outsource or get temporary contract labor or a boot camp grad to design to spec.
The problem with outsourcing in the early stages (MVP), is the speed of delivery. If you outsource it to a temp contract you are introducing a weak link in your delivery pipeline.
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.
I’ve never worked at an early stage startup. For the last decade, I have been hired at four companies after they had found product/market fit, they “moved fast and broke things” and saw their velocity slow to a crawl because what got them here won’t get them there. (I never fault a company for having a horrible architecture if it got them off the ground, they got funding and survived to get to the point they are (see Twitter).
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).
In a startup you need to wear many hats. At a large company you may have had a specific role ("front-end developer", "database administrator", etc). In a startup you don't have the luxury of not-my-jobism. Experience is of course great, so long as you have breadth.
If I were hiring for a startup. I would avoid someone who worked at Google. I would want someone who is wide not deep and could handle the stress and juggling that is part of a small company.
Google seems to have more “smart people” (tm) who don’t “get things done”.
> 2 (Bad Location) - this one became a horrifying monster that devours everything it touches.
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.
The original post makes it pretty clear that pg believes that, if you're not in a handful of locations, there's basically no point in doing a (presumably SV tech-style) startup.
> It probably means the founder couldn't talk any of his friends into starting the company with him.
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.
The best startups I've worked for have had multiple founders. It gives you multiple points of view. The company is less likely to make a mistake. And when it does, it's less likely to stay with it.
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...
Guilty of number 18, guess why it took two years between wanting to found and actually doing it.
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.
Valid point. Depends on what solution you are looking at, so. One extreme would Office, nobody would develop word, excel or outlook by themselves if that wasn't the product to be sold.
I wouldn't draw the line of writing software at "is software the product to be sold?", but rather at "does writing software gives us a true competitive advantage?".
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!
Nobody in my story was in the business of writing a word processor.
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.
yeah, the bias towards San Francisco got so strong that companies fight over every single college graduate that gets near there, inflating salaries to incredible levels, while tens of thousands of experienced engineers are underemployed in other cities. And the glut of overpaid 23-year-olds hasn’t exactly been good for making SF be a nice place to live
Bootstrapped, launched and sold two startups as a single founder. Launched a third one with academic cofounder . Was asked by VC "how much of a Prof is your Prof". Spot on as it turns out too much. Just saying...
> Not leveraging / building upon an unfair advantage — Network, Contacts, Insider information, Access.
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.
In the Wrong Platform section he mentions how the new PayPal CEO wanted to switch the company to Windows and “Fortunately for PayPal they switched CEOs instead.” That CEO they gave the boot? Elon Musk.
It was probably still a good decision and maybe we wouldn’t have spaceX or Tesla without that change, but still hilarious!
IIRC from reading the book PayPal Wars, Elon wanted to switch PayPal over to Windows because he saw it as the future. At the time, PayPal was on Unix. Max Levchin and the other main programmers didn’t want to switch. The disagreement on platform eventually came to a head and Elon was replaced by the board with Peter Thiel.
If you haven’t read PayPal Wars, it’s a great book.
Agreed. I think it was also a power struggle over which engineering team would be in control moving forward. Musk’s X.com was built on windows and he wanted everyone to switch over on the merge.
The Elon Musk biography has Musk's side of the story in the appendix. Paraphrasing, but basically he saw the tooling for Windows software development (Visual Studio etc) as being more coherent/batteries included/practical, in part because of Microsoft's investments in gaming and needing those tools to work on commercial games, which were stupidly complex even back then. Keep in mind Musk had some experience in the gaming industry. I'm not familiar with Linux, but it was likely rudimentary by comparison at the time.
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.
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.
On "bad location": consumer-focused startups will need to scale up fast if they get traction. Those are the ones that benefit most from being in SV: a pool of skilled labour they can bid their VC dollars + stratospheric ambitions on.
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.
I still firmly believe that a lot of people get the scalability/sustainability thing wrong, and then overhire like crazy.
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.)
> 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.
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 remember reading that too. I think Ben Horowitz might have talked about this in The Hard Thing About Hard Things, though I might be misremembering the source.
Hiring bad programmers is so common it's crazy. Most hacker news types probably won't know this, but there are so many startups out there than aren't VC backed and they have a limited dev budget. They try and hire who they think is good, spend all their money on programmer salaries, and then what get's built is a total turd. They never get traction because they keep failing to launch. Company dies. All too common.
The funny part is they scoff at an extra 50k for a better programmer, and then watch as that cheaper guy that looks good on paper writes a pile of garbage
True, but how can a non-technical founder know who is good, or who is just expensive? I've seen dev consultancies that are very expensive, and they play the part in every way, but they produce total garbage. There really isn't any way to know unless... well you know.
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.
Very insightful, as with most of Paul’s work. But it also shows a very specific mindset. In my opinion #15 was wrong back than and is even more obviously wrong now in 2020.
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.
The only mistake that kills startup is running out of money. Every other piece of advice is hand-wavy at best and lacks context. For example - How much is too much to raise? How much is too little? What constitutes a bad programmer?
I agree but don’t think “don’t run out of money” makes for very helpful advice, hence a bunch of other suggestions that help you not run out of money. If a doctor told me “don’t have a heart attack/stroke/etc” I’d probably have some follow-up questions.
> 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.
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.
Meh, I kind of think you're both right. I mean, while Google was just the evolution of a search engine, they did solve a very specific unsolved problem that the founders identified (namely, how to rank results in a manner that was a much better indicator of relevance and quality). When it comes to Facebook, people forget that before them, using your real name and identity online in a social network was extremely rare.
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.
I bet many of you have read all of Paul's essays, I thought I have read this one. I didn't know this one exists until today. Many of the points in 2006 are still hold true
I'm gonna take a stab at assessing the relevance of the mistakes to a self-bootstrapper:
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.
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?
> 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.
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!"
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).
Google seems to have more “smart people” (tm) who don’t “get things done”.
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.
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.
VCs love multiple founders because it partially mitigates the bus factor and creates a pressure point for the investors to exploit
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.
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.
20 is just awesome!
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.
wonder how the two ideas square up.
It was probably still a good decision and maybe we wouldn’t have spaceX or Tesla without that change, but still hilarious!
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.
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.
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.