I've heard this called the "Netscape Effect" after NS4, which was so bug-riddled and bloated that people left for Internet Explorer in droves... it makes sense.
But some of those problems sound like they could be ameliorated by minimising features and making sure that the few features that you do implement are tested as thoroughly as possible. If someone looks at your software and it doesn't do what they want, they might come back, especially if they hear that you've added stuff. If they look at your software and it tries to do what they want then crashes, it's less likely. Similarly, if you lack features then more of the support requests you have to deal with will be "I want this!" rather than "I tried to do this and it didn't work" -- so you can send back a quick "thanks for the feedback" form email and then direct development to add the features people are asking for. And, of course, if your product does what it says on the tin (and just doesn't say it does very much) then #6 won't apply.
So agreed that "your gut" is a great input on the go-live date, but another good one is:
- Have I used it enough to be sure that I know about most of the bugs?
- Have I fixed all of the ones that matter (for a fairly pernickety value of "matter")?
(Of course, the line between a "bug" and a "feature that I really want" can be a fine one, especially in some industries and for certain users. But I don't think that's avoidable -- when you launch you are guaranteed to not have every feature that every user wants.)
But some of those problems sound like they could be ameliorated by minimising features and making sure that the few features that you do implement are tested as thoroughly as possible. If someone looks at your software and it doesn't do what they want, they might come back, especially if they hear that you've added stuff. If they look at your software and it tries to do what they want then crashes, it's less likely. Similarly, if you lack features then more of the support requests you have to deal with will be "I want this!" rather than "I tried to do this and it didn't work" -- so you can send back a quick "thanks for the feedback" form email and then direct development to add the features people are asking for. And, of course, if your product does what it says on the tin (and just doesn't say it does very much) then #6 won't apply.
So agreed that "your gut" is a great input on the go-live date, but another good one is:
- Have I used it enough to be sure that I know about most of the bugs? - Have I fixed all of the ones that matter (for a fairly pernickety value of "matter")?
(Of course, the line between a "bug" and a "feature that I really want" can be a fine one, especially in some industries and for certain users. But I don't think that's avoidable -- when you launch you are guaranteed to not have every feature that every user wants.)