The following is a guest post by Jason Cohen. Jason's got a knack for stirring pots and getting us thinking a bit. And, thinking is a good thing. Even when the thinking makes me awfully uncomfortable and goes against my strongly held beliefs. I couldn't be a stronger advocate of "Release Early, Release Often", so it took a bit of effort to post this article "as is". But, as I hope you'll see, Jason does make some pretty good points. Well worth debating -Dharmesh
[UPDATE: I originally stated that Eric Ries was a proponent of "Release Early," but I was completely wrong.] 
You can't throw a stone in the blogosphere without hitting someone arguing in favor of releasing software as early as possible. The idea is that it's best to push new software onto potential customers before it would be traditionally considered "ready."
Here's the general line of reasoning: In the beginning, you have a theory about who your customers are, what their pain is, what your product needs to do, and how it will be used. But it's just a theory, and it will always be wrong. That's OK! It's life.
Since you're wrong, your v1.0 is really just a foil to get people talking. Therefore:
- Don't add a lot of features, because you don't yet know which features are actually needed.
- Don't fix every bug, because half of this code might not be here in a month.
- Don't pretty up the user interface, because it won't look anything like this in a month.
- Don't obsess over the customer workflow, because it will change completely in a month.
- Don't worry about scaling, because you won't have that many customers for a while.
- Don't worry about architecture/extensibility/documentation because most of your code will be different in a month.
Now in general I agree with this line of reasoning, but I don't like how one-sided this discussion is. Even a casual glance through this discussion of the subject shows that people -- me included! -- are recommending this strategy as a knee-jerk reaction.
So for the sake of thoughtful debate, I'd like to present the case against.
The best ideas aren't built by consensus
Would the iPod have been invented if it were built by iterative customer feedback? I doubt it:
- Do you want a portable music device without a radio? No.
- Do you want a battery-powered device in which you can't change the battery? No.
- Do you want a portable music device without Bluetooth? No.
- Do you want a wheel-based user interface which you don't already understand and which makes certain operations confusing? No.
- Do you want it to take 5 clicks to toggle "shuffle," one of the most-used functions? No.
Apple doesn't ask customers what they want -- they just go invent awesome stuff. People complain, sure, but in the end the success of the iPod and iPhone is undeniable.
In general, disruptive products by definition cannot be built by consensus. In fact, it's well-known that "design by committee" is a sure-fire way to get mediocre design.
Small, incremental changes pulled by customers blind you to bigger, better ideas.
You're misinterpreting the 80/20 rule
The typical 80/20 rule is: 80% of your customers use just 20% of your features.
The "release early" folks take this to mean: Just implement 20% of the features you think you need, because if that's good enough to get 80% of your sales, this is a much simpler, efficient, and therefore profitable way to operate a software company.
But this interpretation is wrong! To spell out the 80/20 rule more accurately: 80% of your customers use just 20% of your features, but each customer uses a different 20%. That implies you need more features, not fewer, otherwise there won't be enough for the various use-cases for your software.
Take Microsoft Excel. Every person I talk to uses a different subset of functionality. Some people are experts at PivotTables whereas others have no idea how they work. Some people can't live without the database connectivity stuff whereas others don't know what a database is. Some people drive key business data using conditional formatting, some people know just enough Visual Basic to save themselves hours of manual labor, and some are experts with the charting system.
The point is that you can't just remove 80% of the features from Excel and expect 80% of the people to still be happy.
Mock-ups are faster than code iterations, without some of the drawbacks
There's a variety of software and techniques for mocking up applications, both web-based and desktop. Mockups can typically be built in a matter of days and put in front of customers for feedback. Iterating with fake screenshots is always faster than actually messing with HTML, CSS, and back-end code.
Once the mockups for v1.0 are set, actually writing v1.0 is fast because you know the goal ahead of time. The complete cycle is faster than if you started coding in the first place, and the code is cleaner because you don't have traces of major false-starts. (Think database migrations, CSS styles, extra AJAX routines, unused dialogs.)
Releasing too early can ruin your reputation
When your first version is sub-par, you'd better hope very few people find out about it.
Back to Apple: The iPod worked on day one, but back in the 90s the Newton didn't. The Newton (the world's first PDA) was hailed as a revolutionary technology (just as the iPod and iPhone would be), but it didn't work well. In particular, the handwriting recognition sucked and there wasn't a lot of apps.
It never recovered from its early reptutation as "doesn't do a lot, and what it does do doesn't work well." Even when that was remedied, it was too late.
The typical counter-argument to this is that "release early" doesn't mean "release with lots of known bugs," but rather "release with fewer features." But we all know the difficulty in separating a "feature request" from a "bug report" -- what a customer sees as a devistating lack of functionality (bug) you say is missing by design (feature).
Ignoring architecture creates waste
Software architecture is something the end-user never sees, and is therefore usually cast aside in the arguments for releasing early and collecting feedback. But incorrect choices in architecture can bite you later on, causing an immense amount of waste, possibly enough to sink the company.
It's true that most companies don't survive, and therefore having a growing user base with a problematic architecture is "a good problem to have." But it's also true that an ounce of prevention is worth a pound of cure.
Take Twitter. Their scalability problems are legendary. Suppose they didn't have billions of dollars in funding to throw expensive people and hardware at the problem? It's not hard to believe that continuing scalability problems would have sunk their ship.
Or take Netscape. The architecture problems with their browser were so severe it required a rewrite, which took so much time and effort the product (and company) died.
Of course this doesn't mean you should dwell on architecture for six months before working on features, but it does mean you shouldn't just ignore future maintenance issues for the sake of releasing a month sooner.
Untrue: "The worst thing you can do is built an unnecessary feature."
This is frequently used as an argument for releasing early. The logic goes: Every feature is effort. Not just in creating it in the first place, but debugging it, testing it, training customers on it, integrating it into all other features, supporting it in the user interface, covering it in the user's manual, and keeping it even as the product's focus changes. Therefore, never add a feature unless it's absolutely necessary.
I agree unneeded features are a major expense, provided you retain them in the product. But having incorrect architecture is also expensive, yet the "release early" folks tell us that expense is OK!
The fact is, you can change or even completely remove features that have become albatrosses around the neck of your tech support and product evolution. The "release early" argument also includes frequent iterateration, morphing the software as evidence suggests. Changing and removing features is simply a part of that, and doesn't imply that releasing early is smart.
In fact, adding features is one of the few ways to test what customers actually want, because:
Customers are notoriously bad at providing feedback
Sometimes users will tell you that they want a time/date-based voting widget they can send by email, when what they really mean is that they need to coordinate schedules.
In my experience customers are terrible at deciding what features they need, which features they use, or how features should be altered. They're much better at describing what's difficult in their life, what frustrates them, or what takes up a lot of their time.
Customers aren't even good at explaining why they did or didn't buy your product. From Jo Owen:
My research showed customers thought they were rational purchasers of video cameras: it was all about price and performance.
But when I interviewed them as they left a store, they were often unclear about how much they had actually paid for the model after splashing out for warranties, batteries and accessories and sorting out a financing plan. They were also very confused about the relative performance of different models.
Of course it's necessary to gather as much feedback as possible from both customers and lost-sales! But it's not clear how accurate the feedback is or how to weigh it against your own vision and goals for the product.
Relying on unreliable information as the primary driver of product decisions is unwise.
What do you think?
In the end, of course it's better to have more feedback than less, better to be more agile than less, and better to have technical debt with a successful product than a failed product. However, it's just not fair to present only one side of the argument!
Do you have more arguments either way? Do you agree we're taking "release early" a little too far? Leave a comment and join the conversation. Or, if you've got a question, you can post it on Answers.OnStartups.com