What companies failed because they released too early?


Most bloggers are saying you should release early, iterate often, and fail fast.

But some companies are notorious for releasing early, but then getting a bad reputation which led to their failure. Sometimes they corrected the problems but couldn't redirect the reputation.

What companies do you know like this? And then: What should we learn from those specific stories?

Getting Started Features Failure Release

asked Dec 19 '09 at 05:41
16,231 points

8 Answers


I think the "release early, iterate often, and fail fast" is often misquoted and misused. The origin of this phrase can be attributed to Eric Raymond. The release early, release often makes perfect sense, particularly since we as the developers don't always know what the consumer really wants.

So the idea is to release a minimal version which provides the basic functionality, and then to get users on board as early as possible. And observing the users closely will tell you what the additional functionality should be.

This is very different from just throwing a buggy broken version into the user's hands. Buggy is not equal to minimal.

My main take away - Focus on building the absolute basic functionality, but make it robust, non-buggy. Release it when you know it runs without too many crashes. Even though it doesn't have all the functionality that you would be proud of. Then observe the users, and iterate often to add incremental functionality.

Here is a set of learnings from Paul Graham on why startups succeed / fail And another set from Jason Fried on why startups fail.

answered Dec 19 '09 at 09:06


One startup that comes to mind is theglobe.com. They are essentially what MySpace and Facebook are today. Their failure is rooted in the dotcom bust of 2000, being that they went the IPO route and so forth. But I see it as a social media site as we know it today being way ahead of its time.

But for a textbook example of failing due to an early release, Pownce.com comes to mind. It was founded by Kevin Rose and band of his buddies. With his name attached it had all the typically SV press coverage it needed, but it failed because it was hard to distinguish what it was. Was it a Twitter clone, or a Facebook for co-workers? The execution of it fits the classic example of "let's get it out there, then think of a business strategy next".

I look at Pownce and it makes me realize that a startup, on launch, should solve exactly one problem first, and that problem should actually exist in the real world. They could have focused on a niche, such as office co-workers. When Google created a search engine, they did so to solve the problem that "search isn't smart enough, let's make it smarter".

answered Dec 19 '09 at 10:41
Joe A
1,196 points
  • Did Pounce really fail? It was acquired by Six Apart... – Jason 14 years ago
  • Yes it failed. Heard a talk from Leah Culver (one of the founders) and it didn't do so well. – Espinet 14 years ago
  • Jason, type pownce.com and read for yourself. SixApart acquired it for practically peanuts. – Joe A 14 years ago


This one is infamous, though probably not the type of software you are looking for

One of the problems with your question, Jason, is that many of the failed releases we know about are because they are companies we know and which exist today, so the data will be skewed to show that releasing early is not so bad - companies can survive.

The companies that fail after their first (too early) product launch are not going to be remembered for too long.

But this is still a good question. It certainly gathered a lot of discussion on Jeff's blog/SO blog.

answered Dec 19 '09 at 06:32
Tim J
8,346 points
  • Great point about survivor bias. – Jason 14 years ago


Sorry, don't have any specific examples to point to, but certain ideas come before their time. It may be hard to gauge whether it's time for your idea, but you can try to get a sense by looking at the cost of some fundamental materials you need to build.

Some examples - Apple Newton was a great device that just was ahead of its time - its price point / interface / speed wasn't such that became a huge hit. If it was designed today (and I am sure the rumored Apple Pad is a grand-child of that), it would be much different. I am sure there were lots of video startups in late nineties, but bandwidth cost too much and the idea of user-generated content wasn't as ingrained in average user's mind. There are a lot of services right now that would not work 10 years ago, because, for example not enough people had computers or internet / broadband access. One of the reasons so much software is SaaS now is because you can assume that your users will be able to connect - doing that even in early 2000 might be a harder sell in some industries. Same thing with mobile - lots of people have been trying to do stuff in that space five years ago, but the technology was too klunky for people to really use.

So release early, release often is valuable. I read it as release as quickly as possible with a minimal feature set (that works well), so you can start getting users and learning more about what they are interested in, so you can iterate to your eventual product.

answered Dec 19 '09 at 06:12
Jean Barmash
195 points


"Release often" and "Iterate Fast" only work AFTER you reach a minimum viable product threshold. If you release a crab, you will get bad feedback that you deserve and unless you have enough resource & run way, you will die. Again, don't confuse rushing product out to market with reaching the minimum viable product threshold which vary drastically by businesses.
For example, if you launch an enterprise focused product that needs to be sold by salesforce behind firewall, you better not release often. Also, would anyone want to buy infrastructure hardware and software that are missing some common features and constantly having updates? I don't.

One might argue that SaaS approach would enable customers to adopt this mantra but it's all relative. I guarantee you that the release cycle at Salesforce.com or even other brand new enterprise focused SaaS company delivering mission critical service is a lot longer than a consumer facing website that is launching another "community" site or twitter mashup app with no mission criticality.

The "lean" start-up mantra is admirable but you need to take it a grain of salt. Don't offload your sxxt to your customers. Define value and deliver them with the minimum viable product AND then iterate fast & release often.

I get antsy when some people keep saying "we have to release often!" Remember there is another much more time-tested advice...don't fix what's not broken.

