You Will Probably Fail in a Boring and Project-specific Way
geeksinboston.com
geeksinboston.com
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."
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.
You'd probably benefit a lot more analyzing the reasons why you personally give up on projects than why someone else has.
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
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.
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.
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 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.
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...
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").
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.
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?
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.
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.
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.
Isn't that like saying "Everybody dies the same way - their heart stops beating." Yes, but there are many, many ways to die.
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.
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!
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.
But don't say Fortran as if it's slow, Fortran is still one of the predominant HPC languages :-)
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 :)
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.
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.
But for programmers with little user experience experience (urk), your point is a good one.
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.
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...
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!