

Ask HN:  When to release?  - Everest

I've been toiling with this question this morning and curious to hear the thoughts of HN.  This isn't a purely academic exercise as I'm planning on launching a startup in the next couple months and this is an issue I have to grapple with. Rather than speaking in generalities I'll layout an example.  Say you are Pandora and you are building the first music recommendation engine or you are Farecast and building the first prediction model for airline tickets. These companies spent years developing their predictive technologies and they are assuredly extremely comprehensive and robust.  However, say they gave themselves a 2 month deadline and released a service which they strove to improve over time.  Their service was not nearly as prescient as it could be if they took 3-4 years to develop it. Still, there was some data analysis that went into the service and Pandora and Farecast could advertise that fact on the website and indicate that the results will get better over time.<p>How many users would these services have lost?  Some users will be dissatisfied with the services so they would lose potential customers. Also, another competitor could see that they could do better and launch their own service, diluting the market share for these comapnies. But these companies sacrificed revenue by not releasing their service until it was very strong. Also, there are other companies that took years of work and flopped miserably upon release. Farecast and Pandora faced the risk of joining that unenviable pool.<p>It's hard to argue that Farecast and Pandora went down the wrong path since they were super-successful startups. But if I'm not mistaken, both started in academia so they have a higher standard to live up to in terms of rigor. Most startups are under the pressure to launch something quickly.  If you were running a similar company, when would you launch?
======
bjclark
I think you should launch as soon as your service provides enough value to
someone that they should care. If no one cares, it doesn't provide enough
value (for whatever reason). If people do care, then you know your on to
something.

If you launch before you provide enough value, no one will care.

If you wait to launch, you are only doing yourself a disservice by delaying or
prolonging the feedback cycle. You should be doing the opposite, figuring out
how to make your feedback cycle as short as possible.

Worrying about competitors at this stage is dumb. You could only be so lucky
as to have an idea good enough that someone would care enough to try to
challenge you for it.

~~~
pg
_I think you should launch as soon as your service provides enough value to
someone that they should care._

Yes. In general, you should release at the point when there is at least some
set of users, however small, whose lives will be improved enough by whatever
you've built that they'll start using it.

------
dsil
One of the advantages you have as a start-up vs. larger corporations is that
you CAN launch something before it's "ready". Getting feedback quickly and
early is essential to evolving your product.

It's common knowledge that the earlier a bug is found the cheaper it is to
fix. Same goes for problems in UI design, etc.

------
rg
One thing to consider is to what extent the user will be depending upon the
quality and comprehensiveness of your specific product. A product used for
recreation or convenience may be very partial and/or may fail frequently
without causing much disappointment, and users may be happy to have it early.
In contrast, my startup made a product that many users considered vital to
their professional and business success, that required substantial initial
investment of effort, and that users often used under considerable time
pressure. Anyone starting to use the product who became wedged by incomplete
features would be extremely unhappy. For this product, it was necessary to get
it over a fairly high threshold before offering it (apart from a demo or alpha
with no expectation that it could be depended upon). Most products aren't in
this category, and profit from early release. But even so, for your specific
example, I tried Pandora on its release day and was disappointed, and wrote to
Tim Westergren to tell him so; he answered within minutes promising future
improvements, which should have been impressive enough, but it took me two or
three years before I tried Pandora again (I'm now an enthusiastic paying
subscriber).

------
aditya
That depends on what you're trying to build. For most startups, getting early
users (not a full launch but a limited alpha/beta) is key in developing a good
product.

Sure, given more time you could just keep perfecting the product to your
standards, but if you don't have a good idea of EXACTLY what you're building,
why not do a limited release and work with the feedback that these alpha users
give you to improve your product as opposed to waiting for a really long while
before you release something that you (not the market) thinks is perfect in
every respect, that sounds like a really good way of failing.

Yes, you're going to lose some people who will hate the product and find it
useless, maybe they're not your target market. Maybe they are, if they are,
listen to the feedback that they give you and hopefully retain them. If not,
well, you don't care about them anyway.

3-4 year long dev cycles are generally not a good idea, since user driven
development is key in making good products.

You can do it if you're Apple and you have the in-house expertise and market
research to know EXACTLY what your users want, but if you're a scrappy
startup, you have nothing to lose by launching early, and often and failing
fast.

~~~
anigbrowl
Indeed. 25 people who'll give you a page of detailed feedback once a week
could save you months of frustration and wrong turns. If your site depends on
a networking effect of some kind, you might be able to recruit Alpha testers
who'll agree to roleplay all being interested in the same topic.

------
lunaru
There's no rule of thumb when it comes to launching. Everyone recites the
rhetoric of release early and iterate often, but that can lead to releasing a
premature product.

Your product only has one reputation, so more important than "when" is "how".
You'll want to make sure you have at least a differentiating feature, a
marketing plan in place, and a good initial spike of users to even begin to
draw worthwhile feedback. Having small sample sizes just leads to noise, which
can then lead to even more indecision than you began with.

The best way to think of a launch is not as a switch you flip, but as a reveal
that you build up to. The balsamiq guy had a great blog post about prepping
for launch: [http://www.balsamiq.com/blog/2008/04/18/preparing-for-
launch...](http://www.balsamiq.com/blog/2008/04/18/preparing-for-launch/)

It's as close to a video game walkthrough as you'll find.

~~~
dsil
Here's how I prepare for a launch:

1) log on to server 2) svn up 3) go to apache directory 4) bin/restart

~~~
jganetsk
Same for me, except change step 2 to "git pull" and 5) sound the alarm

------
chaosmachine
Is your product good enough to blog/tweet/tell friends about? If so, you're
probably ready to launch. If you think it'd get bad reviews, keep working.

------
uptown
Depends on whether what you're building is free or costs money. Each results
in different expectations on what you provide at launch.

------
jmonegro
Common creed I've read around the startup world seems to be "release early,
upgrade often", but I've always thought you must have a strong (note: strong
doesn't mean many) set of features before launch.

------
smokey_the_bear
I think it depends a lot on what your service is. I'm working on a startup for
hikers (trailbehind.com) and we were live from day one. But most of our
traffic comes from searches, and we've gotten more and more traffic from
searches as we've gotten better and more popular. We've also had some hard
core outdoors fans find us and send us great suggestions and even data. But if
we were a service like Pandora, that model wouldn't have worked, since people
would have had to remember to come back after a bad experience.

------
keefe
One important factor to consider is scalability. A lot of people like to
launch with a relatively immature server that only supports a relatively small
# of people in a beta with the idea that they will expand it after that # of
people come in. I think this adds an extra risk of someone absorbing your
ideas and it's better to get a nice, horizontally scalable server. You don't
want to break on slashdot or techcrunch and then have the site go down under
load.

------
dejan
I am always for launching as soon as your thing is operational. Real users and
critics need to shape your startup and technology, and nothing can replace
that.

------
richcollins
I like the minimum viable product approach:

<http://venturehacks.com/articles/minimum-viable-product>

