Writing a Press Evaluator's Guide

Overview and Objective

Glowing product reviews in trade magazines are critical to the sales and marketing success of technology products. A positive product review can mean thousands of new leads, result significant sales increases, and provide a "stamp of approval" of sorts for future advertising and promotion.

Many companies suffer from poor product reviews because some of the best features of their products are not obvious. As a result, the review that is written up in a magazine is lacking in depth and misses the key selling points of the product. Additionally reviewer's often don't know where to start. They load the product and just try to use it. Like the rest of us, (or even more so because they consider themselves experts) they tend to avoid using manuals unless they absolutely have to.

The Evaluator's guide makes it easy for reviewers to immediately witness the benefits of a product. The result is often a positive product experience and a great product review highlighting the exact points the vendor wants to see featured.

Requirements

The press does not want to read glossy marketing material with lots of adjectives. They view this as pure hype. They will tell you that they just want to cut to the core product capabilities. This is the same reason that press releases are always written in a simple, concise format. Keeping this in mind, the Evaluator's Guide should have the following characteristics:

  • Simple formatting - Fancy layouts are wasted on the press and turn them off. The document should be primarily text with few pictures and diagrams.

  • Minimal hype - Excess adjectives and buzz words for their own sake will turn off the reviewer, the guide should discuss useful functions and concrete examples as to why a feature is useful.

  • 5-10 pages in length - As with all documentation, shorter is better. Three pages is ideal, but it is difficult to get enough substance into three pages. Ten pages is about the limit for someone actually following the guide. They will most likely go off on their own after that. Anything as larger than 20 pages is just plain intimidating. Use the front and back when printing. Remember that the reviewer is looking at many products, so short concise documents with punch are more powerful then fluffy documents laden with hype.

  • Higher level than product documentation - The reviewers are most often professional analysts. They have loaded hundreds of products and are probably looking at your competition at the same time that they are evaluating your product. They don't need details on installation, simple operations, or a detailed product description.

  • Highlight new features - If this is a new product release, the guide should highlight the changes and new features so that the reviewer can discuss those individually in their review.

Outline

The following is an example evaluator's guide outline:

1)      Product highlights - A list of the key points that will be shown in the guide. This should call out the benefits or why the feature is interesting. This should be an introductory paragraph that includes target market and then a series of bullets. This is the most often used portion of the guide and will occasionally be quoted verbatim in articles. One page maximum.

2)      Getting started - Any info needed to get the product running. This section should be kept to a minimum size. This should walk through an installation on your recommended target environment. A long or difficult installation will reflect poorly on the product. Make sure all sample files are included. You don't want the reviewer to have to do a lot of unnecessary typing.

3)      Points of interest - This provides a tutorial-type walk through of the key features of the product. This should cover the major highlights of the product. This section will include features that differentiate the product from competitive products. This is the largest section of the document.

4)      Summary - The summary is a simple ending to the document that is intended to reemphasize the product highlights. This is the least-used part of the document. One paragraph.

5)      Contact information - Company and support contact information. Often times reviewers want to evaluate the company's support as well as products.

6)      Facts at a glance - An optional section, “facts at a glance” provides an area where you can list the product, market, pricing, and availability.

Packaging

The Evaluator's Guide should be shipped proactively to all reviewers of target publications with a copy of the product and sample files on CD. Ideally it should go out with a press kit with the latest product announcement information.

The guide should also be available from the web site in both RTF format (because no one has the same version of MS Word) for download and HTML for reference.

The guide can also be repackaged as an evaluator's guide for potential prospects. The following are the recommended changes to reorient the document to this audience:

  • Remove target user out of introduction.

  • Refer to product documentation for installation. Each customer will have a different installation environment so it is best to refer to the product documentation.

  • Formatting - The document should be broken up for easy reading with diagrams and more interesting formatting.

  • Compelling descriptions - This version of the document should have richer descriptions of the features.

Process

I have found the following to be the fastest way to write an Evaluator's Guide:

1)      Spend an hour or so with a systems engineer or product manager who has gone on sales calls and knows the key selling features of the product. Have them demonstrate the product to me as a prospect.

2)      Gather a copy of the product, sample files, datasheets, Market Requirements Documents, and functional specs for back-up information.

3)      Write a first draft interactively using the product.

4)      Review first draft with product manager/systems engineer.

5)      Write second draft.

6)      Run a beta test of document with two users.

7)      Review second draft with product manager and engineering and other appropriate people.

8)      Write final draft.

Note:  Any changes happening to the product during this process may require additional passes.