Releasing Early Is Not Always Good? Heresy!

About This Blog

This site is for  entrepreneurs.  A full RSS feed to the articles is available.  Please subscribe so we know you're out there.  If you need more convincing, learn more about the site.



And, you can find me on Google+

Connect on Twitter

Get Articles By Email

Your email:


Blog Navigator

Navigate By : 
[Article Index]

Questions about startups?

If you have questions about startups, you can find me and a bunch of other startup fanatics on the free Q&A website:

Subscribe to Updates


30,000+ subscribers can't all be wrong.  Subscribe to the RSS feed.

Follow me on LinkedIn


Current Articles | RSS Feed RSS Feed

Releasing Early Is Not Always Good? Heresy!


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.] OnStartups No Hear

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

Posted by Jason Cohen on Mon, Dec 21, 2009


Well said. It's funny cause it seems to me that a lot of the people that carry the 'release early and often' flag are also Mac fans. 
Like almost any complex subject you can't blindly apply some general rule and expect it to fit every situation. 
There is a lot to be said for JFDI though:

posted on Monday, December 21, 2009 at 4:12 PM by Justin

I definitely see both sides of the case, but we in particular chose the wait-til-its-nice-and-pretty-and-works-for-the-most-part route. We just launched last week, after having worked on it on and off for a year, and then myself full-time with part-time help for another year. Let me first say that while we only officially launched last week, our doors have been open for most of those two years and we have had a good amount of active users throughout our active development process... it's not like we were stealth or anything remotely resembling it. 
Breaking my train of thought for a second - I think bringing Apple into this is a bit wrong. Yes they are the perfect example of disruptors with a knack for getting it right on their own, and that's why I think they are out of place here when talking startups. Companies like did not release "early" but rather were in active development for quite some time. I remember visiting their HQ back in the Summer of 07 and they were going out to coffee shops with surveys asking people their opinions on this or that. It was very much design by committee (from my outside perspective). 
As for "80% of your customers use just 20% of your features, but each customer uses a different 20%." - I definitely agree and that's where we took attention to detail for some tiny features that only a few use, but they are a vocal few. 
I also agree with "Changing and removing features is simply a part of that, and doesn't imply that releasing early is smart." We were always adding features and didn't stop to do any marketing - aside from my own ramblings on my blog - until we were comfortable with the state of the product. By no means are we anywhere near the vision we have for the product, but we're close enough to getting down our core competency. That being said, there were lots of things that kept getting built, and some that were heavily refactored or just completely removed after we found they were too hard to use, or just weren't being used. 
Getting back to my initial thought - so our startup launched after a rather long time (which could have been a bad thing if sizeable competitors entered the market, and there are some out there but not exactly stepping on our feet). The launch went well from my perspective - for one, the comments on our TechCrunch article were remarkably positive, so much so that one commenter thought something fishy was going on. We have been around in some form long enough that beta users came around and congratulated us on the article and so on. We also snagged around 1,000 new users from the TC posting.. I'm not sure where that ranks on the grand scheme of things, but we're happy! 
And of course, my shameless startup plug:

posted on Monday, December 21, 2009 at 4:22 PM by Paul Stamatiou

Thank you for finally saying out loud that users don't know what features they want - but rather they know what problems they have. I'm all for building a culture of urgency and agility, but the constant drum beat of "Release Early Release Often" is too simplistic to be meaningful. It's sad to me to see people being encouraged to "don't be visionary, be reactionary."

posted on Monday, December 21, 2009 at 4:25 PM by RUss

The "Lean Startup" and Agile models are in some sense the embodiment of the Scientific Method applied to software development. Form a hypothesis (some theory about what consumers want), then devise an experiment (a new feature or piece of software) that you can use to test your hypothesis. Rather than speculating about what users want, the approach says, don't speculate - test. Then you can really know what matters. 
Here's the interesting part though - anybody can form a hypothesis. There are good scientists and bad scientists - what differentiates them? It's not the quality of their tests or experiments, it's the quality of their hypotheses. This is where I find the Lean Startup model doesn't really provide enough guidance. How big of a hypothesis should I test? A world-shattering new insight? Or a more modest theory? The bigger your theory, the more variables it has, and the harder it is to test. As Einstein said, "everything should be as simple as possible, but no simpler". If you have grand ambitions, the "release early and often" approach may not get you there. People form opinions about what your service *is* very quickly, and it's hard to change that opinion down the road. Even though Yelp covers everything from Plumbers to Dry Cleaners to Bed and Breakfasts, for most people it is and forever will be a Restaurant Review site, because that's where they started. Your first release, as buggy or lacking in features as it may be, should paint the picture for what you want your startup to be when it grows up - and no less, and it needs to work well enough that people will come back a second time. 

posted on Monday, December 21, 2009 at 4:26 PM by Mark Watkins

I do not agree that it's easy to remove a feature. 
Example from - an invoicing app: when support for quotes was added, people immediately started to create and send them. Now could the feature be removed now? Delete data couple hundred people have entered? Invalidate quotes that were already sent? (luckily the feature turned out to be successful). 
I remember Github announced closing gem hosting feature. I can still hear the uproar...

posted on Monday, December 21, 2009 at 4:31 PM by Wojciech Kruszewski

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. 
Absolutely. Early versions of Memory Validator allowed people to select function names they didn't want to instrument when detecting uninitialised data.  
When we removed that feature (probably a year or more after release), not one person complained. That validated our decision. No one was using that feature that couldn't live without it. 
We removed it because we thought it was just added complexity that outweighed the value it added. 
We're currently slowly, cautiously reengineering the bowels of our tools to undo some of the mistakes (that resulted in less reusable code than we could have had) of the release-early phase of our company. Its more costly and slower than you imagine. Release early isn't quite what its cracked up to be. 

posted on Monday, December 21, 2009 at 4:33 PM by Stephen Kellett

Finally, some common sense! I've never been a big fan of the "throw software at the wall and see what sticks" philosophy. As in all things, there is a balance between speed and quality. I especially agree that highly iterative development that's "designed" by customer feedback ends up being mediocre. Hosted software (SaaS) has the advantage of being capable of more frequent iterations, and that's a good thing, but anything of value--and that includes software--needs vision, planning, and design behind it.

posted on Monday, December 21, 2009 at 4:37 PM by Eric Lenington

