Ask HN: When to release?
17 comments
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.
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.
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.
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.
> How many users would these services have lost?
It's a myth that users who don't like your product in its alpha state won't like it later.
BUT: Make sure you signpost the site: this is beta software. Participate in our trials, help us improve it. That's really important.
Even if early users get annoyed because it's beta, they know you now. These are people squarely in the middle of your target market: they found you before you even released. ==> They want your product.
If you improve the software over the next 6-8 months and release a quality product, you will pop up on those same customers' radar screen, they'll want to see if you've made any progress.
It's commonly known in advertising that the quality of an ad affects purchasing decisions less than the frequency of an ad. It takes several exposures to a name, idea or product for someone to feel they know/understand it. Therefore, the more the better.
The poster below is an excellent example of this. He didn't like Pandora when he first tried it - now he's a paying member. With repeated exposure come clients.
It's a myth that users who don't like your product in its alpha state won't like it later.
BUT: Make sure you signpost the site: this is beta software. Participate in our trials, help us improve it. That's really important.
Even if early users get annoyed because it's beta, they know you now. These are people squarely in the middle of your target market: they found you before you even released. ==> They want your product.
If you improve the software over the next 6-8 months and release a quality product, you will pop up on those same customers' radar screen, they'll want to see if you've made any progress.
It's commonly known in advertising that the quality of an ad affects purchasing decisions less than the frequency of an ad. It takes several exposures to a name, idea or product for someone to feel they know/understand it. Therefore, the more the better.
The poster below is an excellent example of this. He didn't like Pandora when he first tried it - now he's a paying member. With repeated exposure come clients.
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.
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.
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).
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.
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.
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.
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...
It's as close to a video game walkthrough as you'll find.
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...
It's as close to a video game walkthrough as you'll find.
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.
Depends on whether what you're building is free or costs money. Each results in different expectations on what you provide at launch.
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.
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.
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.
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.
I like the minimum viable product approach:
http://venturehacks.com/articles/minimum-viable-product
http://venturehacks.com/articles/minimum-viable-product
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.
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?