You Will Probably Fail in a Boring and Project-specific Way(geeksinboston.com)
geeksinboston.com
You Will Probably Fail in a Boring and Project-specific Way
http://geeksinboston.com/2009/01/07/you-will-probably-fail-in-a-boring-and-project-specific-way/
47 comments
But surely an analysis of the reasons why they stopped working on it would prove interesting?
I.e., what chain or confluence of events brought them to the breaking point, and what processes/practices could have prevented them from reaching it? I imagine there's probably a great deal to learn from even the most "boring" failures.
I.e., what chain or confluence of events brought them to the breaking point, and what processes/practices could have prevented them from reaching it? I imagine there's probably a great deal to learn from even the most "boring" failures.
The biggest reason founders stop working on their startups is that they get demoralized. Some people seem to have unlimited self-generated morale. These almost always succeed. At the other extreme there are people who seem to have no ability to do this; they need a boss to motivate them. In the middle there is a large band of people who have some, but not unlimited, ability to motivate themselves. These can succeed through careful morale management (and some luck).
I'd say about a quarter to a third of founders we fund have never-give-up morale. The rest are mostly in the middle group.
For the people in the middle group, I think the big danger is not knowing what to do next. That's why it's so important to launch early. Once you get something in front of users, they tell you what to do next. Not that you should do exactly what they tell you; you have to guess what they really need. But at least you start to have some data about that.
I'd say about a quarter to a third of founders we fund have never-give-up morale. The rest are mostly in the middle group.
For the people in the middle group, I think the big danger is not knowing what to do next. That's why it's so important to launch early. Once you get something in front of users, they tell you what to do next. Not that you should do exactly what they tell you; you have to guess what they really need. But at least you start to have some data about that.
unlimited self-generated morale
I have seen people learn this talent from two sources:
1) A deep, abiding conviction that they will get what they want because they always get what they want. 2) A cheerful disregard for other's predictions of failure (or well-founded empirical observation that the project is anything but a success) -- because "you've only failed once you quit".
Type #2 are much easier to have dinner with but I've certainly seen #1 work.
I have seen people learn this talent from two sources:
1) A deep, abiding conviction that they will get what they want because they always get what they want. 2) A cheerful disregard for other's predictions of failure (or well-founded empirical observation that the project is anything but a success) -- because "you've only failed once you quit".
Type #2 are much easier to have dinner with but I've certainly seen #1 work.
#1 makes me think of a Steve Jobs or Bill Gates type.
#2 is more optimistic.
But what if you started optimistic, but after years of dealing with stupid people who can't even write decent emails, your morale has fallen so low you can't stay excited?
Is there any way to recover, short of wiping your memory of the past and starting out innocent and optimistic again?
Or is that part of what makes it an exclusive trait of the successful, because it is very hard to stay optimistic over the long haul, therefore only a handful actually succeed...
Maybe the pharma industry can make "stay optimistic" drugs just for startups...
But what if you started optimistic, but after years of dealing with stupid people who can't even write decent emails, your morale has fallen so low you can't stay excited?
Is there any way to recover, short of wiping your memory of the past and starting out innocent and optimistic again?
Or is that part of what makes it an exclusive trait of the successful, because it is very hard to stay optimistic over the long haul, therefore only a handful actually succeed...
Maybe the pharma industry can make "stay optimistic" drugs just for startups...
There is always the possibilty of obvserver bias though. If you able to accurately assign the never-give-ups, middle and slacker groups before the process started then the 'attitude => result' case would be pretty watertight. But if you only determine that during their startup progress then it still leaves 'result => attitude' as a possibility. Beyond the obvious metrics, the founders may have a feel for the way things are going that they can't articulate but influences their decisions.
You could argue that 100% believing 'attitude => result' is the best way to think even if it is not so true. But it seems to me that each person involved in any endevour needs maintain their own cost/benefit analyses of the situation. If the costs mount and the chances of benefit shrink they are actually doing the right thing by changing path. I can see why this might not make for good coaching advice though.
You could argue that 100% believing 'attitude => result' is the best way to think even if it is not so true. But it seems to me that each person involved in any endevour needs maintain their own cost/benefit analyses of the situation. If the costs mount and the chances of benefit shrink they are actually doing the right thing by changing path. I can see why this might not make for good coaching advice though.
> For the people in the middle group, I think the big danger is not knowing what to do next.
That was the big reason for me. There were a bunch of contributing factors - rejected by YC 3 times, no luck with other outside investors, better opportunity came up, all other founders quit, scope of the project was much bigger than we envisioned, continuous problems simplifying the UI enough that I'd want to use it myself, and some doubt about whether current browser performance is even good enough to run the product - but I kept going through all of them until I really had no idea what to do next.
Joel's comment about it taking a long time before you can even know what knobs to tweak is right on. Early-stage products are almost completely wrong, and oftentimes they're so fractally wrong that nobody will bother telling you how to make them right. Launching helps, if you can get users. But many startups fail to get even one loyal user.
That was the big reason for me. There were a bunch of contributing factors - rejected by YC 3 times, no luck with other outside investors, better opportunity came up, all other founders quit, scope of the project was much bigger than we envisioned, continuous problems simplifying the UI enough that I'd want to use it myself, and some doubt about whether current browser performance is even good enough to run the product - but I kept going through all of them until I really had no idea what to do next.
Joel's comment about it taking a long time before you can even know what knobs to tweak is right on. Early-stage products are almost completely wrong, and oftentimes they're so fractally wrong that nobody will bother telling you how to make them right. Launching helps, if you can get users. But many startups fail to get even one loyal user.
> I'd say about a quarter to a third of founders we fund have never-give-up morale. The rest are mostly in the middle group.
What's the distribution of never-give-ups among YC startups? That is, do startups with a never-give-up tend to be composed entirely of never-give-ups? What are the dynamics for startups of mixed composition?
What's the distribution of never-give-ups among YC startups? That is, do startups with a never-give-up tend to be composed entirely of never-give-ups? What are the dynamics for startups of mixed composition?
There seems to be some tendency of never-give-ups to cluster, but it's not absolute. It's common to have one founder who's super determined and another who is less so.
If the never-give-up is sufficiently convincing, that's almost as good as having all never-give-ups. He drags the rest along. The dangerous case is the startup that has all middle of the road founders. These have to get lucky fairly quickly or they give up.
If the never-give-up is sufficiently convincing, that's almost as good as having all never-give-ups. He drags the rest along. The dangerous case is the startup that has all middle of the road founders. These have to get lucky fairly quickly or they give up.
Some people seem to have unlimited self-generated morale. These almost always succeed.
This sounds like 16PF Second-Order Factor IV: Subduedness vs. Independence -- also known as "field independence".
.
From Page 119-20 of the "Handbook for the 16PF":
Both the ratings and the primaries in Q-data support this pattern, describing a person who is independent, radical, autistic, projective, and a law to himself (hence the alternative designation of this dimension as "Promethian Will").
This sounds like 16PF Second-Order Factor IV: Subduedness vs. Independence -- also known as "field independence".
.
From Page 119-20 of the "Handbook for the 16PF":
Both the ratings and the primaries in Q-data support this pattern, describing a person who is independent, radical, autistic, projective, and a law to himself (hence the alternative designation of this dimension as "Promethian Will").
I don't think so, not so much. I suspect we're all experts to some degree at the myriad of reasons one has for giving up on a project. There's no reason to suspect the YC founders have any special reasons for giving up.
You'd probably benefit a lot more analyzing the reasons why you personally give up on projects than why someone else has.
You'd probably benefit a lot more analyzing the reasons why you personally give up on projects than why someone else has.
I'm not interested in the abstract reasons why people give up ("ran out of funding", "founders broke up", "burnout", etc.). We know all those, definitely. What I'm interested in are the specifics. What specific decisions (and in what contexts) led to a lack of funds, what specific disputes or personal issues led to founders breaking up, what shifts in the market made their startup not viable, and so on. That's the real world data that we don't necessarily have from experience.
I think people give up mainly due to lack of momentum leading to lack of motivation.
I can tell you how we failed with our first product. Bad design choices (that people would accept a large client download, that Mac wasn't that important) and a bad UI meant a bad user experience. Plus a lack of up front planning about why would users want to use us. Therefore the users never returned - the lack of momentum had a big negative effect on morale. Every day in the office was miserable then because we knew people weren't using/enjoying our product and we weren't growing.
We made a tough choice to abandon that first product and our new site is starting to rock and is heading in right direction. The positive momentum has such a big impact on morale and every day hearing a user say "I'm so glad I found this site" is best motivation to keep going through all startup challenges. So it comes back to momentum from users, and that comes back to good design and understanding what people want and why they would use your product.
just my $0.02
I can tell you how we failed with our first product. Bad design choices (that people would accept a large client download, that Mac wasn't that important) and a bad UI meant a bad user experience. Plus a lack of up front planning about why would users want to use us. Therefore the users never returned - the lack of momentum had a big negative effect on morale. Every day in the office was miserable then because we knew people weren't using/enjoying our product and we weren't growing.
We made a tough choice to abandon that first product and our new site is starting to rock and is heading in right direction. The positive momentum has such a big impact on morale and every day hearing a user say "I'm so glad I found this site" is best motivation to keep going through all startup challenges. So it comes back to momentum from users, and that comes back to good design and understanding what people want and why they would use your product.
just my $0.02
But that's a great example of a lesson to be learned from stories about quitting: sometimes you do it because a hard reset is the best option. Knowing where that point lies is valuable knowledge.
Personally, I want to hear stories about failure more than stories about success. Stories about success are boring and repetitive, because they usually revolve around some combination of luck and persistence. But the truly hard decisions in life come when you're spinning your wheels, and you need to determine when it's time to cut your losses.
Personally, I want to hear stories about failure more than stories about success. Stories about success are boring and repetitive, because they usually revolve around some combination of luck and persistence. But the truly hard decisions in life come when you're spinning your wheels, and you need to determine when it's time to cut your losses.
once we finally made the tough decision to abandon the first product, then designing and making the second product was so much (3-4x) faster, as we knew exactly what sucked the first time around and how to avoid all the inefficiencies as well.
so i guess, actually failure was very valuable. i actually see 3-4 much larger / better funded startups in our field who now are repeating the mistakes we made in our first product, but somehow I guess they won't be able to make that decision to change course.. easy when you're smaller and flexible.
so i guess, actually failure was very valuable. i actually see 3-4 much larger / better funded startups in our field who now are repeating the mistakes we made in our first product, but somehow I guess they won't be able to make that decision to change course.. easy when you're smaller and flexible.
"That would be boring," she told me, "it's always they same thing: they just stop working on it."
Isn't that like saying "Everybody dies the same way - their heart stops beating." Yes, but there are many, many ways to die.
Isn't that like saying "Everybody dies the same way - their heart stops beating." Yes, but there are many, many ways to die.
OK firstly you stole my point and secondly it is more accurate to say that most death is caused by lack of oxygen to the brain.
I fail to see what is so bad about saying that I have already posted pretty much exactly the same thing in exactly the same context. Scroll down and you will see my post. I think that originality matters and that it is better to merge duplicate concepts rather than reproducing them. As a matter of courtesy I will always read through the existing posts to ensure I don't post the same thing as somebody else.
You will probably also die because of a lack of oxygen supply to the brain but some people like to look for precursors. I agree with the broader point as it applies to life in general but obviously at a project, business and even career level it is important to know when to cut your losses.
I like your description of starting a business. The length you went in describing it suggests that many people reading it might not quite grasp the extent of its difficulty, and perhaps that's the more essential problem.
It's not unlike someone who gives up on dating after three rejections. Just keep going. There's still something to be said, though, for asking quickly and getting the response, rather than spending two weeks practicing your phone voice.
It's not unlike someone who gives up on dating after three rejections. Just keep going. There's still something to be said, though, for asking quickly and getting the response, rather than spending two weeks practicing your phone voice.
I see a lot of folks fail because they don't give up...on their first idea, and look for a second or third. Most teams that succeed make adjustments.
I remember back before we launched I was so worried that TC/Digg/Reddit traffic would bring the server down and I'd be a laughing stock. Then we launched, and...
Nothing happened. I mean, we got the traffic and all that, but the only way you would have known was to look at Google Analytics. The site was screaming fast (way faster than any competitor) and it was a pretty uneventful day for my sysadmin hat.
It was then I decided that maybe you don't have to architect some masterfully optimized site to survive traffic surges... you just have to use common sense and everything will be fine.
Nothing happened. I mean, we got the traffic and all that, but the only way you would have known was to look at Google Analytics. The site was screaming fast (way faster than any competitor) and it was a pretty uneventful day for my sysadmin hat.
It was then I decided that maybe you don't have to architect some masterfully optimized site to survive traffic surges... you just have to use common sense and everything will be fine.
Ha - I still remember that night/week. Tom and I were so worried that we took turns staying awake to make sure the Boogie Monster wouldn't take down TicketStumbler. I think I ended up sleeping 10 hours in 4 nights and puking my brains out before we gave our demo day rehearsal presentation later that week.
We had a similar experience with Twiddla. It just plain handled all the traffic that TechCrunch, ReadWriteWeb, LifeHacker and 100Shiki could throw at it, and all the traffic that came from winning SXSW too. Never moved the CPU over 15%.
The strange thing is that it was almost exactly the same magnitude of traffic that stopped Twitter dead in its tracks a year earlier, and subsequently gave them a ton of media attention.
Sounds like maybe there is some strategic benefit to falling down under load in a spectacular way!
The strange thing is that it was almost exactly the same magnitude of traffic that stopped Twitter dead in its tracks a year earlier, and subsequently gave them a ton of media attention.
Sounds like maybe there is some strategic benefit to falling down under load in a spectacular way!
I get annoyed with the "start quickly, fail early" philosophy. I think it can work in certain contexts - particularly consumer web, where the engineering is often quirky and superficial - but it just does not apply for real innovation based upon medium to long term software engineering, which is ultimately what pushes economic growth in the sector. The other point about this blog post: a 16 year old business studies student would point out, why didn't you do any market research? It's uncool, often pedantic and can become irrelevant quite quickly, but it should always be done, particularly if your putting so much effort into scaling the technology.
Quite true that market research is critical. However, the choice of potential markets to research is even more critical. One of the points I read frequently about successful startups is that the founders set out to solve some problem that they had: something that was interesting to them. Doing so gives you an inherent domain expertise - and internal motivator - you wouldn't have otherwise. For instance, I don't have any interest in having a home theater so working on software to control the different components of a home theater leaves me guessing, rather than knowing, what people with home theaters might want.
Couldn't agree more - the problem-fixing approach is fantastic for focus and motivation. My new startup follows this pattern, we're pre-commercial and the funders have got us to do market research in tandem with prototype development. I was a bit wary at first, wanting to jump into the problem fixing part with the engineer, but the more research I undertake, the more I realise that other people have also had the same problem, and tried to fix it; at least by knowing about these attempts we can save ourselves a lot of dead-ends in the problem fixing process.
In other words, don't optimize/scale prematurely... building a product that people want to use is many times harder than scaling that product.
Yeah, just don't go the cuil route and advertise heavily for a sudden spike-induced system failure.
Build up your traffic slowly, and ramp up your scalability with it. Bumps nobody minds (or really notices, really), it's the giant crashes that get noticed.
Build up your traffic slowly, and ramp up your scalability with it. Bumps nobody minds (or really notices, really), it's the giant crashes that get noticed.
Cuil's problem wasn't even that their site crashed (that was just a minor blip). Their main problem was that their search results weren't very relevant.
This article makes me think of Twitter, which didn't come up with a highly-scalable architecture initially (or even now really). The Fail Whales, though, were a sign that they were on to something big.
True, attracting users and traffic may not be easy and seems to be the fail point for many ideas, but why not consider scaling issues as well? With products like EC2, ruby on rails etc. its easier to plan for the "techcrunch" scenario than ever, so why build your site in fortran on a computer you bought at goodwill? In other words, once you get past the prototype stage, I think it might be worth it to take the extra 5 minutes to do a little research.
I agree with your sentiment as long as scaling is not a blind obesession.
But don't say Fortran as if it's slow, Fortran is still one of the predominant HPC languages :-)
But don't say Fortran as if it's slow, Fortran is still one of the predominant HPC languages :-)
Cue the hoary joke from the 70s:
Q: What will the High Performance Computing language of the 1980's be?
A: I don't know, but it will be called Fortran
That was one of my dad's favorites :)
Q: What will the High Performance Computing language of the 1980's be?
A: I don't know, but it will be called Fortran
That was one of my dad's favorites :)
I'm almost inspired to build a web site in Fortran.
And in terms of scaling Ruby is likely to be the cause of your problems rather than the solution...
We shipped http://letsfreckle.com without a lot of "features" that most people would consider necessary, banking on two things:
a) we wouldn't get a lot of initial signups, and we just wanted the positive feeling of shipping (and keeping our commitment to ship), and
b) just because a feature is considered required by common wisdom doesn't mean jack.
So, for weeks, you couldn't deactivate or delete a user account, or a project, or a number of other basics that we bypassed in favor of perfecting the "main dish": entering time.
We got a lot of unexpected traffic, so we were wrong on A. But even with 800 new accounts the first week, only one person wrote us noticing the "missing" features. By the time people caught on, we'd prepared those features for deployment.
Same goes for handling accounts where the CC couldn't be charged at the end of the 30-day trial. We had 30 days to deal with it.
It takes a lot of discipline to draw that line in the sand, and it's worked out very well for us.
a) we wouldn't get a lot of initial signups, and we just wanted the positive feeling of shipping (and keeping our commitment to ship), and
b) just because a feature is considered required by common wisdom doesn't mean jack.
So, for weeks, you couldn't deactivate or delete a user account, or a project, or a number of other basics that we bypassed in favor of perfecting the "main dish": entering time.
We got a lot of unexpected traffic, so we were wrong on A. But even with 800 new accounts the first week, only one person wrote us noticing the "missing" features. By the time people caught on, we'd prepared those features for deployment.
Same goes for handling accounts where the CC couldn't be charged at the end of the 30-day trial. We had 30 days to deal with it.
It takes a lot of discipline to draw that line in the sand, and it's worked out very well for us.
I've always been a "kitchen sink" programmer because that's the way I was taught to do it, and it's part of the fun of the job: anticipating everything which might go wrong and pre-empting it. Unfortunately, I noticed that I am a mere mortal anyway, so I could never anticipate everything.
Then about the same time I noticed that people would fall in love with very sucky products if those products did the core "thing" correctly. Crappy interfaces, poor layout, confusing buttons - didn't matter as long as people could work out how to do their task and get on to something else.
So, the next question I had to answer: why not just build something you consider sub-par in the hope that it will be useful to others, and perfect it later? Thinking like that lets me focus on what matters rather than wasting time working out which AJAX library to use or which colours would look best. Perfectionism really isn't a trait I admire any more.
Then about the same time I noticed that people would fall in love with very sucky products if those products did the core "thing" correctly. Crappy interfaces, poor layout, confusing buttons - didn't matter as long as people could work out how to do their task and get on to something else.
So, the next question I had to answer: why not just build something you consider sub-par in the hope that it will be useful to others, and perfect it later? Thinking like that lets me focus on what matters rather than wasting time working out which AJAX library to use or which colours would look best. Perfectionism really isn't a trait I admire any more.
Well, I have a reputation to protect as an interaction designer. I'm kinda a microcelebrity. People who know me have a high expectation of my work. (Surely not as high as I think, though, I'll give you that.)
But for programmers with little user experience experience (urk), your point is a good one.
But for programmers with little user experience experience (urk), your point is a good one.
One example of what I'm thinking of is the tarsnap website. Nothing fancy, and Colin mentioned in a blog post he'd rather get the code for his product right first (and from what I've seen it's good stuff) then work on the website. So sure, if you're an interaction designer you have to do the Right Thing. But it's easy to get paralyzed in the face of what looks like an overwhelming task when you should just pitch in, accept you're going to f*ck up to some extent, then rework it.
I failed a project last year through being too perfectionistic, so I'm trying to retrain myself not to be. Frankly, my standards were much higher than the clients' and I could have done half the work and been much more successful.
I failed a project last year through being too perfectionistic, so I'm trying to retrain myself not to be. Frankly, my standards were much higher than the clients' and I could have done half the work and been much more successful.
> accept you're going to f*ck up to some extent, then rework it.
Oh, I'm totally with you.
My app is far from finished. The settings area still sux. And we use lightbox-style overlays in a few places and I hate those suckers. And there's a lot more that I want to do with it, like, NOW.
But we did ship on the day we said we would. :)
The main reason we were able to do that was to first identify which missing "killer features" would not be apparent to people other than us. We, of course, had the perfect 2-years-down-the-road mental image of our project. We could never ship that.
But other people, coming to the app as newbs, would not know that we managed not to include <killer feature here>.
Then we ruthlessly qualified things as "good enough." I can't tell you how many times I said "Eh, fuck. Just ship it. We can make it better later."
I just wouldn't compromise on data entry. That's the whole point of the app. Then again, we didn't compromise on what we had, BUT we did leave out the other entry mode (still working on the design, a month later). So...
Oh, I'm totally with you.
My app is far from finished. The settings area still sux. And we use lightbox-style overlays in a few places and I hate those suckers. And there's a lot more that I want to do with it, like, NOW.
But we did ship on the day we said we would. :)
The main reason we were able to do that was to first identify which missing "killer features" would not be apparent to people other than us. We, of course, had the perfect 2-years-down-the-road mental image of our project. We could never ship that.
But other people, coming to the app as newbs, would not know that we managed not to include <killer feature here>.
Then we ruthlessly qualified things as "good enough." I can't tell you how many times I said "Eh, fuck. Just ship it. We can make it better later."
I just wouldn't compromise on data entry. That's the whole point of the app. Then again, we didn't compromise on what we had, BUT we did leave out the other entry mode (still working on the design, a month later). So...
That's a nicely designed site. Kind of a relief from the standard "Rate my Startup" submissions we've been seeing here lately. Makes me want to hand you money and try it out, even though I don't actually need the product!
On topic though, I'm also a big fan of releasing the "Meat" first and filling in the rest later. S3stat went live with a completely blank "Features" page and no way to charge CC's. Like you say, a 30 day Free Trial means that you don't have to actually be capable of processing payments the day you launch. It's a good motivator to ship that code though!
On topic though, I'm also a big fan of releasing the "Meat" first and filling in the rest later. S3stat went live with a completely blank "Features" page and no way to charge CC's. Like you say, a 30 day Free Trial means that you don't have to actually be capable of processing payments the day you launch. It's a good motivator to ship that code though!
Starting a business from scratch in a market that doesn't exist is like solving an equation with Newton's method, and you're starting with a really, really bad guess.
The first iteration or two is almost always a complete failure. You get such poor results you can't even tell which knob to turn to get better results. You start with another guess, maybe a different business altogether. It takes a lot of persistence even to get to the point where you can figure out that you're onto something that might work as a real business. Then it takes a lot more work to get to the point where you even HAVE knobs and dials you can turn to try to fine tune the business so it actually works.
I asked Jessica Livingston to speak at the business of software conference, and I suggested that she talk about all the ways Y-Combinator startups fail. "That would be boring," she told me, "it's always they same thing: they just stop working on it."