@Wojciech -- I certainly accept your critique that "removing features is NOT easy." Good point. 
But I wasn't saying it's easy to retire features, just that it's possible. It's also not "easy" to rearchitect a product, but it's possible. I'm saying it's not necessarily worse than other things which "release easy" is supposed to provide. 
For example, in your case you could prevent NEW users from seeing the feature, and not add more to the feature. Yes that means maintaining for existing customers, but only a few, which is different than supporting for everyone. Also you COULD phase it out even for them, e.g. they can't create new ones.

posted on Monday, December 21, 2009 at 4:46 PM by Jason Cohen

I think it depends on the definition of "committee".  
I'm not a believer in the heroic entrepreneur model, and so putting several heads together (including potential customers) when developing a complex product is usually a good idea. But putting too many together, i.e. releasing it to the general market, will result in so many conflicting opinions, it's all but worthless. It just becomes an unmanageable continuous focus group. 
So,I agree that the release early and often mantra is misconstrued. I would change that to release early to BETA testers (i.e. selected early adopters) so they can tinker with it and make it more functional for the larger group that follows them. This is probably closer to the hypothesis model, but is more controlled.  
Tony Wanless 

posted on Monday, December 21, 2009 at 4:46 PM by Tony Wanless

Your examples products are from Microsoft and Apple...not exactly the companies I think of when reading "OnStartups." They have the money and market control needed to focus on building a complete product at the expense of time to market. Few startups have this luxury (particularly given how funding models have changed in the last five years). 
I agree that building by consensus is a bad strategy, but there's nothing about the lean startup model that says you should do this....instead your goal is to find innovators who have enough pain and vision to work with you as you build out the full solution.  
The concerns over reputation and scale are only issues if you follow the traditional big launch approach. If you're going to spend $20K a month on a PR firm and launch at Demo/TC50, it matters, but this isn't the lean startup approach. Initially, you're not looking for broad acceptance of your product. You're looking to get it in the hands of the people who will be passionate about it despite it's limitations (both because of current capabilities and long-term potential).

posted on Monday, December 21, 2009 at 4:53 PM by Paul May

I think it really interesting that so many seem to have been taken in that this release early thing is standard. 
A simple rule like that is clearly moronic. There's a lot more to it than a general rule for everything. Some of the points are raised here, good, well done. 
Much of the software, especially web 2 stuff is pretty junky under the skin. Just try using it a bit and you'll find servers crashing or overloaded, code that fails regularly and designs that surprise in their flat out wrongness. 
I chuckle at a lot of the things that the media gush over. 
I think some people are taken in by this initially, the smart ones soon realise that a lot is wrong. They can't be bothered to do a proper job themselves, but one day competent people might get involved! 
If you want misinformed, impressionable people during the early no-profit-in-sight stage then maybe follow some of the advice that somebody dreamed up in fifteen minutes so that he could make his self imposed blog article quota. 
(I know the tone of this is a bit harsh, it is about Web 2 rather than other releases. Sorry for that. In the last few days I have been evaluating a bunch of web things that I've tested recently. I've stopped my suspension-of-disbelief and the cold light of being real has been harsh on them.) 
A lot of this stuff may go somewhere eventually but much of it is experimental.

posted on Monday, December 21, 2009 at 4:59 PM by Mike Gale

While I definitely agree there are times to NOT release early, I think this glossed over a major piece of Steve Blank's argument. In The Four Steps to the Epiphany, Steve very specifically states that the traditional product development life cycle might work for large corporations who can afford to take big chances, but that it doesn't work very well for small startups. It is presented very much as a risk mitigation tool. 
Given that, the iPod / Newton analogy is clearly flawed...not much of a startup at this point. Apple could afford to fail with the Newton. A startup attempting the same thing would of never had a second chance.

posted on Monday, December 21, 2009 at 5:00 PM by Tristan Kromer

I am one of those that just wants to get it out and then figure it out later. My partner is a former gunny sergeant marine and he believes it all has to be correct to take it to market. I am sure you can imagine some of our conversations (disagreements). However, we offset each other enough that we come out with a working product. We spec out the project with what it's core purpose or value is...what is it supposed to do. We think ahead for user experience, ease of use, ease of integration and implementation. Then we take out the bells and whistles and push them to phase 2, 3 or whatever. What that does is allow us to launch a working product that fulfills it's purpose. You can sell that to customers all day long. Then we go into phase 2 and enhance the product and then with some feedback from the users, we do the third phase to finish out the product.  
I don't know of a perfect product/software. There is always things to improve or add on. Though I am a heavy advocate of release early, I have the scars, wounds and bruises to prove that it can be very dangerous. Hey, we all have a sense of urgency, we all need more revenue, we are all behind on the budget, but taking out a crappy or unfinished product or service, just to get it into the marketplace, is much worst. Take the time to get it right the first time, but don't waste your time on the initial launch version with a bunch of bells and whistles. Plan for phase 2 and 3 or more. It might just be worth it.

posted on Monday, December 21, 2009 at 5:03 PM by Phil Huston

I like the mock idea. Actually, I like the pre-sell idea. Larry Ellison (Oracle), the story goes, pre-sold so much the company got in trouble. The idea being, focus on what the customer is willing to pay for and what it is they find of value. Get them to commit and then build your best shot at what you promised them. Don't release, pre-sell it :)

posted on Monday, December 21, 2009 at 5:27 PM by Jose daVeiga

Excellent article. It really made me thinking alot, and about a very good and important subject. Thank you!

posted on Monday, December 21, 2009 at 5:54 PM by Perica Levatic

I think this is an interesting debate. I just launched my first startup and struggled a lot with this decision. I kept telling myself it would be better to get the product out there in front of potential users, but there were always just a few more bugs/things that weren't just right. 
I finally decided to just get it out there in front of people and continue to work on the site. It's never going to be perfect - and it can't even be close to perfect until you know what perfect looks like. Your users will tell you that.

posted on Monday, December 21, 2009 at 5:55 PM by Tony

It is convenient to use Apple as the poster child for go into your cave and let the genius shine. It should be noted though that Apple's leader is a product visionary (and a marketing genius). If you work for a company where your CEO is a product innovator and has the chutzpah to go all out - more power to you.  
It is more often the case that (atleast in medium size enterprise software) the CEO has a background in sales or marketing. In these situations, "release early" has the advantage of arming one with facts and the voice of the market to drown out the torrent of well intentioned but poorly researched _opinions_ that come from internal leadership. The sooner a product is being guided by market research the better and releasing early is one way of ensuring that. In some cases it may be expensive but in other cases it might be the best way to educate internal leadership.  
This is less pronounced in the case of a startup that is releasing its first product versus a company adding a new product to its existing portfolio.

