
You Will Probably Fail in a Boring and Project-specific Way - shimon
http://geeksinboston.com/2009/01/07/you-will-probably-fail-in-a-boring-and-project-specific-way/
======
spolsky
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."

~~~
walterk
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.

~~~
pg
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.

~~~
patio11
_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.

~~~
stevewa
#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...

------
tdavis
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
You're better at this stuff than most other _teams_ , Tom.

~~~
tdavis
Thanks brother :)

------
puzzle-out
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
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-out
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.

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

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

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

~~~
m0nty
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.

~~~
ahoyhere
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.

~~~
m0nty
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.

~~~
ahoyhere
> 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...

~~~
m0nty
So this is the letsfreckle.com site? Looks really good, must be fun :) If I
was _still_ freelancing it looks like something I'd actually use, unlike 90%
of webapps out there.

~~~
juzmcmuz
Yeah, just discovered this myself. Looks like a super-professionally built and
designed web app.

