How to write a product review
The essential steps to writing an effective review.
by Esther Schindler
What's the most important way that most people find out about which new products to buy, and which to avoid? Whether it's groceries, minivans, or software, the opinion of respected friends and colleagues is number one. And after that comes impartial product reviews in professional and user-group magazines. And that includes extended attributes.
I should know: I've been writing product reviews professionally for about eight years, and nearly twice as long if I count my contributions to user-group newsletters since the mid-80s.
So why am I talking about this, and what does this have to do with OS/2?
I have several reasons to share my skill with you. First, extended attributes is always in need of product reviews (as Craig Greenwood, our long-suffering reviews editor, can attest). Plenty of people say they're willing to contribute to the magazine, but they're intimidated by the prospect of reviewing software, and they don't know how to go about it. (We do promise novices that extended attributes has three professional editors standing by, ready to make your text look good. But that doesn't help when you aren't sure what to say, in the first place)
So, my clearest reason for explaining how to write a review is simply to inspire you and to help you write one for this magazine. And the more OS/2 product reviews that the Phoenix OS/2 Society can provide, the more valuable we'll be to each other.
However, that's not the only reason for you to read this article. Even if you're sure that you'd never contribute a review for a user group magazine, there are more reasons for you to understand the review process.
First, you may need to evaluate a product for your business or your customers. Your own firm may need to compare products, and these instructions may assist you in organizing the process. Or, you might be curious about how professionals go about the process of evaluating software, where those "Editor's Choices" come from, and how the products get judged. Finally, you might want to write a review for another venue: a user group magazine, e-zine, or just your Web site.
The reviewer’s attitude
The most important component in a writer's toolbox is her attitude. At all times, you need to keep in mind that you're writing for the reader. Not for yourself. Not for the vendor. Not for the editor.
It's the reader who matters, and ultimately it's only the reader who matters. Some poor schnook is out there, listening to your advice, and deciding how to spend his money based on what you say. It's your job to give that reader the most useful advice you can, based on your expertise in the subject area, a thorough understanding of the reader's needs, and how well this product serves those needs. If you can keep this attitude in your head, your article will be valuable even if it's poorly organized or awkwardly written.
However, it's a common error—particularly for new reviews—to think that "the reader" is the same as "me." This process isn't about your needs. It's about your readers' needs.
That means you have to understand who the reader is, what he cares about, what problems he struggles with. A home user setting up her first network has different concerns than your IT manager boss, who's responsible for supporting 1,000 end-users. Those two computer users will have a different level of technical knowledge, too, so you'll have to explain technical features in a different way to each of them.
Sometimes, you can find out "who's the reader?" simply by asking the editor who assigned you the article. In professional publications, the editor has a very clear idea of which readers they target, which makes life easier for freelancers (at least those thoughtful enough to ask). User group publications are muddier because the membership is "anybody interested in PCs" or "any OS/2 user," but even for extended attributes, we have a reasonably clear picture. For instance, if you write for this magazine you should assume that the reader has been using OS/2 for 3-5 years and is familiar with the basics by now, even if he isn't savvy about every feature in detail.
That's not to say that the product you're reviewing is suitable only for one reader. Almost every computer user needs, say, a word processor, but some packages are more appropriate for lawyers and others are best suited to new users. While you examine the package, you should ask yourself, "For which readers is this suitable?" Part of "serve the reader" is to point out which users would appreciate this product's features. A product that's a great value for a home user may be irrelevant to a corporate user, but that doesn't make it bad.
Also, keep in mind that every product exists in a context. What is it? What other products claim to solve the same problem? If there are 100 ftp clients for OS/2 (and it sure seems that way), what's different about this one? Why did the software developer decide that the 99 other applications available weren't suitable, and spend the time writing this one instead? In a crowded marketplace, oftimes you don't need to describe what a product is, as much as you need to explain what makes it different from its competition. ("Nothing much" is an all-too-common answer.)
The essential questions
Every review must answer these questions:
- What does the product promise?
- How well does it achieve those goals?
- Is it a good value? for whom?
Everything else is just details.
The same rules apply to a restaurant review or an evaluation of stereo equipment. The rules apply whether the review is ten pages long or whether it's contained in a single sentence ("That new Ethiopian restaurant was disappointing, because the food quality wasn't up to the prices").
Evaluating the product
Before you write the review, naturally you first have to evaluate the product. Assuming that we're talking primarily about software reviews, at the moment, here's some of the steps you should take.
Obviously, you need to install and use the software in whatever seems like the ordinary manner. At first, you can use it the way you would personally, but always keep the reader's concerns in mind. At first, follow the directions and create simple projects (the proverbial "hello world" application, flow chart, or other result), and gradually get more complex.
Read the documentation. I realize that this is anathema for a lot of technical users (particularly those who seem to be tapped for a review at work, because of their expertise), but when you're writing a review it is entirely necessary. You need to understand everything the product can do (or at least what it promises to do), not just use the features that appeal to you personally. (Remember that part about staying aware of what your reader cares about?) Plus, you can't put yourself in the position of reporting that an application lacks a feature, only to have the vendor sadly respond, "It's documented right there on page 42!"
While you explore the features, look at what the product does—and also look at what the product doesn't do. It's easy to get lost in the feature chart of promises, and to become distracted from the necessary tasks that the product lacks.
For both yourself and your reader, note the difference between the features that are "need to have" versus those that are "neat to have." (Okay, so this lawnmower cuts the grass with a laser and has a connection to the Internet. Why would anybody need such a feature?) How well do these features address the problem to be solved?
Types of reviews
Finally, you have a good sense of what the product does and doesn't do, and you have an opinion about its value for your readers. How do you present the information?
There are a few standard types of reviews. A stand-alone product review examines one item only, and doesn't pay very much attention to the other products on the market. It simply examines how well this product solves the problem, and answers, "Is this good?" not "Is this better?"
On the other hand, a comparative review answers the question, "which of these products solves the problem best?" Comparative reviews are common when several products offer the same basic functionality (making the variations the important component) and when a user is apt to purchase only one of such an item (such as a DVD player or a flowchart application).
A technology overview can look like a comparative review, but they're generally not as evaluative or as exhaustive. Rather than saying whether a product is good or better than its competitors, a technology overview describes different ways to approach a problem, with products described as example solutions. These are becoming more prevalent as some product categories increase in complexity. It's nearly impossible to do a fair review of any package that requires its users to spend two months in class before generating a "hello world" result—such categories include applications like enterprise-class e-commerce development tools and customer relationship software.
There are two other article categories that are not really reviews, but are sometimes treated as such (particularly by readers who take exception to the contents): opinion columns and product announcements.
Product announcements, like the "New and Improved" pages here in extended attributes, merely say that the product exists. If there's any qualitative statement, it's attributed to the vendor ("According to the company, this is the fastest...").
While it's gratifying when opinion articles (particularly in the computer press) are based on personal experience and factual tire-kicking, that's not always the case and not necessarily required. An opinion column represents one individual's point of view, after all, which can be completely one-sided.
A review's structure
Finally, you're ready to actually set pen to paper, or fingers to keyboard. If you've done your research well, this is the easiest part of the process—at least for me. I can spend weeks evaluating a product, but it rarely takes me more than an hour to write the actual text. This isn't only because I love to write. Reviews have a very clear structure, with few variations.
First, you write an introductory paragraph. The lead paragraph (what journalists call a "lede," which is the word "lead" misspelled so that proofreaders will be likely to catch it) states the problem to be solved, and introduces the product as a possible solution. The introductory paragraph (sometimes spilling to a second one) also provides a one sentence summary: Did you like it? Is it disappointing? Provide no details, here, just the summary.
Writing an effective lede is the subject of many books on creative writing. For our purposes, let's just note that a lede needs to capture the reader's interest and give him a clue about the article's contents.
In the main body of the review, you describe what the product does, and how it works. While you can show your appreciation or disapproval of the features and process here, the underlying intent is to describe "what it promises."
Then, go into detail about what you like, and what you dislike. Though it's common for new reviewers to switch back-and-forth between the likes and dislikes (perhaps they think it sounds more fair), readers usually expect the likes to precede the dislikes.
Finally, summarize your opinion, with a strong conclusion. Tell someone with certainty: is this worth the money? Don't waffle; the reader has made it this far through your article because he wants to know if this product is worth his money. At heart: if this was your money, would you buy this product? Tell the reader so, and explain why.
There are many mistakes common to new reviewers. I'll point out a few, so you can avoid them in your own articles.
Avoid irrelevant introductions. Alan Zeichick, extended attributes' long suffering contributing editor (and longtime computer industry journalist), calls this the "First, the earth cooled..." phenomenon. ("First, the earth cooled. Then the dinosaurs came, and they got too big so they died out, and then came the mammals, and mammals invented ftp clients.") Beginners tend to provide way too much history and context at the start of a review, and most of the time it's unnecessary.
Another common mistake is to recite the feature list. Don't do this. It's boring, and it adds no value to the reader. Why should they care if the Gargleblaster has X, Y, and Z? How does that help the product deliver on its promise, or fail to do so?
If you must provide me with a long list of features, create a separate chart with checkboxes. Otherwise, tell me only about the features that are worth knowing about—because they're exceptionally good, poorly implemented, or simply unique and interesting.
Also, don't give me a tour of the installation process: "I put the disk in Drive A and typed INSTALL, and then explained that I would like to have the program installed in the C:\MYFILES directory." Don't mention specifics about the installation process unless there's something significantly wrong with the automated scripts or the vendors's instructions.
Also, keep in mind that, just because you got the product free, it doesn't mean that it's a gift, and you should thank the vendor by providing a thumbs-up review. Remember: it's not the vendor's "gift" that matters. It's the reader, who is a user-group member just like you. You're telling someone how to spend her money, and it's your duty to answer the question, "Would you spend your own hard-earned cash on this thing?"
Your relationship with the product's vendor has no part in the words you put in the review. I've heard user group members say, "But they were so nice to me!" as a reason for writing an undeserved positive review. But by now you're familiar with my refrain: it's your fellow user-group members who matter. Of course, it's in the vendor's interest to be nice to you and to enable you to review the product (such as providing it to you in the first place); but it's not the vendor you're serving.
In addition to the main body of text, your review can contain other article components, such as screen shots, box shots, feature charts, the "About this product" box, a short bio (that says why you're qualified to offer judgements on a product like this), and other article components. Ask your editor what he expects, and in what format. As a minimum, you should supply the product name, version you evaluated, full company name, the list price, and the company's URL.
Be brief. Unlike me.
When you write, keep in mind the King's advice to Alice in Wonderland: Start at the beginning. Go on until you reach the end. And then stop.
I've certainly gone into a great deal of detail here—though I worry about the points I left out—but at long last, I think I've given you enough basics that you can feel comfortable in writing a review. If you write a review for extended attributes, I'll feel as though the exercise was a success.