posted on Monday, December 21, 2009 at 5:56 PM by Amar Rama

Apple and the ipod doesn't help make your side more convincing. They already had significant brand power and a fanbase that somewhat mitigated the risk. Nevermind the fact that Apple loves prototyping and letting people test then iterate (albeit internally). Feedback from a Jobs+Ives+great people are not resources you can immediately have in a startup so data/feedback from users is essential. Another wrench to throw is the 'release early' concept is mostly applied to startups around software not hardware. For software, the magic formula would be minimum viable product + measurable data/feedback + good interpretation + agile team + lean.  

posted on Monday, December 21, 2009 at 6:43 PM by twidlit

Jose brings up a good point. Don't release early, sell early.  
Selling early is often easier than releasing early and has the advantage of getting to the customer value quickly. Users may clamor for a feature, but if it isn't a feature that will sway them one way or another in a purchasing decision, adding the feature does little to help get to profitability faster. 
Selling the product before release can also have the advantage of financing the development while at the same time focusing on the customers who are willing to put their money where their mouth is. It gets rid of the biggest problem of eliciting feedback, getting feedback from people who will never buy your product anyway (or may never buy at a price you can make money at). 
When we consider adding a requested feature, I've learned to ask "if we add this feature, do I have your order?" or "we can add this feature, but it will cost extra, do you still want it?". That quickly reduces the set of features to those that have actual value--something you won't get by releasing early or often. 
As a developer, it often pained me to see features requested again and again that we ignore for years. Yet it has been the right business decision. Pre-selling features, and even entire products, has enabled us to avoid low value features and sometimes even stopped development on products entirely.  
As a final plus, the 18 months it took before we released our first product gave us time to develop a flexible architecture that has given us a solid foundation that now allows us to rapidly add features when required. 

posted on Monday, December 21, 2009 at 6:51 PM by Trevor Lohrbeer

Jason this is definitely very thought provoking blog. Obviously some of what you say here, I agree with some I do not. 
First and foremost, let me ask you a question “How do you define early?” or “What is too often?” are these definitions with reference to traditional enterprise software life cycle or are these evaluation based on the quality of the product? In my opinion, as long as you meet you criteria for releasing a product, even if you do it earlier (than originally planned) there is no harm in that (provided criteria was not defined to allow early/fast release and it was focused around completeness and holistic customer requirements).  
I also believe that product features is a way to address customer challenges/problems. Best way to add product features is to make sure that each product feature addresses customer pain point or makes customer’s life easier. Technical and product designers should take liberty in the way they solve problems and that is where creativity and innovation comes into picture (Google wave, Gmail’s tagging feature etc…). “Product features is means to the goal of solving problem, they are not the end”. I would not go so far as saying customers are bad in terms of providing feedback; Customers traditionally talk about their problems in their terms/language. Many a times technical/product people now want customers to talk in terms of product features and that is where discussions around product features/feedback goes downhill. I think, as a product person, if you listened to the business problems highlighted by users and then provide creative solution for that problem, development of features/functions is a very creative process.  
I totally agree with your argument about how costly it is if one gets architecture wrong. Getting one or two features implemented incorrectly or at subpar level is much better than getting the architecture wrong. I personally believe that architecture choice has much more to do with business model (economic/structural) as well as business execution model (than the reason that someone released half baked product).  
Vish Agashe 

posted on Monday, December 21, 2009 at 7:14 PM by Vish Agashe

With all due respect, it sounds like first class rationalization to me. As others have said, Apple is not the appropriate analogy. If you are a future Apple, go for it. But most startups are not an Apple (and THANK GOD for that!) 
Yes, there are some valid points but the better point would be to be pragmatic and take all advice with a grain of salt, even that contained in this post (and in this comment too!)

posted on Monday, December 21, 2009 at 8:19 PM by Mike Schinkel

As others have pointed out, the mantra of "release early, release often" is relevant only to a certain subset of internet startups. Some start up's require more back end work before they are even possible, a site that offers games to it's community for example goes no where unless at least one game is ready for users to play. The same can be said about sites that provide services that are highly integrated with third parties as far as enabling or facilitating data transactions (say as travel sites do) ...a certain amount of work is required in these situations on the back end before you can even consider presenting anything to the user.  
The pattern should present itself by now, the sites that have a large percentage of their success in the development of a useable UI (as opposed to some back end wizardly that shines through a UI) are the ones that are most likely to benefit from "release often, release early" these are subject to the advantages of fixing UI issues that may mar the useability of the site without futzing with the back end magic provided by the site or service considerably.  
So, a site that is only providing aggregation of feeds from outside sources or something similar (Twitter) can benefit from release often, release early ...the technology for doing Twitter is dead simple the hard part of it was the scaling and that was the part they let hang in the wind and the only reason they succeeded was because the founders had previous capital accrued from previous positions in other startups and new people who got them the funding they needed to burn through the issues. Most startups are not this if you know that your secret sauce is going to take 6 months to get right, then take the time to get it right then put a face on it and get it out and iterate that as soon as you can..the invariant quantity is the secret sauce development time after that the mantra of "release early, release often" makes sense before that it makes trouble. 
David Saintloth 
Founder and CTO Apriority LLC,

posted on Monday, December 21, 2009 at 8:23 PM by David Saintloth

This is excellent write up. 
Sometimes it is not about "idea", but about quality of service/product.  
Did iPod have any killer feature? Not really. It was just the best MP3 player. It worked.  
What about Google and Yahoo!? It is just that Google search was better.  

posted on Monday, December 21, 2009 at 8:30 PM by Senad Dizdar

It's easier for Apple than it is for a start-up to develop disruptive technologies and get people to buy them despite their flaws. I'm glad I just released my start-ups product early. I know that half the features weren't needed, but I didn't know which half. My early customers unanimously led me to a bigger pain point that my product concept could solve, which resulted in a 10 degree shift in my direction.

posted on Monday, December 21, 2009 at 8:38 PM by Jeff Ernst

