True, according to the waterfall model. But I've become more a fan of betaing early and betaing often, myself; having worked both ways, I find that the more complete my app is when I first release a beta, the less flexible I am to make changes and the less useful the app is to my users. On the other hand, if we release a beta that's just complete enough to basically work and to give the users a sense of what's possible, we get invaluable feedback that shapes the direction of the app from that point on, which makes the app more useful for everybody. Also, if users find performance issues that we've missed, they tend to be easier to fix early on.
A good example of what not to do is the first application I released, Cue Tracker. I solicited the advice of some really savvy potential users whom I knew well, started developing, kept going until I thought it was ready for prime time, then released a beta. Only then did people start realizing what other really useful features might be possible. I was mostly able to add them, but a lot of them feel inorganic and tacked-on. The app works, and (I think) it works well, but my challenge in v2 is now to try and make it all feel more coherent and, frankly, less like a Windows app. :) As for attrition: Yes, it's inevitable. But if you have a really cool product that excites people, they'll stick around. If your beta testers start dropping like flies, you may need to rethink your app. Which is also useful feedback, and a lot easier to act on early in the process. Sean --- In [email protected], Todd Blanchard <tblanch...@...> wrote: > > Beta implies "feature complete" >
