A Well Run Beta Program

The rest of us might take a hint on how to run a beta program from the good folks
who are building MSN Messenger 8. The things that they are providing are not necessarily
groundbreaking, but good execution of the basics is what makes this work.

Here is a small list of some things that will make your beta program more successful:

1. Make membership exclusive. If the software will be free, use an invite
   model. Restricting access to the software actually creates an air of privilege around
   the beta program. If the software will not be free, use a registration model. In either
   case, ensure that users must commit a little to you to get involved. Following through
   with this one will gie you a controlled user base for more useful feedback.
2. Make feedback easy. Provide a drop dead simple way to provide feedback
   within the application itself. Maybe with a menu set like this:
   Help > Comment on the Software
   Help > Request a Feature
   Help > Report a Problem
3. Use the feedback. Obviously soliciting this data and storing it in
   a central repository is the first step toward improving your product. Now you must
   actually use the data and act on it. Hook it into a defect management system or something
   and assign a person to actually monitor and report on the data. Schedule regular reviews
   of common feedback themes with the lead techies, QA, and the product managers.
4. Be transparent to the beta participants. This one is the golden rule.
   Let the people know what is happening behind the scenes and what direction the software
   is taking. They are investing in you, you owe it to them. The best example of this
   I have seen is the MSN Messenger 8 beta blog here.
   The real essence of this can be seen in this
   post which discusses the feedback that people are leaving and decisions that are
   being made as a result.