I think one would have to agree with both sides of the argument. The problem lays in the fact that know one has yet defined What is a early release? At what point are you early, and at what point in your product are you too late. 
In some ways Apple's released a complete product, in others it was early, else they would not have had upgraded versions, with more memory etc.  
So the problem is not in releasing early and often, nor is it in building the perfect software and then releasing,its actually in defining the point at which you are early/late. 
Was twitter early, because it had not built an infrastructure to manage its customers, or was it late in that the application did what they wanted to do 100%. Was Facebook early or late, they have added lots of features, hence that would make it early, but based on what the founders thought the market wanted, they had built 100%. 
The problem with "early" releases is that users do not know what they want. To use an old analogy: If you had gone to someone who owned a horse driven cart, and asked them what they want, how many would have described the Model T Ford. Sometimes you need to put ideas in front of people. How many people knew they needed Facebook, or felt the desire to communicate using 140 characters on the web. 
There is NO early or late release of an idea, there is only release. Whatever you build, you will change, hence it will never be complete for all, but for others it will.  
One of the first webmasters of AOL once said "Build it just good enough, otherwise you will be too late". The key is to find out what is "just good enough" 

posted on Monday, December 21, 2009 at 8:50 PM by Iqbal Gandham

Everyone says Apple's not a good example, even though they had this behavior since their inception. 
OK, but there's lots of other examples! 
Take Twitter. It's a revolutionary idea that most people probably would have said "wouldn't work." And they didn't iterate through features. In fact they almost don't have any features. 
Take Seth Godin's books and his approach to selling them. No publisher would have done it (or at least, they didn't). No publisher would agree it would work. But he just did it, and it works. 
Take any wonderful restaurant. The chef knows what he wants to do, and does it. 
It doesn't mean you never iterate, never change, never learn, never grow! Of course you do, but you don't make a top restaurant by iteration and "release early."

posted on Monday, December 21, 2009 at 8:56 PM by Jason Cohen

Outside of the content of your post, there are quite good reasons for releasing *small* changes, often. I suspect that most of the people who advocate early and often also might mean the spirit behind 'continuous integration' software development cycles, or in the grander scheme: 'continuous deployment'  
To which I say: yes. Releasing small changes very often could be the best thing for keeping a growing and evolving site available in the midst of changes. Operationally, it's a boon. 
Ries is a smart guy, and has experience with both releasing early/often, and releasing small changes often. All of those things have helped Flickr in a number of ways. But hey, that's just Flickr. 

posted on Monday, December 21, 2009 at 9:23 PM by John Allspaw

Correct me if I am wrong but the release early thing is not what Steve Blank and Eric Ries are pushing in their Customer Development methodology. 
As an entrepreneur, you start with a vision and an educated guess about what customers might need. 
Through the process you refine that judgment, but not by letting customers lead your development strategy... instead, you will just throw away the features that they don't need from your own feature list and focus on what they really care. 
Never ask what features everybody wants, you will not fit with anyone. 
First go see your customers and try to define if there is a market for the product you had in vision. 
When you find your market, then fine tune your app and release it. 
The goal is not to collect features from everyone, but to listen carefully to your early adopters and transform them into evangelists. 

posted on Monday, December 21, 2009 at 9:44 PM by Yves (BeeBole)

I agree about the hype around "release early". But the apple example is out of context, they did not have to validate their product/features with customers, because they took the phone, which was around for umpteen years and the mp3 player which was also around for a while and put it together. I'm trying to say that there was enough mistakes to learn from available on the field. 
"Release Early" does matter when you are the first one around.

posted on Monday, December 21, 2009 at 10:17 PM by Girish

After a bad experience of waiting for the perfect product to release and losing the pioneer brand advantage, I am in the camp of "Release early Release often". Especially, in the technology startups, there is a winner takes all advantage. There can never be another YouTube or another NetFlix. If these startups had waited for a year or so to make their product perfect they would have lost it.  
Back in 2005 we had ability to click and post photos from mobile phone to our website with single click. We decided it was not good enough and we needed to add videos to make product compelling to users. We spent next one year to make this feature happen..In the meantime, others released their mobile apps with photo uploads only and they rapidly gained market share. We learnt from mistake and now we make sure we release as soon as we can. The product is marked Beta and early adopters understand that there can be bugs. They provide worthwhile feedback. Besides the confidence and motivation that it gives a startup team just knowing that there are consumers using your product is enormous. Through rapid iterations we were able to create an award winning product called Vaayoo SocialBox.  
Here is the bummer, the number of photos that are uploaded to our website outnumbers videos by 1:10. So our users would have told this to us, if we had gone to them early. Instead we just assumed that they would post more videos from their phone. 
Some of the other arguments are also not necessarily true: Faster product to market does not imply poor engineering design and architecture. In fact, if you have good technical team, they will design a good product / architecture right from the word go. A architecture and design which is scalable and extensible to ensure it is flexible to the changes. 
You never ask consumer "What you want?" They will always give you the wrong answer. A better way is to observe consumer behaviour and deduce the features. Intuit and other companies have mastered these techniques and they have always come up with best products (Turbo Tax , QuickBooks etc) with the help of their users. 

posted on Monday, December 21, 2009 at 10:36 PM by Ranjit Sawant

One of the problems with this debate is that the supporting evidence is all anecdotal. There are plenty of examples showing why release early is bad and plenty of examples showing why release early is good. 
The question we should be asking instead is when is release early appropriate and when is it not. And is there a way to define this objectively, outside of personal biases that are skewed by our own limited experiences. 
I'm wondering, is there a way to design an experiment to test entrepreneurial theories like this? Or are we forever stuck in a he-said, she-said argument? 

posted on Monday, December 21, 2009 at 11:10 PM by Trevor Lohrbeer

While I agree with the argument, I take this a bit forward and say that a mixture of efficient marketing and product features is a must to attract those "Initial and Invaluable" clients. This is what is done by companies like Apple. Also, keeping the software development in stealth mode does not make sense beyond a point 

posted on Tuesday, December 22, 2009 at 1:51 AM by L V N Muralidhar

I just want to comment one aspect of the post which says "don't depend upon customer feedback at all since they dont know what they want". 
I think it will be wrong to ignore the customer feedback / customer data or develop the product for long with zero customer interaction. The release early bit is great if used correctly, since it allows you to test your hypothesis. You can see how people are reacting to your product, what are they saying, collect some data. Once you have this info, do not believe it literally and start implementing every feature asked by customers. But take in this data, digest it, draw insights, combine the customer data with internal knowledge and vision. This will ensure your future decisions about features and direction of the product will be much better.

posted on Tuesday, December 22, 2009 at 3:18 AM by Sameer Guglani

