Knowing when to launch a new product is tough. Is it ready? Does it work? Will they buy it? You must find the right point where the product is good-enough. If it’s too good, you’ve lost timely revenue because you could have launched it earlier.
What is good-enough depends on your customer. In the web world, the customer is pretty forgiving. (Com’on Gmail is still in Beta; Twitter is up only slightly more than down; EC2 and other SaaS are at 2 or 3 9′s.) And, it’s better to get it out there to get feedback in the wild-wild-web. You can throw something out there that works, isn’t scalable and consider it beta. (Not sure why people have created this notion of Private Beta – Beta should have an invite / approval only process, which means it’s inherently private). Seems easy.
Now, enter the less-forgiving world of enterprise software. Granted, if you have a stable of devoted customers who love your products the bar of good-enough is lower (Think Microsoft’s Technology Adoption Program – TAP). But, in the ‘new product’ or ‘young company’ world, good-enough is more difficult to assess. Finding companies or people to test your product in a Beta phase is more difficult. You have no track record. Thus, you want to make certain your product is to a level where it’s not too burdensome to the beta tester.
But, most of the time people release a product after it is better than good-enough; but, that’s much easier to assess in hindsight than looking out at the market. Remember: You have about 5-6 months after launching a new product before you see real sales traction; especially if you’re a young company. So, if you screw up the GA release, you can always issue a patch a month or two after the release to clean-up any rush-to-market problems. Also, the following assumes that you’re satisfied with the requirements that actually made it into the release plan.
Here is a list of decision criteria that I use to assess the good-enough factor of when to GA a product:
Installs :: Unless you have a stable of professional service people at your calling, then you need to install a product that the typical competent, relationship-savvy sales engineer is capable of installing. Sure, if the product is brand new, you have engineering and QA to help out. But, if not, it’s typically a good idea to make sure that the product installs without too much heavy lifting.
No Blockers :: You must assess whether or not certain features work. If they don’t work, you probably don’t want to ship the product. If they work pretty well, and seem to be becoming less buggy as you approach your ship date they’re good to go. But, deciding what is a blocker is an important discussion with your engineering, QA and support teams as we PM. Everyone has a different perspective on what’s a blocker and there’s always some grey area on what’s a critical bug and a blocker. But, at the end of the day if you think your prospects or customers will have a serious problem as a result of the bug – it’s a blocker!
Elicits Feature Requests :: You want a product that installs, is usable and elicits feature requests. If during your beta cycle you don’t seem to be at this tipping point, then you should probably hold on to until it is better. But, if the product is eliciting feedback and feature requests, then you’re likely to be at a release ship point.
Bug Fixes Beating Bug Filings :: Product releases reach a turning point where the number of bugs filled per day is beaten by the number of bugs fixed. This is an early indicator that the product is starting to reach a release point. However, one must watch the aggregate number of bug filings to fixes to ensure that the product has reached a quality point to release.
Does No Evil :: Make sure that your product does no evil. The more intrusive the product the more careful you have to be. For example, if your product requires super-admin privileges to function then it better be very well tested. And, more importantly, if your product changes something, then it better be rock solid and not do anything that will create work or headaches for your customer. Understanding the ‘change’ and ‘impact’ factor of your product is key. You typically only get one shot with post-beta customer, so you want to ensure that you get a good Beta group to mitigate post-GA hiccups.