Ask HN: Why should you ship fast?

More than shipping fast, it is about getting something out there. I have been stuck with a project which I should have frikin shipped a year ago. I am still thinking about customer development instead of putting something out there and getting the customer to validate :(. Need a kick in the butt desparately. So yes, I say ship fast and ship now if you can.

"Ship fast" and "Develop something to a level which makes it feel like a complete product" aren't necessarily opposed. Agile and lean methods, in general, tend to be about focussing on the smallest units of work that will deliver complete units of value and getting them out delivering value quickly -- so, ideally, you have something that feels like a complete product whenever its released, just initially a complete product with a very narrow scope.

I think shipping fast is useful if you want to get an early feedback from users. With feedback you'd be working on something somebody wants instead of losing your time (and money) on product you think everyone would need.

I believe it's very necessary both in startups and enterprise. Here's why - it helps you get to the core of what people need. It helps you iterate instead of building 30 features no one uses. I think it also makes you focus on what's important.

A bit of anecdotal evidence for you:

I've tried a whole bunch of web based side products in my years as dev, most I never even launched, and the ones that I did launch flopped.

Then after reading about shipping fast and MVPs on HN, I built BugMuncher as an MVP in a couple of weeks worth of evenings and weekends, and it is my first (and only) success! It's grown organically, and I've built it up from a really bare bones MVP to a full featured web app.

Because you lose excitement and creative energy the longer you wait.

Relevant book: http://executebook.com/

It really depends on the domain:

Among consumer facing web-technologies, there's definitely a compelling argument in favor of shipping fast. Shipping fast lets you iterate quickly based on lots of small pieces of feedback. This is a really effective way to build something that fits your users' needs.

In other domains, however, it may make a lot less sense to ship things rapidly. For example, in science and medical domains, it becomes important to validate carefully everything that you are shipping before you ship, because your audience has no tolerance for rough edges. Those audiences tend to be less willing to adopt half-baked/non-turnkey products as well, so first impressions count more.

I think you should think hard about who your audience is and how they will perceive your product before trying to ship things aggressively or patiently.

The motivation to ship early and often is to obtain feedback on the product. Of course, such feedback is extremely valuable, but it can also come at a cost. IMO, whether or not it is a good idea to ship early and often depends on the "cost" of obtaining feedback.

For example, say you are developing a web-app for a sizable customer base and it is easy to release intermediate releases and put it in front of a small fraction of your potential customer base and obtain instant feedback. In this scenario, your "cost" of obtaining feedback is negligible and I think it makes all kinds of sense to ship early and often.

However, consider another scenario (one that I am more familiar with). You are developing software for a medical device, perhaps in a surgical setting. Your chances to test this software with actual customers (e.g. surgeons operating on live patients) are extremely limited and costly to obtain. Not only that, but surgeons (and doctors in general) have a low tolerance for time wasting and may very well lose confidence in a product that is not thoroughly tested. The confidence of your early-adopter surgeons, often key opinion leaders (KOLs), in your target market is something you cannot afford to lose. In this scenario, cost of obtaining feedback is staggering and shipping early and often, to real-world customers, is almost impossible and wholly unadvisable. I still recommend you iterate and test often in this scenario, but it must happen internally.

In my experience, shipping fast wasn't the determining factor. It's always been to build tangible features for feedback purposes, and to focus development efforts on the core of what provides the value. Shipping fast is a side effect of maintaining this type of focus.

I think it's a good idea to ship fast for the sake of getting early feedback. However, you don't have ship to everyone. You can ship early to a small group of users, then when you've improved the product over a number of iterations you can release to everyone.

So I'd say, ship quickly and regularly to a sub-set of users that have shown interest in your product who will hopefully be keen to provide feedback. Then ship to the public once you have made any required improvements.