Haven't we (software, usability research) already been here once before in the 1980s? It is/was called "rapid prototyping". It was feasible then because of tools such as Hypercard all the way to GUI toolkits. It was great for user experience / requirements elicitation. It was less great for data-centric decisions such as database choice, scalability, performance, etc. Once you started the momentum, you had to keep it going. This led to a dread amongst developers of prototypes and demos being shipped as product, with dubious marketing language to disguise the fact. Surprise, surprise, both sides had a point. No product = no visibility in market. No quality = no customer retention.

posted on Tuesday, December 22, 2009 at 3:40 AM by Paul Walsh

Good article.. All true.. Architecture should be perfect.

posted on Tuesday, December 22, 2009 at 5:08 AM by santosh

Coming form the games industry I can't really say that all these rules of thumb would fit there: 
Not fixing bugs? You would have a game that would crash and people would trash talk your product and leave for sure. 
Don't make pretty interface? Well, you'll most likely not hit the mass market with your product then... 
In a sense, it is all about innovation - and can users really help you there? I think not. Users do not know what they want before they see it. 
That is why the iPod was such a landmark innovation, because Apple didn't take the end user too lose into the concept development phase. This gave them the needed room to innovate. 
I agree that a software product shouldn't be overladed with features - less is sometimes more. 
Keeping production minded towards what the end user actually will use is good common sense - don't let production use 90% of their time on features only 10% will use.

posted on Tuesday, December 22, 2009 at 7:03 AM by JeppeKM

There are two sides to every story and arguments can be made for both here. In scanning the article and comments I see only one mention of the word revenue. To get paid for a product/service it needs to solve a problem for some a) large group willing to pay a little or b) a small group willing to pay a large fee. 
I think the best way to look at this problem is through the eyes of the buyer. At the intersection of Social Media Review and Release it Early lies a question or two; Are they willing to pay for something that is a moving target? Are they willing to play now and convert to pay later? 
What can we learn from Facebook and Twitter - They set an expectation of free and created a vocal following - right now they are both trying to figure out how they will generate enough revenue to satisfy the VC obligations.  
Even if you are self-funded, your product or service needs to do more than hope to generate revenue using a ad supported model so begin with the end in mind unless you have deep pockets.

posted on Tuesday, December 22, 2009 at 7:33 AM by Tobias Bray

@Trevor -- I agree completely, this is about "when" not "if," and I also agree that my examples are anecdotal and convenient, as are those for the other side. 
My point here wasn't to say "Take 12 months before release." Rather, the arguments I read ALL say "earlier earlier earlier" I felt that it should be more balanced than that.

posted on Tuesday, December 22, 2009 at 7:33 AM by Jason Cohen

@Sameer - The passage you quoted: "don't depend on customer feedback at all" IS NOT A QUOTE. Please don't put text in quotes which I didn't say! 
Here's an ACTUAL quote: 
"Of course it's necessary to gather as much feedback as possible from both customers and lost-sales!" 
As you can see, you pretended I said something I didn't say, then argued against it. 
My point is that I think people are emphasizing customer feedback to the exclusion of other important considerations.

posted on Tuesday, December 22, 2009 at 7:36 AM by Jason Cohen

Nice sense of perspective. I suspect that the best scenario is actually somewhere in the middle, where if you aren't about to shock the market with something totally awesome that you can tell your customers that they want exactly what you built, you will have to balance these issues. I think that for many developers this might be the hardest question they face in the early days of their business - how late is too late for the release?

posted on Tuesday, December 22, 2009 at 9:29 AM by Elie

Maybe I'm missing something, but this felt one-sided to the effect that it was a lot more "What Not to do" without a lot of what To Do instead.  
Perhaps a Part II is in order that would clarify the alternative approach to the lean startup method? 

posted on Tuesday, December 22, 2009 at 10:20 AM by Jason Evanish

Jason, in a previous article, you wrote about survivor bias and how it plagues all business advice. Same is happening here. 
I don't necessarily agree that Apple has been a release-later company "since its inception". I'm trying to recall where I read this, I think it was in Founders at Work, but Apple completely missed its market with the Apple I. Hardware is tougher to iterate quickly on than software, but they did iterate until they found their niche (computers for desktop publishing) and their flagship product (Macintosh).  
Likewise, I think Twitter is an example that argues against your point. Twitter did release early to see if their stupid simple (in a good way) idea would take hold. That they haven't iterated through features is not evidence that they weren't early. Their scalability problems are. If they had built the massive infrastructure to support their current load and nobody cared it would have been a huge waste. In retrospect, perhaps they could have foreseen the scalability issues and done something on the business side to prevent it. Maybe invite-only beta like GMail and Google Wave. 
I think the real lesson here is that 1.0 should not be a throw any old thing at the wall release. Instead, give some thought to what you believe are the critical features *and* your key differentiators. Spend your implementation time on those and skip the rest until you have some feedback. 
If you're revolutionizing portable music players, the critical features are portability and ability to play music. Your key differentiators may be a polished design and a music store. Other features, like replaceable battery, Bluetooth, AM/FM tuner, etc., skip them. 
If you're inventing microblogging, your critical features may be SMS integration (140 characters) and publish/subscribe. Differentiators are the network effects incurred by the first to market, biggest buzz. Do a product launch directly to early adopters at SXSW Interactive.

posted on Tuesday, December 22, 2009 at 10:25 AM by Brandon

Great post though I don't really agree. 
The reasons I have outlined here (to long to put in a comment)

posted on Tuesday, December 22, 2009 at 11:01 AM by Thomas Petersen

@Brandon, thanks that's a very good counter-argument, and I agree that I picked specific examples, that you have great examples, and that hardware is harder to iterate and therefore not the best analogy. 
I like your proposed compromise that you should pick exactly what your key differentiators are, defining "who you are" fundamentally, and then considering everything else to be optional and/or extraneous. 
However, there's still some hindsight going on in your argument too. For example, you say Twitter's scalability issues weren't a deal-breaker, but YOU know that NOW; if Twitter ended up not being able to keep up after all, you would have concluded that scaling should have been a primary concern from the start. 
That just points out that what's "vital" often cannot be known at the beginning. That's why I like your definition as "what makes us unique," because at least that's a good handle that we can all agree is vital.

posted on Tuesday, December 22, 2009 at 11:11 AM by Jason Cohen

and perhaps more importantly this post

posted on Tuesday, December 22, 2009 at 11:16 AM by Thomas Petersen

