My previous post discussed how to research and pitch the review of a technology product. Here’s what to do once your product has been accepted for a review.
Learn as much as you can about the reviewer beforehand.
Ask who will be doing the actual review. Read the person’s previous reviews, looking for any strengths or biases.
Sometimes magazines send the products out to third parties for review and will not tell you the reviewers’ names. That definitely puts you at a disadvantage.
This happened to one of my clients, who went ahead with the review anyway because the publication was important and had a good reputation. Unfortunately, the results were disappointing. In a comparative review of business telephone systems, AT&T was given an “A.” All other participants (including my client) were given a “C.” The products were all very similar, so the discrepancy in ratings was dramatic and, frankly, puzzling at first.
Then we learned that the reviewer was actually an AT&T reseller. We notified the editor about the apparent conflict and we refused to participate in subsequent reviews when we discover that person was doing the review.
This is the most egregious conflict of interest I’ve seen in reviews, and it definitely illustrates the importance of knowing as much as possible about the reviewer.
Learn as much as you can about the reviewer beforehand.
Ask the editor what the goal of the review is. What are they trying to accomplish? To find the faster widget? The easiest-to-use? The least expensive?
Ask how the product will be reviewed. Almost any product can be tested in multiple ways. What is the methodology? What features and functionality will be emphasized? What will the evaluation criteria be?
Also, research whether the publication has reviewed this type of product before. If so, what product won? Why? What did the reviewers rate highly about the last winner? What did they rate poorly? Although editors and criteria do change, this review history can be valuable information.
You might not get all the details, but you’ll probably learn enough to determine whether the test seems reasonable, and whether your product will do well or not. If the review methodology and criteria do not fit your product, it is better not to participate. A bad review is worse than no review.
Prepare a reviewer’s guide.
In general, reviewers seem reluctant to open users’ manuals, but they do expect a reviewer’s guide. This document gives background on the product and suggests ways to test it.
In many cases, the most effective way is to arrange the guide in a “problem-solution” scenario. For example:
- Problem: The company is losing money because of delays getting information into the central database.
- Solution: This product can speed up data entry and this is how it’s done.
Include graphical material: screenshots for software, diagrams and illustrations for hardware. Consider including checkboxes for the features or functions most important to your target market.
The guide does not have to be long, but it should be done well. This is your chance to position the product, explain where it fits in the market, describe its major features and, most importantly, elaborate on its benefits to users.
Include two contact names: the PR person and a media-trained technical contact. List both their work and mobile phone numbers. Reviewers often work evenings and weekends and may need technical help after normal working hours. The success of your review may depend on your responsiveness.
Prepare a review agreement.
If the product is expensive, prepare a review agreement, which stipulates that the publication must purchase the product if it is not returned after a given period of time (typically 30 to 60 days). Have your lawyer review your agreement and get it signed before shipping the product.
Media train your product spokespeople.
Media train your spokespeople, including any technical contact who might be answering questions from the media (for any technical product). Run through the questions you think editors might ask about the product and determine the best ways to answer them.
Present your answers in terms of the end-users’ wants and needs. As much as possible, incorporate your basic messages into your answers. Use stories, data and industry trends to illustrate and substantiate your points. If possible, refer the reviewer to independent research that backs up your opinions.
Alert tech support.
Some reviews will evaluate technical support as well as the product itself. You can give the reviewers a separate phone number for support, but often they will call the general support number anyway, the better to see the kind of help end-users would get.
So always let the support department know that a reviews editor might call and probably will not identify him or herself. And do what you can to make sure your support department gets a glowing report.
And, although it should be too obvious to state, do not fire your technical support person while the review is in process. One company did just that. Unfortunately, the reviewer called right before the person left. The support contact trashed the product and the reviewer evidently took his word for it, calling the network switch “a very expensive doorstop.” The moral of this story? Select good technical contacts and keep them on the job.
This and the previous post were excellent. You should really turn your posts into a textbook, Kay.
In particular, I commend your suggestion that spokespeople be media trained. I’m thinking that some organizations may want to skip this step, citing expense, but it’s really critical to success.