How to get your product reviewed

So, you want to get your product reviewed in one of the ZATZ publications. If you follow the steps below, you'll have a much better chance of getting that fabulous write-up.

All products submitted to ZATZ publications for review must follow the following procedure:

• We require two units of each software product and one unit for each hardware item (usually);
• The software or hardware must be completely unrestricted, without feature or time limits;
• Unless you have specifically made prior arrangement with an editor who has agreed to return your item, we generally do not return items sent to us.
• You must send us a short, one paragraph description that can be listed here on AuthorPower and in our special mailing that goes out to ZATZ authors each month;
• Be sure to provide name, address, phone, URL, and contact email for both support and review logistics;
• Send everything to reviews@zatz.com. For physical products, contact us and we'll give you the best address depending on the item and delivery method.

Once a product is submitted, it will be listed here on AuthorPower for authors to review. We never make any guarantee that your product will be reviewed or that, once reviewed, it will appear in the magazine. The first is up to whether your product fits in with anything our authors or editors are planning on writing, and the second is determined by the quality of the review and editorial theme of the publication.

You should know that our policy is to review products with what we call "kindness to the manufacturers." We know how hard it is to create a product, any product, and we don't view it as our job to bash a product. On those occasions that we find a product that, well, sucks, we'll usually just withhold the review, rather than run it.

Generally, we'll give the hapless manufacturer feedback and take another review shot when the product has been fixed. Now, there are exceptions to this. First, of course, in any review we run, we will always point out the bad as well as the good of a product, including, and especially, areas where the product needs improvement. Secondly, we will run reviews of bad products if we believe it's more important to caution our reader against predatory, misleading, or unsavory practices by the manufacturer. Thankfully, this is very rare.