You're wrong about the 80/20 rule. It's the same 20% of features used by 80% of your users. Take Excel for example: pivot tables, database connectivity, and the like are probably used by less than 1% of users. Even formulas are outside the 20%. A spreadsheet that can resize cells, do basic formatting (eg. bold headings, borders), is good enough for most. And what's more, they don't even need it to be Excel compatible -- they just use Works. 
The iPod is another example. It's a horrible tool for anyone who wants to do more than push play on their favorite 15 (of 250 purchased) songs, and every one of the features you disparaged is wanted by everyone in the 20% minority. Most people just bought it because it's shiny and they think earbuds are fashionable. The remainder put up with it because Apple has a virtual monopoly on copyrighted digital music distribution. 
As for Steve Blank, his personal story about working for a defense contractor in the 1970s is interesting, though his historical conspiracies theories about radar are pretty far fetched.  
But Eric Ries -- who is he? I guess Steve Blank backed his failed chat program startup, but I don't know how he gets any credence. It's funny watching them talk, because neither one actually even understands mainstream concepts like "Agile" or even "Open Source". 
The one idea they have that makes sense and gets lost in the shuffle is that finding customers is job one, and all you need is some mockups and bullet points to do that. Once you have customers who will put it in writing that they will pay X for your slideshow, then you know you have a product. 
Where it gets confused is they then talk about early adopters, but the early adopters are the ones who will put up with the ugly buggy beta.  
They are not the buyers or the decision makers or the trendsetters. They are the scouts. You do need to appeal to the early adopters, but it's a crap shoot which early adopter is going to be connected to a trendsetter or whatever they call them in "The Tipping Point". 
So they have (at least) two contradictory strategies:  
One is iterative 'customer development' which is the end boils down to market research, no matter how many times they say it doesn't. It's a simple statement of common sense that needed reiterated. 
The other is "build it and they will come" -- which follows the newer meme of social growth. It's not a great strategy, but it does have value. Open source is proof of that, and frankly, one of the main reasons that people forgot about "the customer is always right" part. 
The real insight is that while "the customer is always right", also "the customer doesn't know what they want". So you have to guess, and then ask them. If they say yes (and mean it -- read: pay for it up front) then you have a product to build. Now build it iteratively, because they may have gotten a bit excited when they said "Yes, yes, yes!" but really meant "Yes, no, maybe, and also..." 

posted on Tuesday, December 22, 2009 at 11:25 AM by Aaron

I think it'd be more accurate to say entrepreneurs should start with their own strong intuitions about what customers need and want. Then validate those assumptions with customers as often as is feasible. I believe this article is making extremes for the sake of a good article. My understanding of the 'release early, release often' model is a bit more moderate.

posted on Tuesday, December 22, 2009 at 11:26 AM by Tony Jacobson

Jason - Thanks for this thought-provoking post. 
Truth is never absolute and always lives in both sides of the argument. There is an "i" in vision and it's the entrepreneur's job to bring that vision to fruition - alone. All the examples cited, Apple, twitter, etc. did this by building a minimal product that was true to an original vision around what eventually was a compelling enough unique value proposition that allowed these products to achieve product/market fit. Product/market fit is when your users don't care about a removable battery, or intermittent service. Things like scaling can almost always be deferred to after product/market fit. YouTube, Facebook, twitter, all managed to scale later which goes to Steve Blank's point that the biggest risk is usually market risk versus technology risk.  
In hindsight, arguments can be made on either side as to whether these companies released early or late as all successful products iterate from V1. The key for me is identifying a compelling problem I think people want solved. Then building a minimal solution around that value proposition that has to work. Releasing early cannot be a cop-out for poor execution. Deciding what goes into V1 is hard work and has to be done with a priority to maximize utilization of the most valuable resource - time. Customer Development essentially helps build this list through early prioritization not aggregation of features. Lean techniques help measure what's working as customer actions speak louder than words. Iterating from V1 is also an ongoing exercise in prioritization as not all customer pulls are created equal.

posted on Tuesday, December 22, 2009 at 11:28 AM by Ash Maurya

I love the opposite side of the story, well done for putting this forth and questioning the wave of consensus. I think in the early stages you must build the product you want, your vision, your way. once you have something workable you must then shift the focus to gathering feedback and testing with real users. The idea that things will change must be accepted and kind of baked into the plan. Most of this should be before you go off and raise tons of money. In the Product Development Cycle there is an assumption of loads of VC money in the bank before the product is built which seems weird unless your building some Oracle like monstrosity of a product. For the bootstrappy entrepreneurs with a bold vision, the goal should be build your vision in a v1 format and then go out in the world for feedback, taking a little from both sides (i.e. the middle ground) is far more effective then following the wisdom de jour.

posted on Tuesday, December 22, 2009 at 12:07 PM by Hasan Luongo

