What should be built is a question all software development companies struggle with. If you don’t launch enough of a feature set, user adoption will suffer.

Laura Klein makes a compelling argument that launching a limited product that solves a user need and then improving on it is a better than launching a product that’s packed not only with features but bugs and usability issues.

Great post:

A limited product is something that may not do much, but what it does, it does well. It makes it clear to the user what it does and what they should do. It solves a serious problem, or perhaps a small part of a serious problem. It doesn't crash relentlessly. It doesn't have enormous usability problems.

…

But a limited product probably doesn't do anything else. It doesn't have bells and whistles. It doesn't have "nice to have" features. It may only support the problems of a small subset of the market. It may only be released to beta users.

…

A shitty product, on the other hand, often tries to do too many things at once, and it doesn't do any of those things particularly well.

You really don't want a shitty product because, when people don't use it, you have no idea if they aren't using it because you have a bad idea or the wrong market, or if it's just because your users are confused and turned off by your shitty product.

Shipping a shitty product is one of the best ways to get a false negative on your idea. People will use products that aren't "polished." They will abandon products that are just bad.

…

So, when I'm yelling at you to Fucking Ship It Already, I don't mean that you should ship something bad. I mean that you should ship something limited – something that is small enough to be shippable and usable in a very short amount of time.

And then I mean that you should immediately improve it and ship it again.  Do this over and over again as many times as you can for as long as you can.