How to write a stellar computer product review

Let’s say you are a college student taking journalism and your assignment is to write a review of some computing product or service. What do you do? To get things started, here are a few suggestions from someone who has been writing such reviews for more than 20 years, publishing hundreds of them in dozens of IT trade publications and Web sites.

Make sure you have the most up-to-date product version. This seems obvious, but there are many download sites that don’t make it easy for you to determine this. Make sure you are testing a shipping version too: the differences these days between beta and final versions are very blurry (remember Gmail was in “beta” for several years).  And if you are testing some Web service, realize that the code that you test today will change tomorrow, so it is important to check back when you finish review (if some time has elapsed) to make sure that you cover the new features that were recently added. I know, the Web makes for a moving target.

Go to the vendor’s Web site, collect information such as system requirements (which version of Windows, with what Service Pack and what version of .Net Framework and Internet Explorer) and make sure you have a PC that can run the software you downloaded or work with the particular hardware.  If you are testing a network product, make sure you have at least a server and a client or two for your tests. Also find the current pricing information (this is usually the hardest thing to discover), and call the PR contact listed for the company (if indeed it is listed) and tell them you are going to be reviewing the product. You could ask them for a special tech support engineer to resolve any issues, depending on the product and your own level of comfort.

Some professional reviewers shun special tech support, I find it useful especially if you are stuck with a problem that is entirely of your own ignorance and you are trying to resolve the issue and get your review finished.

Don’t write about your installation experience. Even if it was onerous, your readers don’t care. They want to know what the product does. Just get straight into the review. If you must carp about the install, write the graf and then delete it before your final edit to get it out of your system.

Give us a nut graf that sets expectations of who uses what and why. See the first graf of this screed as an example: I tell you who should read this piece and why I am qualified to write it.Most of the times this is the second graf of your review: “Microsoft’s new cloud-based thing is aimed at engineers who can understand how to configure routers in their sleep, but isn’t yet ready for the general IT population.”

Understand the context of where the product fits into your reader’s computing ecosystem. If it is a cloud-based Web application, does anyone use similar premises-based applications of equivalent functionality? Why or why not? If you don’t know the context, this would be a good time to talk to a few IT folks to get some idea of how they intend to use the product, or drawbacks in similar products that they are trying to avoid.

What breaks or doesn’t work when you try to use a Mac or Linux machine? Not everyone uses Windows PCs, you know. Dealing with a mixture of endpoints is part of the challenge of any modern IT department. Same is true for a variety of browsers. Make sure your test plan is rich enough to include these variations.

When you get some unexpected result, it is polite to call the vendor and let them know. It could be something you did. Or didn’t do. They could have a fix coming for this situation, something you might want to tell your readers about. Or you could have found a real honest-to-goodness bug. It happens.

Take copious screenshots for your own reference, as well as for ultimate publication. I prefer to use TIFFs because you can preserve higher-resolution screens. I then create a private photo album on Picasa or Flickr that I upload the screens to and link in my article so my editor can pick the ones that s/he likes. Having this record can be useful if you are going to get paid to write another article for a different publication down the road, because you won’t have to go back and try to re-create your test bed.  Windows 7 (Snap) and Mac OS (Grab) come with built-in utilities to take screenshots. Oh, and include captions on all of your screenshots too.

Look at the previous version, or at least the press release, to understand what is new and shiny and different about the current version. What did the vendor add, why did they add it, and what does that mean for users of the legacy product?

Look at the competition too. If you don’t know which products are competitors, you can ask your friendly vendor PR person. If the vendor tells you that they have no competitors (they often like to say that) and you know this not to be the case, don’t be afraid to call them out on it.

If you don’t know how to use desktop virtualization technologies, now is the time to learn. Virtual machine products such as VMware have made the product reviewer’s job a lot easier. When I began in this business, I had a room full of PCs that were setup for different situations. Now I have a hard disk filled with VMs of different operating systems, and when it is time to test something, I can make a copy from my clean master and not have to worry about reinstalling the OS if something goes south.

Email your PR contact when the review is published. These days, almost everyone has set up Google alerts but you want to show that you care. Thank them for their help, even if they were less than forthcoming. You want to build up a relationship with these folks. Don’t be afraid to enter into a dialogue with the vendor to explain your point of view and take the time to listen to where they think you missed the boat.

Good luck with your reviews and feel free to share here some of your own tips.

For a more detailed missive on how PR people should deal with the press from the press’ perspective, see the very excellent “Care and Feeding of the Press” by Esther Schindler here.

0 thoughts on “How to write a stellar computer product review

  1. Excellent advice, David. I would add just two points.

    1. Before you even start testing, check with your marketing contact and get them to tell you how the product is positioned. You might be more forgiving about missing features in a product intended for entry-level consumers than you might be for one aimed at high-end professionals. It’s better to know that before you start.

    2. After you finish the draft but before you submit it to your editor, call the company and fact check your work. At the very least, get the company and products spelled (and capitalized) correctly, and confirm the price (and is it the direct, list, or street price?). It’s good to check other details that will be published, such as capacities and limitations and requirements. My practice is to read the review but leave out any subjective statements. (DO NOT LET THE COMPANY SEE OR HEAR THE SUBJECTIVE PARTS BEFORE PUBLICATION.) Doing this step can be a pain, but believe me, it’s a lot less painful than printing a retraction if you get something wrong. (Want to ask me how I know this?)

    Even without these additions, your entry should be required reading for anyone planning to do product reviews (and their editors).


  2. Great post David… I work for a vendor, and the world would be a much better place if every product reviewer would follow your checklist (and Alfred’s additional points as well!).

    Also, it seems that the number of people who write product reviews for enterprise products is shrinking by the minute. Nowadays everyone just seems to be writing about the iPhone, Android, Facebook and other consumer oriented tools and gadgets. Hopefully some of the “college student taking journalism” that read this post will decide to turn this around and write reviews for the enterprise.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.