Illogical question. The entire point of "good enough" is that it is excellent.

Each iteration of the project has to be good enough. All you need to be excellent is enough iterations.

Perhaps a better question would be, "Which do you favor, many 'good enough' iterations or one shot at perfection?" The answer to this question is obviously the former because the latter almost never gets done.

There are a lot of similar questions that are interesting.

For example, let's say that all product development activity falls in to one of three categories: "concept", where you're collecting ideas and talking to customers, "prototype", where you do your heavy lifting, and "polish", where you refine your product's performance/UI.

You aren't going to be able to control the amount of "prototype" you have to do to achieve a given product state. But you can control how much "concept" and "polish" you'll throw in with it. If you estimate that it will take you two months working alone to produce a prototype that will interest customers, what is the right amount of time to talk to customers before you write your first line of code? I'd say a few days--in my view, startups should do this early on, instead of jumping in right away.

As for the "ideas" part of "concept"--I've been surprised how easy it is for me to turn on ideas like a tap. The insight that made me completely rethink what I'm working on now came to me late at night when I had forced myself off the computer because I wanted to start getting to bed earlier. But even if you can't turn on ideas like a tap, how much time should you spend recording the ideas that do come up and doing research on the internet? My guess--quite a bit, but it'd be even better if you could outsource this work to a nontechnical cofounder. (Too bad I haven't been able to find anyone who meets my standards for this and wants to work with me on the product I'm building.)

The amount of "polish" you should do before serious PR efforts is extremely situation-dependent.

- If you're entering an established market with a bunch of small innovations over your competition (Quora), you should do a lot of polish so your product will genuinely be the best thing out there (and they did).

- If you're doing something totally new, a moderate amount of polish is probably better--just enough to avoid acquiring a bad reputation.

- If your customers are going to be spending significant cash with you, polish is key so you seem (and actually are) trustworthy.

"The answer to this question is obviously the former because the latter almost never gets done."

If you know you're likely to irrationally give up on a product idea because your morale is low or irrationally continue with a product idea regardless of whether customers say it'll be useless, obviously those are factors to take in to account.

Personally, I wouldn't be afraid to, say, spend a long time building a better version of Ebay without doing any releases if I was convinced that people would switch to my site if and only if it was a significant improvement. If my intuition changed partway through the development process (without any solid external evidence or new observations--just a change in my gut feeling) then I would say "well, my intuition now isn't much better informed than my intuition at the beginning of the project--they're equally valid intuitions" and operate as if the average of my two intuitions were true (say, wrap up what I've got so far and make a solid effort at releasing it. Or start working half time and spend the other half of my time plowing onward with my project.)

A is the route Google takes (e.g. there have been 6 updates to Android since Feb 2009, with a 7th due out in a few months, but still not matching the polish of iPhone OS).

Apple does B (e.g. one major update to iOS each year, even if it means trailing the industry with features like copy/paste, multitasking, video chat until they can do them the pretty "Apple way").

Microsoft these days seems to have found a choice C, which is longer and longer iterations and settling for good enough or worse. Just look at the following release dates for Windows Mobile and you can see longer intervals for smaller improvements:

  5.0 5/2005
  6.0 2/2007
  6.1 4/2008
  6.5 5/2009
  6.5.3 2/2010

I personally would rather work for Google, so my answer is A. Rapid iteration gives you the satisfaction of seeing something you worked on "go live" vs seeing it die on the operating table after years of work and knowing you'll likely see Halley's comet before another project goes live.

It's amazing that the tech industry's three giants all do things totally differently and all make tons of cash.

It's likewise fascinating how different devices handle simple tasks in vastly different ways. Just look at GPS navigation systems for cars.

I favor the company that chooses the option that is right for the circumstance and for their customers (internal or external), not the one that chooses A or B dogmatically.

Obviously, the right choice depends on the situation. Companies should tend towards B if they already understand the needs of their customers or if they're in a slow-moving market where customers make big, infrequent purchases.

Probably it would be more useful if you described a few specific companies that you think release products too frequently. Then we could argue if they would benefit by releasing less frequently.

Keep in mind that the question of how companies should act to profit-maximize is totally separate from the question of what sort of company you want to work for. I'm only interested in the first one; you might not be interested in it at all.

The way you phrase your question is somewhat prejudicial. No one wants to claim that they'll "settle." However, everyone has some threshold of "good enough" for release. Even your option B alludes to that; if you're iterating, it means that there's something that can be improved after release.

The real question is at what point will releasing produce the most value for you and your customers. For some circumstances, that point might be very early with very little polish. In others, it doesn't make sense to release publicly until you've ironed most of the kinks out.

I doubt that there is any one answer to a question like this.

What field are you talking about? If it is a performance critical application like code for hospitals or intelligent life support systems/medical devices then certainly one would go for B.

On the other hand if you're designing a UI then there is no one way to do it. It's true that Apple releases only one update in a long time but they make hundreds of prototypes and test them out like anything (see: http://developer.apple.com/mac/library/documentation/UserExp...). So they do a clever combination of A+B, while maintaining their image.

However, if you're small then you can't afford to hire professional testers to test everything, or do videotaped randomized trials with volunteers who have signed a NDA. So, then a release often and correct often strategy would work well for you.

The question should be; How should I decide which one is better for me? A, B or A+B in some permutation?

[note: I am assuming that B in its pure form means micro-managed code that is proactively developed to be perfect from the start based on some previous parameters.]

Excellence in one thing. Good enough in everything else.

This is also known as t-shaped competence and is common in firms like IDEO.

It is more of a continuum than an A or B question, and it would be a bad idea to get religious over the question. From a pragmatic perspective, B should be favored when either production constraints (capital investment, etc) or distribution costs are tangible at the margin. So durable goods and long-term services (e.g. insurance) should lean toward B. A is favored if and only if iterative cycles can be accomplished without additional capital investment and distribution costs are near-zero. So, basically anything that could be delivered digitally that is not embedded in a durable good should be released when "good enough" (and then only improved if the iteration creates more value than the development of a new good or provision of a new service--iteration as rent-seeking is wealth-destructive).

When programming life support software for spacecrafts, A and B converge. Nothing less than excellent is good enough. I know there are other industies like this too, where 'release early and often' can result in death or some other disaster.

It depends. You cannot have a "good enough" with rapid iterations approach for a mission critical project. e.g. A software to control chemotherapy or a missile controller program

However for consumer facing products or in some cases for enterprise products, you can start with a minimal working version and then improvise.

Personally, i prefer A because the real feedback comes in from your consumers and you will find lot of your assumptions going wrong

Good enough is never good enough. It leaves lots of room for mistakes and at that point "good enough" becomes "oops." Not worth the rapid iteration if there is room for it to come crashing down...

A. Because existing good enough is better than non-existent excellence. And it can be polished forever.

I don't know who would prefer good enough, but the realities of the market and life in general forces you into it.

Even companies which we associate with excellence end up shipping less than ideal products with crucial things MIA, e.g. copy+paste, multitasking.

But in the end those things didn't matter so much, did they.

How do you know what is important enough to make excellent without trying lots of good enoughs?

B

Do your best to draw it straight. Slanted it will come out anyway. -- Mr. Someone, 2010

C) it depends. each is the smarter choice in different situations.