Advice for Writers Part 5

By Mike Gunderloy Saturday, August 30, 2003 Today I want to talk a bit about writing product reviews. Having spent quite a while as the Product Editor for MCP Magazine, this is an area that I should know something about. As always, though, remember that what one editor likes another might detest. There are two major attractions in writing product reviews. First, they can be an easy way to break into a particular market or in to computer writing as a whole; many editors are willing to try new writers on reviews before they will let them tackle a feature story. Second, you get to keep the product. Now, there are some limits on this second benefit. Some vendors will not in fact send you full licensed product to review, but rather a 30-, 60-, or 90-day version. You can't hold this against them when writing the review, as long as you can test the product's full functionality. Also, it's not ethical to sell a review copy of a product, and it's dubious to even use it in day-to-day work after your review is finished. If you really think a product is indispensible for your own work, you ought to consider paying for it (though, frankly, most reviewers consider free software a perq of the job, and most vendors will turn a blind eye to this). Product reviews are inherently subjective, but this doesn't mean that you can just write whatever the heck you want. Rather, you need to present the readers with an informed opinion. This means taking the time to actually use the product's functionality in a realistic setting. You need to be careful to only take on reviews for products that you can actually test. At the absurd end of the spectrum, you wouldn't write a review of a Mac-only product if you only run PCs. But you also shouldn't try to review a product meant to administer a 10,000-node network if you only have a single computer to test it on. Plan on enough time to actually exercise the product, so you can see how well it holds up and give rare bugs a chance to appear. The best way to do this is to install the product on your main computer and use it on a daily basis for a while. But we all know that just installing products willy-nilly is dangerous to the stability of the operating system. If you're going to write a lot of product reviews, either maintain a separate test computer or buy a copy of VMWare or Virtual PC so that you can test in a virtual machine. The goal of a product review is to inform the reader. This means that your review should cover three critical points: What does the product do? How well does it do these things? Is it a good value for the money? As a service to readers, you should always include at least a Web site address and a price in any product review, so they can easily find more information. Some vendors don't like to quote prices, on the theory that "every deal is different." In such cases, you can normall get a "starting at $xxx" price to run in a review. This helps readers decide whether something is worth pursuing; a $100 product for a particular task may be attractive, while a $5,000 package for the same task can be completely out of reach. Make sure you include supporting evidence for your opinions. "The user interface is lousy" doesn't tell the reader much. "It was far too easy to lose changes by clicking on a different node in the tree" is more informative. Try to back up both positive and negative points. Reviewers should strive for balance, but that doesn't mean you need to include an equal number of positive and negative points. Rather, you want to get across an honest opinion of the product. one that you could defend to either the reviewer or the vendor if they phoned you later on. It's normally a good idea to wrap up the review with a final paragraph that sums up your feelings: "No organization can be without WhizBang 2000 if they're doing X, Y, and Z" or "Despite the few failings I've mentioned, if you need to cross-reference frammistans on a regular basis you'll probably find this application useful" are two reasonable examples. Just about any review will be enhanced by a screenshot showing the product in action. Make sure you know whether the publication wants screenshots, and if so how many and in what format. Try to find a screenshot that shows the product actually doing something, rather than a splash screen or a blank window. A few things not to do in a product review: Don't just regurgitate the press release that came with the product. Your editor will catch you, and you won't work for that publication again. Don't concentrate on a product other than the one that you're ostensibly reviewing. New writers are sometimes tempted to go down the road of "This product doesn't do as much as Product X. I prefer Product X because it lets me..." There is a place for comparative reviews in most publications, but don't write one unless that's what you were asked to do. Don't write a good review just because you want to stay on the vendor's good side. The magazine is in the business of providing technically accurate information to readers, not in the business of selling reviews to vendors. (Well, some magazines are in the business of selling reviews, but I'd suggest you avoid them). Do not send a copy of the review to the vendor. Most magazines do not let vendors see things before they're published. If they do, this is your editor's job, not yours. In fact, I would recommend being very wary of contacts with vendors; you should try to view the product as a customer, rather than as a privileged sort with inside information. Use your judgment here; if you need help installing or using the product, by all means call the vendor. But make up your own mind about how well it works, because they're certainly not going to give you an objective opinion. Finally, beware of conflicts of interest. Here's a piece that I wrote for the MCP Magazine review guidelines: "MCP Magazine has a zero tolerance standard for conflicts of interest. Our readers count on our reviews to be impartial, and it’s imperative that we maintain that standard. Here are some examples of situations that are not acceptable:   You write a review of a book by an author who was your co-author on another book. You write a feature article about a software product category and your employer is one of the vendors covered in the article or you work for a company with a product that should have been included in the feature article. You accept plane tickets from a vendor to visit their headquarters for a product briefing. You recommend a particular training company that you teach courses for.  You get the idea. We will not allow you to cover a product or service in which you have a direct interest. If you are unsure about whether you have a conflict of interest on a particular story, please check with your editor at the time that the story is assigned. We'll be more than happy to help you sort things out."   Mike Gunderloy is the lead developer for Larkware and author of numerous books and articles on programming topics.

Home