Ask HN: Why should you ship fast? | Hacker News Reader

Ask HN: Why should you ship fast?

9 pointsshail15 comments

Is it really that necessary. Does it ever makes sense to develop something in its entirety (some level which kind of makes it feel like a complete product and not a in-haste release).

Thoughts? Did you ever do otherwise and were successful?

View on HN

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.

Without reading this first, I wrote almost the exact same thing, just worded differently. Needless to say that I completely agree :)

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.

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.

I am really interested in understanding the WHY part of being stuck. Why does it happen? Is it because a person is perfectionist. Or is it because of fear of failure. Or a combination of both?

Few of my own reasons/excuses:

- Fear of rejection. What if no one likes it ?

- Fear of being mediocre. What if it really is not what I wanted it to be ? Damn I hate to be mediocre.

- Distractions and not enough focus. I should have coded up that module last week but I am too distracted to do so. Every day I think of coming home from work and compiling that piece of code. oops I rather start playing with my kid or watch TV

- You know what. I have this stuff ready but I want to enhance the design further. Damn I don't like that CSS. Ok will finish this tomorrow (which never comes)

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.

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.

"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.

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 agree to this absolutely.

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.

What if you are building for which the market already exists. You are just being another option in the market. Then I kind of feel that ship fast's meaning changes a little bit. Because now you know you will be compared with the earlier service as soon as you launch.

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.

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

Relevant book: http://executebook.com/

Reply on news.ycombinator.com