We're often asked why we don't accept feature or time-limited products for review and why we ask for two copies or two units of a given product that we're reviewing. Although some developers may think it's because we want loads of goodies, the reality is that there are very specific reasons why we need multiple, unrestricted products (and why it'll benefit you). Frankly, we've got a storeroom and lab filled with piles of old review software and hardware. After a while, the gee-whiz factor wears off and all we're left with is a ton of overly large cardboard boxes our overworked editorial staff has to find a way to manage.

Want a tangible example of what happens when we get time-restricted copies for review? Here's a quote from an actual email from one of our authors:

By the way, I installed that [name deleted] product, but before I got a chance to really take a look at it, my 21-day trial period expired. I let them know that, and they sent me an extension key, but then they told me that they had a newer version out, which they also sent to me, but things have been so hectic lately that I haven't had time to even install that one.

Sadly, this was from a company who knew about our full-product review policy but tried to sneak in a limitation on the author anyway. The product never did get the review they wanted.

Here are some more reasons for our policy:

• We usually ask for two complete review units. Often one goes out to a writer in the field. Said writer often forgets to take pictures, screenshots, do a critical test, whatever during the rush to deadline. If we also don't have a second unit in our office, something critical doesn't make it into the review (or we have to hold or kill the review).

• Timing. We never really know when a review is going to run. To be honest, any given article is never a top priority. Some other action (a management crisis, a broken server, etc.) may hit one of our editors. This is often true for our outside authors, who are the top domain experts in their fields. So a review might be started, shelved, started, shelved, and finally completed. But then, two months later, when the article is going into production, again we need to test something or clarify something. If the product's time limit is over, the clarification might not be made and the review might not get run. Not good.

• Editorial calendar change. If something big suddenly happens (a major new product or problem, for instance), we often have to rework the calendar, and a project is put on hold for a while or an article is bumped for a future issue.

• If we have to dicker around with getting new codes, tracking expirations, and the like, it'll vastly increase our workload. Setting up and taking down special machines is also a pain. Given that there are so many people who want their products reviewed (and you wouldn't believe some of the wacked-out bribe offers we've personally gotten!), it's much easier for us to just review the products whose manufacturers make the process hassle-free.

• The "it doesn't work quite right" syndrome. We get lots of products that aren't quite perfect. During testing, we may hit a snag that requires measurable additional work. We'll often stick the problem on hold until we can get back to it or bring in an expert to look at it, or wait until the manufacturer has a better answer. This relates to our desire not to slam products. Our competitors will often take a fast look at a product, decide they don't like it, and write a classic "this product is shit" review. We don't do that. Instead, we keep it in mind, tracking it in our AuthorPower service (our site for authors), and continue to tinker until we find a good angle.

Of course, if there's some funky hardship reason why you can't live with our policy, contact us and we'll see if it'll make sense to make an exception.

Hardware manufacturers also often ask us why we need to keep their products around. Here are some of those reasons:

• Setup time. First off, managing hardware products is a royal pain. Often setting up a product to do testing can take hours or even days. If we're testing a phone or other "linked" device, there are often service plans to enable, dickering with the phone company, and all kinds of hassle. We have limited time and a lot of products to cover.

• Real testing. Our review process here at ZATZ is often different from most other tech magazine publishers. We go out of our way to make sure that the we have devices we review on hand for quite some time. Rather than coming out with a review of the Dell Axim X30 the day it shipped, for example, we used it actively for quite a few months. This regular use definitely helped give us a better feel for its strengths and weaknesses. We could have done a GPS product test with some local driving, but it's far better to take it on real road trips to areas where we're really relying on it, and then determining whether it's saving our trip or we want to throw it out the window. That's what readers need to know.

• Product shootouts. Our product shootouts, where we compare a bunch of like products side-by-side, are particularly popular. It is often a huge effort to get all of the similar products into the office or the lab, and they don't all arrive at once. It can take months for everything to coordinate properly. If you're not sure what a product shootout looks like, here's an example.

• Subjective reviews. Many of our competitors do rigorous lab analysis of the various products they test. They test each item in controlled conditions. However, users use hardware items in wildly uncontrolled conditions. Our readers come to us to understand, really, how the product will work for them. The only way we can tell them is to actually use the product. Admittedly, having editors and reviewers actually living with and using a product seems a strange concept, but it works. We learn the little quirks that make us want to recommend the product, as well as the snags and tips that might make the product annoying on real use.

• Huge responsibility. We make real, live spending recommendations. Our readers work really, really hard for the money they make, and whether they're spending their own, hard-earned cash or spending on behalf of their company, they want to make a good purchase choice. This gives us an awesome (and sometimes daunting) responsibility. A good or bad review could, literally, affect how millions of dollars are spent. Imagine if only 1% of our 300,000 Connected Photographer readers, for example, chose to purchase a $500 device on our recommendation. That's $1.5 million dollars being spent. We damned well better make sure we're recommending things that our readers will benefit from.

• Six Months Later series. Another question readers want answered is whether the product holds up over time. Yeah, a new PDA might look incredibly sexy on day one, but after it's been lugged all over hell and back, how is it now? Will it stand up to real use? We've got a series that revisits products to see how they hold up (for a good example, read Six months later with the palmOne Tungsten T3). Remember, six months or so after launch may be old news to a PR professional, but if you went out to buy a car, wouldn't you want to know about reliability and performance over the long term? Of course you would, and so do our readers. By the way, only a few products make it to this series. Most don't last that long or we find a better answer. If we've found a product that can be used for six long months or more, it's clearly a good purchase option.

• It is also incredibly time consuming (and space intensive) to return physical products all the time. Most of the products we get are rather delicate and are generally shipped in big boxes. If we sent everything back, we'd need another room just for box storage. It's also very time-consuming for support staff to manage and pack these things back up, and, after all, we're doing you the favor of giving you incredibly valuable extra publicity. Now, we will send back hardware products sent to us, but ONLY if you're previously arranged with an editor BEFORE you've sent the product.

But there are a few other reasons why we want to keep unrestricted copies available here in the office:

• After a review, we often get reader comments and questions. If the software is running and easily available, we answer them, both directly to the reader, sometimes on our PowerBoards, and sometimes in a follow-up article or Letters to the Editor section.

• If we're writing additional articles on similar topics, we'll often reference previously reviewed products, do additional work with them, or write something about integrating them into the solution we're writing about. If that product isn't available, we're certainly not going to take the time to set up a server; the manufacturer just lost a valuable mention.

• There are some products we mention so many times because they're in our hands that they've probably been covered or mentioned 15 or 20 times. One example: months ago, we reviewed the folding Palm Portable Keyboard. Theoretically, that's the last editorial coverage it'd ever get. But Palm decided our editor-in-chief should have one to play with. He's been taking it everywhere, kinda fell in love with it, and has been devoting some of our weekly tips to getting the most out of it, mentioning it as part of our favorite solutions, and talking it up on the lecture circuit when asked about great products.

• A review is a review, but tricks are tricks. Basically, a take-off on the previous comment. We'll run a review (usually) once. But we'll often write more about interesting products or tricks for using them if they happen to be at-hand. For example, we could certainly forsee writing a "how to dump your Notes email list into Lyris" if we happen to be running Notes and Lyris and need an article topic. Or, in DominoPower, when installing a new Linux distribution, we might comment how easy it was to install the distribution, set up Apache, and have Apache talking to Notes and to Lyris (with some specific instructions or tips if we find any).

• In a few rare occassions, we decide to keep using a product as part of our operation (with the manufacturers approval, of course, and again, you wouldn't believe some of the weirdo bribe offers I've gotten from folks in the hopes that the magazine will use their product in daily work!). If we really love them, we'll often describe the products we use. Very often, readers respond first to the products in use by us. Now, we don't know if we'll ever decide we want to use your product after the review, but many developers see a benefit if we were to tell our readers that we chose their technology for internal use instead of, say, a competitor's. To see one such example of this (and there are many more), check out the end of one of David's older editorials.

So there's our list of reasons. But the absolute bottom line is that if a product is easily available to our editors and if it's good, it'll often get repeated press, ongoing press, and regular mentions. But if it's something we see once, it'll at most be reviewed once, and sometimes not even make it that far.

P.S. One last item: during and after the review process, we'll occasionally put authors in direct contact with developers. Most of our authors are independent people, and they write reviews and articles because of their love of the technology and their desire to further their careers. They're people. Treat them politely. We've had (again, thankfully only one or two) developers who went postal on an author, either demanding specific coverage or demanding certain scheduling. Please don't do that. If you have an editorial problem or complaint, you're always welcome to contact our editor-in-chief directly at david@ZATZ.com.