3 ms·
We released one of our products as a public beta in June last year, because we felt it would be useful to people, but not quite good enough yet – by our own sta
by dirkstoop 17y ago
We released one of our products as a public beta in June last year, because we felt it would be useful to people, but not quite good enough yet – by our own standards – to charge people for.
This worked out great, within a very short timespan we had thousands of beta users, who apparently agreed with us that our product was useful. With all the email we received from these people we were able to assess what kind of features people wanted added to our product (and which bugs really needed to be fixed right away) to be 'good enough' in their opinions. We mixed in the feedback with the improvements we had in mind already to release 8 more betas to incrementally get the product to a 'good enough' sweet spot that was being redefined/refined with every release.
Finally, we released a 1.0 (for pay) version of the product 5 monhts later.
Our application now has a large, very loyal and mostly happy group of customers and it won an Apple Design Award last month. I'd say our ideas about how we took it from beta to 1.0 worked out pretty well.
So, I'll echo what others have said here: Make something useful, release that, then work your ass off to turn it from something that's just useful (which is already a hard criterion to achieve) into something great.
If you just need 'testing': Hire someone to be a tester, or employ some friends to play with a private beta and give you feedback. We did this too before taking the beta public, and thereby prevented a lot of annoyances for our users and a ton of nearly identical emails in our support inbox for issues we really ahould've fixed before we released.
Even with this precaution in place, we still received multiple hundreds of emails a day just after the public beta release about other issues that we could have fixed before shipping but didn't yet know about. Releasing prematurely can not only turn away your earliest users, but it can also overwhelm you with a support burden you don't want to deal with when what you really should be doing is continuing development towards a solid 1.0.