answered Dec 19 '09 at 19:03
Jon S
21 points
  • Yes - releasing fast and often can create a usability and maintenance +1 for your last paragraph nightmare. – Tim J 14 years ago


I can think of two languages that were ahead of their time and so they may have been seen as being released early, since developers weren't ready for them.

The first is Smalltalk. It was one of the first OO languages, but there didn't seem to be any need for developers to change their paradigm, so it languished for over a decade.

The other was Erlang. It was developed at the same time as Java, but it required a paradigm shift, and since Eriksson wasn't ready to actively promote it, it's release was probably too early, so it is relatively recent in becoming more popular, as other FP languages become more mainstream.

There are some ideas, such as Cuil, http://en.wikipedia.org/wiki/Cuil, that should have been better tested and they should not have set expectations so high. If they had just come out, and had people try it, then, if it was better than Google, which they could have iterated before their was such a bad experience with it, then it would have spread by word-of-mouth.

Oftentimes it seems that new ideas will fail because of unmet expectations or the idea is too new and people don't truly see the use of it.

An example of that is the Wardenclyffe tower, http://en.wikipedia.org/wiki/Wardenclyffe_Tower, by Nikolai Tesla. If he had finished it we would have had pagers in the 1920's, but it was too far ahead of it's time.

I think there is less risk from releasing too early than too late. Generally, if an idea is ready then there will be several competing products in development at the same time, and if you wait too long, perfecting it, before releasing, then you may have lost your chance at a large segment of the market.

I think if you follow the customer development approach then, as long as expectations weren't set too high, and you can react very quickly to problems and reasonable feature requests, then too early won't be a problem.

answered Dec 19 '09 at 10:49
James Black
2,642 points
  • But if everyone follows this logic, there will be a lot of crappy new products out there, and the one that's more full-featured and less crappy might make a better impression, no? – Jason 14 years ago
  • The idea is to react quickly to the customers, so the new product should either improve quickly or people will move on to a competitor that is improving to meet the customers needs. Eventually there will be a few quality products, hopefully. – James Black 14 years ago
  • Why do you cite Erlang as a failure? Most proprietary languages are just that. Some make in mainstream and others don't. I don't think that by releasing they meant for it to take over the world. – Tim J 14 years ago
  • Why would you want customers with low expectations? – Tim J 14 years ago
  • The people using OO ideas more than adapted and basically wrote OO with the older languages. Migrating to a new language just because it supports some design principles is not the best reason. I don't think you can cite anything that came out of PARC as a failed release since it was an R&D organization - not a product organization. The lack of vision of Xerox and the missed opportunities from PARC is probably a whole set of other discussions though. – Tim J 14 years ago
  • @Tim - I am comparing the popularity of Erlang with Java, since they were developed at the same time. Also, customers don't have to have low expectations if your application isn't fully ready, but, if you don't react quickly to their expectations then they will move on, so they may be willing to give you a short chance to fix to get the application fixed, but you won't be given too long, and you will find yourself out in the cold. – James Black 14 years ago
  • @Tim - Moving to a language because it fits to the solution model best is the best reason to change. If you want to write a functional program using C you can use function pointers to do that, but it will be considerably more difficult than picking an FP program that best matches with the most appropriate solution. – James Black 14 years ago
  • James, I don't see the big deal with functional languages. They have been around forever. I was using Scheme in 1990. Erlang and Java weren't really products - they were free and initially developed for internal use. That is hardly a good case for discussion here. – Tim J 14 years ago
  • @Tim - They were both products in that people use them, and they led to what I was trying to give some examples of why some products may fail, as we generally don't hear about the vast majority of failed products, but the reasons that products fail can be found in other places, and just learn from history. For FP languages, with multi-cores the concepts of immutability helps to make more scalable programs, and some problems are better modelings with functions than objects. – James Black 14 years ago
  • +1 I immediately thought of Cuil. They pretty much bombed out of the gate. – Craig Daniel 14 years ago


I believe in Release often and Iterate Fast. Release early is subjective. If you release too early with bugs and missing important features, your product will get a bad rap and people will shy away from it and you will have to do damage control. When people visit a new site and get a bad first impression, it's hard to revisit the site in the future unless the site is getting a lot of good reviews, and which you are going to be aware of, which have to erase your first impression.

answered Dec 24 '09 at 06:15
384 points


I think there is also the strong possibility of some randomness and luck in the equation - things that can't generally be attributed to one reason or another why some site or product failed and a similar one took off.

answered Dec 20 '09 at 13:22
Tim J
8,346 points
  • Agreed, but sometimes it's clear that the company's reputation was tarnished e.g. by a product that didn't actually work, and then even after they fixed it (objectively) the market still thought it didn't. that's the kind of thing I'm after here. – Jason 14 years ago
  • Yep, I understand. We are going through that right now. Our market is financial institutions and we can't screw up the first release... we won't be able to recover. – Tim J 14 years ago

Your Answer

  • Bold
  • Italic
  • • Bullets
  • 1. Numbers
  • Quote
Not the answer you're looking for? Ask your own question or browse other questions in these topics:

Getting Started Features Failure Release