How to get the best trade press product reviews
By David Strom
(copyright 1994, Marketing Computers magazine)
Getting a good review can make or break a product. I've written hundreds of
reviews over the past eight years for several magazines, including PC Week,
Infoworld, Communications Week, Network World, PC/Computing, and Network
Computing. Here are ten things
you can do to tip the scales in your favor:
- Set up and manage a real program with budget, staff and collaterals for
trade magazine reviews. Don't try to compete with your actual customers for
getting product to the reviewers: set aside a line-item in your marketing
budget to purchase your own product for reviewers and maintain your own inventory. It makes a difference:
Dell and Compaq have dedicated staff and budget for review machines, others
don't. Guess which companies get better treatment in the trades?
- Pick your targets carefully and know your reviewer. Focus on the major
publications in your market and get to know the actual reviewer by reading
his or her prior work and visiting the lab where they do the actual
testing. I still get calls from vendors of monitors and mice these days -- even though I don't handle those types
of products anymore.
- Do the same tests the publications do ahead of time. Get into their
mindset and understand how they interpret the results. Often the reviewers
test very little of a product's features and form their opinions on one or
two simple metrics. I do a lot of
these simulated tests for my consulting clients who find it very useful to
see ahead of time how the trades will react to their products, and their
competitors'.
- Set up a dedicated support line for reviewers and make it work. While
some publications like Infoworld want to call in to the regular support
queues to test the typical customer experience, most reviewers just don't
have the time to wait on hold. And staff this with your best people who can return the calls quickly and give
solid advice. I've often gotten support that has turned my opinion of a
product around completely because of uncovering some hidden feature.
- Understand how each reviewer views beta products. Some publications
(such as the first look writers for Infoworld and PC Week) want betas to
get the scoop on their competitors, others steer clear of them (such as my
own "Beyond Beta" column in Communications Week). Figure out the policy and work it into your overall program.
Some vendors are loathe to send betas as they feel it will set an
impression or expectations later on: it depends on how good your beta
products are. All software has bugs, it is a
fact of life. However, a bug that locks up a machine entirely is a
different kind of bug from one that disables a particular feature.
- Understand what your own engineers are telling you and make sure it is
the truth. Often times they will gloss over deficiencies or soft-sell
benefits. Get your own house in order before you go on the road to
demonstrate the product or write the press kit.
- Make sure you can articulate a product's uniqueness and understand how
to present its competitive position to the reviewer. Some reviewers make a
policy of not asking ahead of time, others want to know before they start
the review. I've seen plenty of
vendor demos that didn't do this and turned off the reviewers pretty quickly.
- Make sure your developers have the right setups to expose the product's
weaknesses. Nothing fixes product deficiencies faster. When I was at PC
Week, we found that Novell's drivers for token ring cards were slower than
for Ethernet. Our reviews made a
big deal out of this. Novell replaced the Ethernet boards in their
developer's machines with token ring products and got the developers to
write better drivers.
- Don't turn away any interested reviewer. When a publication wants to do
a comparative review or when someone from outside your targeted list calls,
consider this a positive sign and support it wholeheartedly. I can't
remember all the vendors who refused to be part of a comparative review or multiple roundup because they
feared being shown in a poor light. Or the times I had to prove to a
brain-dead marcom person that I really wasn't calling to get some free
product and yes, did do reviews for one publication or another. Sure, some of my colleagues want the freebies, but most
are buried under more product than they know what to do with. And by the
way, don't hound reviewers to get product back. I've often done reviews of
products that I've had on the shelf for several months. Consider it a cost of doing business (See step 1.)
- Understand how to follow up after the review is printed. Some reviewers
welcome contact, others have moved on to another product and can't be
bothered. Here is your chance to maintain a relationship with the reviewer.
A short email message asking how
someone arrived at a particular conclusion, or an "attaboy" saying thanks
for uncovering a product weakness, goes a long way here. Some vendors have
better corporate culture for dealing with this than others: IBM is a good
example of what not to do (they
are too defensive and have too many layers to maintain such relationships).
David Strom writes product reviews for Computerworld among others and runs his own
consulting practice in Port Washington, NY where he helps his clients
understand the reviews process. He can be reached via the internet at
david@strom.com.
David Strom
Port Washington, NY 11050 USA
US TEL: 1 (516) 944-3407