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/

by shimon • 18 years ago

80 46 18 years ago

spolsky• 18 years ago

You will probably fail because you give up.

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."

walterk3• 18 years ago

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.

staunch• 18 years ago

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.

pg2• 18 years ago

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.

shimon• 18 years ago

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.

dejb4• 18 years ago

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.

raghus• 18 years ago

"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.

dejb4• 18 years ago

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.

skmurphy• 18 years ago

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.

swombat• 18 years ago

In other words, don't optimize/scale prematurely... building a product that people want to use is many times harder than scaling that product.

lallysingh• 18 years ago

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.

aneesh• 18 years ago

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.

tdavis2• 18 years ago

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.

sachinag• 18 years ago

You're better at this stuff than most other teams, Tom.

tdavis2• 18 years ago

Thanks brother :)

fallentimes• 18 years ago

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.

jasonkester2• 18 years ago

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!

bhc3• 18 years ago

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.

medearis• 18 years ago

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.

timf• 18 years ago

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 :-)

LogicHoleFlaw• 18 years ago

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 :)

fuzzyman• 18 years ago

And in terms of scaling Ruby is likely to be the cause of your problems rather than the solution...

kragen• 18 years ago

I'm almost inspired to build a web site in Fortran.

puzzle-out2• 18 years ago

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.

bpyne• 18 years ago

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.

puzzle-out2• 18 years ago

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.

ahoyhere3• 18 years ago

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.

m0nty3• 18 years ago

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.

ahoyhere3• 18 years ago

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.

jasonkester2• 18 years ago

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!

You Will Probably Fail in a Boring and Project-specific Way

Related Stories