"We don’t want to let the cat out of the bag too soon."
"We know what our customers want, for god’s sake, we are average users ourselves"
"We need to focus on our product; customer feedback will delay the product release. We can always fix it later."
These are common statements made by companies/entrepreneurs. The problem is that you almost never have the chance to "do it over" if you screw up the first time. Valuable time and money are gone and your reputation is damaged.
What can you do to get valuable feedback early, without delaying the product release? The first thing to remember is that there will always be constant tension between "getting it right" and "getting it out." There is no magic formula, but starting with the right mindset and building the appropriate infrastructure for incorporating changes as the product is being built, are two critical success factors. Building the appropriate product management processes for incorporating changes (and testing them) is super important. Young companies are notorious for falling in to the "there is never time to do it right, but there is always time to do it over" syndrome.
Practically speaking – how do you solicit feedback and use it to be successful in the market as early as possible? Here are some recommendations:
· Work with a controlled customer base before you even write the product specs. This can be friends, family, business associates, former customers, as long as they are typical users of your product or service. Try to balance sophisticated users with simple users – young companies tend to skew product feedback to sophisticated users who ask for all sorts of bells and whistles that just make the "mass user" experience more difficult. Start with a small number and add more as the product becomes more defined. Too much variance at the beginning will complicate the product definition. Picking the right customer sample is not simple; prior experience is very valuable. You might want to engage with domain experts/consultants for help.
· Don’t ask customers what they want. This is a common mistake. People are usually very poor at describing what they want or need. People want to be helpful, so they will respond to this question, but it is almost never what they really want. Rather, build a story board that tells people what you are proposing and let them provide feedback. Most people are better editors than they are authors. Refine this relentlessly as you talk to more people. The outcome of this process should be consistent feedback.
· Understand alternatives solutions – young companies focus too much on competitive products instead of what "people are doing today" – for example, if you are offering a mass emailing service, your competition might likely be Excel spreadsheets and some scripts, rather than a competing service.
· As product development progresses, keep in constant contact with these "design partners" – once they provide feedback, let them know how you reacted and gauge their response. If at all possible, let them try out modifications as soon as possible.
· If you are working with a product/service for the masses – track usage online; there are tools available for this. Several key things to track are
o How long are people working with the product per product session?
o What operations are they using (and not using)?
o How often do they use the product?
I experienced this first hand when building a data network CAD system. Tracking usage of early users, we were surprised to find out that most customers did not actually use the product to build a network, but rather to figure out what network components they already had installed. (These findings were in direct contradiction to feedback from focus groups.) This feedback was critical for prioritizing future features.
· Make it easy for users to provide feedback, for example a "provide feedback" button or wiki. People generally won’t fill out forms or questionnaires. They will just stop using the product. For more sophisticated products/services, you will likely need to actively solicit feedback via phone or direct contact.
· Build alpha and beta versions early on – even if only part of the product is functional, let people try it as early as humanely possible. As long as there is sufficient utility in the product, get it out there. Make sure you disable or hide features that don’t work. I find that people are generally forgiving of bugs as long as they feel there is significant utility in what you are providing (and as long as it doesn’t lose their data, crash their computer, etc.). A clear danger sign is not being able to get users for your product early on.
· If feedback is generally negative, don’t hesitate to pull the alpha/beta program and fix what needs to be fixed. People may be forgiving but they aren’t masochists.
· Remember, the overall goal is to get customers early on, so offer a way to automatically convert testers to customers. Incentive plans, introductory pricing, and even offering the product for free in exchange for endorsements or qualified leads, are all valid approaches, depending on the product/service.
When you reach general product release with at least several real users who have paid money for your product and/or provided named endorsements, then you have done something right.