When to Release a Software Product

This is a question that product managers and executives always grapple with. When is a new product ready and how do you know? I am a strong believer in "release early and release often" and this is particularly true for web-based products. No matter how much you think you know your customer and your target market, you never completely know them. As a result, you can't truly understand the priority of the features that need to be added to the product.

I am not talking about stability - never, ever, release a product that isn't stable.

I'm talking about the minimal feature set. Take a good guess at the minimal feature set, but don't get too caught up in what you think it is. Get the product in the customer's hands and let them tell you about the minimal feature set.

Case Study

I was VP of marketing for a software company that was almost ready to release a new product. The product, however, was incomplete and we knew it. We had done focus groups and extensive user testing on the product and we had concluded that it was missing several key features. We had several executive meetings and meetings with our advisors about whether to release the product. We had one advisor (who was a wonderful VP of Engineering for another company) who was adamant that we shouldn't release the product without the three key features. So we listed the trade-offs that we would be making by releasing or not releasing the product.

Reasons to Release

  • The product was stable

  • The product was due to be announced at an Internet World - if we missed the release date we would miss the show

  • The product had been shown to many of our customers and was in demand

  • We had very real revenue pressures for the product

  • The product was brand new with no existing competition - we could be a "first" in the category

Reasons not to Release

  • The product was lacking some major features

  • We didn't want to upset our customers by providing them with an incomplete product

  • It wasn't clear we could sell the product without several key features

  • It was potentially disastrous to have the press review an incomplete product

There were lots of internal battles, with everyone staking out their position. However, reality entered into the equation and we realized that we needed the revenue. We decided to release the product. We also decided to follow the release two months later with a second release including some of the key features that we believed were lacking in the first release.

The end result was that the product sold very well very quickly, it received rave reviews from the press, and it was named "best of show" at Internet World. We did another release two months later to incorporate the most important features that the product was missing. This release was made so soon after the initial release that we only had a handful customers who needed to be upgraded.

But, the most important lesson to us was that the most important feature that the product was missing was not one that we had identified as a top priority. Until our customers started using the product in a production environment, even they didn't realize that there was a critical feature that we had low on our priority list. The lesson that we learned is that, had we delayed the release, we would have delayed an incredibly successful release for the wrong three features.

How You Know When You Have Enough

In the example above, we had done our homework. We had worked with customers closely, letting them play with the product and give us feedback (in our environment). We had a list of over 100 enhancement requests before we even went to market with the first version of the product. We understood the importance of showing our product to our customers and getting their feedback. What we forgot however, was the most basic and simple question, "Is this something you could use today?" or better yet, "Is this something you would buy today?"  If you don't have enough customers for the product yet, then use the absolute minimal feature set to get the product out for people to try. Real customer feedback is ten times more important than the list of features that internal people come up with.

The Basics

This case study is interesting because it points out how, even with the best upfront research, you still don't completely understand the market until you deploy. However, there are some basics that you should never forget before releasing a product. The following is a basic check list:

  1. Are there any major bugs in the product?

  2. Is the product easy to use? (As proven by real user testing)

  3. Are the features accessible?

  4. Is it a product that someone will pay money for in its current form?

If the answer is "no" to any of the above questions, you are not ready to release. You can get the answer to number 1 through QA efforts. But 2-4 take real user testing and honest feedback. You can't know if you are ready to release a new product until you have had real user testing.

New Product Reviews

I feel obligated to mention that if you plan to get your new product in the hands of the press and reviewers, then do not forget the all-important reviewer's guide. It is critical to the successful launch of your new product. A customer version of the reviewer's guide can also be created as an introduction to the product.