Why does every argument have to be extreme in either direction? It seems that people are looking for a set of tools to do their startups, and then they can just "lock and load" and see the company take off. It's not that simple. 
I work for a very large company here in the valley (you all use our products many times a day :) and I am a big proponent for launching early and iterating. It's not just startups that can benefit from that you see. However, it's not "build some random crap and throw it out to see if it sticks." (@Brandon nails that point!) The team building a product (for startups, it'd be the whole company) needs to be smart, persistent, come up with great ideas, iterate internally as much as possible, do a good design, etc, etc, while still aiming at getting a solid product to the users as quickly as possible. And then iterate as quickly as possible. It's hard work, and a lot of the decisions are made at game time, not in some pre-defined plan that's written solely based on some hard and fast advice. 
Whenever we try to boil things down to taglines (or cute signatures like I've all too often done myself) we over-simplify. There's no silver bullet, sorry.

posted on Wednesday, December 23, 2009 at 1:35 AM by Gummi

I think the important thing when considering such matters is to be very wary of absolutes. Which is precisely why the Agile Manifesto isn't a series of do's and don'ts - rather it's a series of contra-positive statements. 
So we could say that although there is value in fixing all known bugs prior to first release, there is potentially more value in releasing with some bugs and using the time to get feedback. 
If you consider the points on architecture, the very notion of agile software development embraces continuous design. At any given point in time, the code base has the simplest architecture to support the *current* functionality. 
If you keep yourself attuned to the presence of code smells, refactoring accordingly, your architecture will emerge organically.

posted on Wednesday, December 23, 2009 at 1:40 AM by Tim Haughton

Good article. Off course saying you launched a project "TOO early" always means it went wrong somewhere. 
Launching early however is not always a bad thing (like you also stated).  
I think it also depends highly on what market you are focussing on. 
In the gaming and software market everyone is used to beta-versions or versions loaded with bugs. They get "fixed" in the process...

posted on Wednesday, December 23, 2009 at 1:51 AM by Seth Rietdijk

@Seth Launching in beta and hoping bug fixing would solve everything more or less was the one big failure of FunCom's 'Age of Conan'. Look where it brought them today.

posted on Wednesday, December 23, 2009 at 2:45 AM by JeppeKM

If the answer was so simple, then "Execution is the key" would be invalid.  
All you would need is a great idea, then follow either pattern A, B or C and to build a great company.  
Right way to build good software and successful startup is complex and somewhere in between this debate.

posted on Wednesday, December 23, 2009 at 8:13 AM by Abhi

Apple has Steve Jobs you don't. 

posted on Thursday, December 24, 2009 at 3:27 AM by Vagmi Mudumbai

Measure twice cut once! Having a great invention is only half the battle. There is customer need, want and overall customer satisfaction. Not to mention how exactly is everyone going to find out about this invention and then commit to it. Giving a beta or early release is a great way to pull in the audience your targeting. Releasing only a few features to save money and still get the results you wanted sounds good to anyone, no matter what!

posted on Thursday, December 24, 2009 at 7:48 AM by Tino

Excellent and thought provoking article. However, in many cases Release Early, Release Often strategy is optimal. Decision factors for selecting strategy Release Early, Release Often:  
1. People. Are they highly talented and capable to come up with great ideas from the beginning ? Or should they learn and understand better the problem space, release incrementally and get more feedback from the users for initial assumptions? 
2. The Problem. Is the problem (software requirements and business domain) unclear, complex, challenging and require a lot of trials and feedback? Or is the problem space well known and team already have good experience with it and can release a great product from the first attempt? 
3. Context. Is the team under a pressure to release a product early, catch at the market opportunity or help a company to survive? Or do they have luxury to take a time for designing properly and release a polished product?

posted on Thursday, December 24, 2009 at 3:36 PM by Andriy

Not sure the IPod defends your argument. It was released with a minimum of features. You don't think someone felt at the start that it shouldn't have to be connected to your computer to get music? Video files were common, but not implemented early on. The first IPhone had none of the features required by businesses that were already common with the Blackberry. From the perspective of the other 90% of computer users who do not use an Apple computer, they are far from perfect.

posted on Friday, December 25, 2009 at 8:54 PM by Jeff

As someone who implements the Blank-Ries-Ellis (BRE) philosophy for startups, I frequently encounter thoughtful arguments laid out in your post. I believe most entrepreneurs, with limited funds (which may last a year or probably less), that BRE offers the highest probability of success. Since the post focuses more on the lean startup philosophy, let me try my best to channel Ries and respond to your critique.  
In order to tease out the causal effect of the lean startup helping or hurting a startup, let's imagine two companies, A and B, who have the same founding team, same capital, same execution speed, etc, but company A implements the lean startup philosophy and the other, B, doesn't. Who lasts longer and has a greater chance to be successful?  
This should have been the starting point for your analysis. Having company A as startup, barely beyond a slide deck, and company B being Apple, misconstrues what Ries (and Blank and Ellis for that matter) are trying to get across to founders of nascent startups. Ries is speaking to startups - meaning that we have a very small user base - made of passionate early adopters (or as Blank likes to call them visionary customers). This is the customer base that Ries' philosophy is addressing. The lean startup is not offering advice to mature companies like Apple (and probably not to companies that manufacture hardware). He is addressing web based startups.

posted on Sunday, December 27, 2009 at 1:28 PM by David K. Park

Disagree. The examples given are actually examples of the benefits of releasing early! When the ipod first came out it wasn't as good or as full featured as it is now... Apple did get some feedback after the ipod's first release and so they made a lot of changes to it. Think of Microsoft's Zune... they were very late to the game and the Zune is awesome... it is just a bit too late and most people are heavily invested with time and file formats, etc... using iPod and the iPhone as their media player. I still think that almost always, releasing early is BEST than taking more time to release something we think is complete... when it might be a product or service that our clients aren't all that interested about.

posted on Tuesday, December 29, 2009 at 12:43 PM by Ricardo

It depends.  
It depends on what the solution is, and what else that's similar is out there. There can't be a one size fits all philosophy here.

posted on Tuesday, December 29, 2009 at 4:47 PM by Samuel

I'm relieved to see some alternative thinking on this. We read all the books and blogs on this before we created our collaboration platform SambaJAM, telling us to put the most simple thing in place, release then iterate but we ended up not doing that for various reasons.  
The line of early/late should be drawn around what is the minimum feature set you need in order to sell your product. If you build features above and beyond that you've released late, if you release before that point, you've released early. 
I think what affected our decision as to when we put SambaJAM online was based on this. We launched early with a private Beta to get some usability feedback from users (as we're really focussing on rich AJAX interface to improve the usability of collaboration platforms so needed to test it with real users!). However what we didn't do was release a general product very early on and this was because of two things: 
- We're in the Enterprise space, unlike free apps, mainly consumer orientated, like Twitter, enterprise users aren't so forgiving about buggy software unless it is is something truely unique. If its not unique, you have to launch with a quality finished product that enterprise customers can confidentally trust is secure and won't lose their data! If not, you seriously risk losing your credibility before you've even got started! 
- We've been in this space for over 5 years so we had a pretty good idea of what user's needed based on our experiances working with massive organisations 
- We're in a crowded space, launching early would have got us little attention because there wasn't enough there to show our differentiating vision, even now there's several key features of our platform which will be coming out next year so I guess we're still "early", but right now we have the minimum our customers require to get started.  
At the end of the day, you if you're in the enterprise space you need to launch a good quality product with the minimum required feature set end users will buy so you can start pulling in cash. The release early only works on something so new no-one has seen it before, or consumer apps which people don't pay for so don't have as vested interest if the product is buggy. 
We're still in private beta, (you can sign up here for an invite: and from next year (2010) we will be moving to the fast, iterative model now that the core platform is stable enough for us to sell and ensure we're not losing people's data!

posted on Tuesday, December 29, 2009 at 5:02 PM by David Gildeh

Great discussion points. Regarding customer feedback, I echo your sentiments, but believe that this can be dramatically improved by asking better questions. Rather than asking what a customer would or would not like in a product, developers should inquire as to what customers would like to achieve that they are not able to with the current solution (the 'jobs to be done' argument - Christensen, Ulwick, etc.). 
Thanks for the thought provoking post, Jason.

posted on Wednesday, December 30, 2009 at 12:37 PM by ruben

Excellent post. As someone who’s launched north of 200 software products over the years, I agree with the premise and see several drawbacks in the release early approach. I also agree with many (but not all) of the other commenters, many of whom appear to be developers. But I’m surprised a few points were largely ignored or given only a passing mention.  
First is the risk (whether deserved or not) that the product will be seen not as late beta by the target users, but pre-alpha. Releasing software that’s viewed as either poor quality, incomplete, or lacking in obvious features or usability can be very damaging. That alone could eliminate all possible benefits of early release. Second, if the early release is limited only to a small group of beta testers, they may be more forgiving and provide excellent input but as a group their feedback will not reflect that of a broader, “non-early adopter” user set. Third is the UI question, which is often separate but equally important to functionality. Unless the product is extremely lightweight and barely has a UI, most users will have concrete expectations about how the UI should work. It’s quite possible to get the functionality right but the UI all wrong, which frustrates early users, who think in effect you’ve designed a car with the gas pedal on the roof, the ignition key in the glove box and the brake pedal in the trunk. Not everyone wants to “re-learn” how to drive. And if it causes a drag on uptake and sales, then why would you want to ask them to try? A fourth factor—one that has happened to me during software evals—is the impression it leaves if the product features change so frequently that changes occur in mid-eval cycle. The change may be an improvement, but the experience may be unsettling to some. A “stable” product cannot also be “a moving target.” 
The bottom line is giving your users the impression you’re asking them to QA a buggy, too-early, half-baked product is never good.  
I think the VC community has played a big role in popularizing “release early and often.” It’s just one more way to try to squeeze more results from less investment, and keep one foot on the brake and one on the gas. But it’s a false economy. There’s more real risk here than many acknowledge. If you’re a real start-up (not an Apple or other major player), then you risk killing the golden goose (or if you prefer, starving the race horse). Stillborn products hardly every get a second chance, and if you put out code that’s not ready for prime time, your reputation, and therefore your product, may never recover.

posted on Saturday, January 02, 2010 at 9:56 PM by Steve Parker

Regarding the 80/20 rule, I remember attending a Microsoft event where they explained the redesign of Office 2007 based on the huge amount of data they've been collecting throughout the years. They said exactly the same as you - that every person uses a different 20% of the feature set. 
It's the same regarding Windows. Data showed Microsoft that not even two installations in the world had the same programs installed - there's always a slight difference. 
As with the architecture/scalability problems: I've seen it with my own eyes. A startup gaining traction in the market. Something as critical as primary keys in our database were Guids/unique identifiers - which meant our index could not be stored in memory - which was very bad for performance. 
On the other hand - you gotta ship! And a lot of startups don't even get there because they want to be perfect. I guess you have to find a healthy balance.

posted on Sunday, January 03, 2010 at 2:05 PM by MartinHN

There is one aspect which has not been mentioned in the whole debate and which I feel is extremely important. Successful start-ups have to build a strong customer service mind-set. By releasing early you are going to get customer issues (more if the customer pays you) The critical thing sometimes is not the "issue" but how you handle it.  
Some months ago in my start-up we had a paid customer that complained because she could not get into one of our MasterClasses. In fact it was our fault given a glitch in the code. We gave her money back, provided the recording, and gave her a VIP Pass to a future class. She was so happy that she told a bunch of friends about us which became paid customers. She understood we were a start-up too. 
Even with the best products your start-up will have customer issues and its better to get the 'customer service' mindset right earlier that later......releasing early will help you to start thinking about & creating an award winning 'customer service' culture! If you handle things well you will build a relationship and trust within your customers.

posted on Tuesday, January 05, 2010 at 4:25 PM by Antonio Faillace

Having read ur blogs v hav come 2 realize the entrepreneur in u.thus we would be honoured 2 present the STARTUP CAMP of Global Entrepreneurship Summit organised by Ecell,IIT Kharagpur. 
We believe that dis info will help some of ur readers who r interested in wrkin wid start-up’s and entrepreneur freaks. 
Want to be a part of a path-breaking venture? Are you looking for an internship which would provide you with an enriching experience?  
Global Entrepreneurship Summit 2010 plays host to Startup Camp which would serve as a platform that connects the best startups of the country to students and VC’s. Startup Camp would witness participation of 10 of the best Startups in the country who would showcase their product/services to students and VCs.  
These startups would provide college students a unique opportunity to work with them as a full time employee or as an intern. In addition, the participating startups would get a chance to pitch their ideas to prominent VC’s of the country, thus giving an impetus to their venture.  
Distinguished VVc's attending the Global Entrepreneurship Summit 
Nexus capital 
Canaan partners 
Navam capital 
Epiphany ventures 
Morpheus ventures partners 
Indian angel networks 
Mumbai angels 
Other benefits will be finding appropriate partners and networking. It also serves as a platform of motivation and valuable learning for aspiring entrepreneurs 
For further details visit da website

posted on Friday, January 08, 2010 at 7:29 AM by prakhi

I think it's healthy for someone to play devil's advocate and question the 'dogma' of releasing early and often but most of the arguments brought by Jason as flawed at the basis. He's comparing software with a (hardware + software) product. He's comparing a free-to-use website with an expensive gadget.  
If I am spending $100-300 to buy something I expect it to work as advertised and if the experience sucks that will damage the reputation of the manufacturer. Apple couldn't possibly release a crappy ipod get some feedback and release a better one for free to those who had given it feedback. The 'release early and often' argument refers primarily to (usually free) sofware products that can be updated in due course (usually for free) e.g. a new travel booking website but, mostly, cannot be applied to expensive products.

posted on Saturday, January 09, 2010 at 5:45 AM by AndreaF

Additional features may also constitute one of 4 P's in marketing. 
Take yext ( It solves a problem of classification between two: junk and not-junk calls (it will charge for). However, they have also developed a large set of features, beautiful UI and are testing the idea/technology for extracting the actions items from call.  
Bare bone solution is not as attractive as it usually is packaged and sold with uncertainty of stated benefits.

posted on Saturday, January 09, 2010 at 6:42 AM by Maksim

Comments have been closed for this article.