The Seven Deadly Product Release Sins
Although Apple’s hardware and software often garner most of the attention at each Macworld Expo, the event is also used by most Macintosh developers to announce new or updated products. Unfortunately, a surprisingly large number of companies stumble when sending out news of their product releases. Time and again these well-meaning vendors make it difficult for news journals like TidBITS to cover their releases, which has the effect of keeping the news from potential customers.
I bring this up now because I’ve been preparing for the return of MDJ, a daily journal for serious Macintosh users. MDJ started in 1996 and went on hiatus in July, 1997; we started MWJ in the interim and will continue to publish it once MDJ returns. We have several improvements in mind for MDJ, but one thing I want to bring back is complete coverage of the Macintosh product announcements we find each day. MDJ, unlike any other journal, devoted at least one paragraph to each new product or update released since the prior issue.
Now I find that level of coverage impossible to sustain. Part of it is the price of success. Apple’s comeback has brought developers to the Mac in droves, and we often receive 40 to 60 product announcements per day. MWJ’s recent Macworld Expo wrap-up issue covered more than 300 new products or updates, and I expect we missed a few. To report on them all, even briefly, I need to cover the basics in every announcement:
- What does the product do?
- How much does it cost?
- What is new in this version, if it’s an update or upgrade?
- Where do I go for more information or to download an updater?
This is basic information you’d expect all publishers would include in press releases. Yet they don’t: more than half the announcements we cover don’t include all of this information, and some don’t include any of it. Like the folks who can’t seem to put together a decent ReadMe file, developers often fail miserably at announcing and describing their products.
<https://tidbits.com/getbits.acgi?tbser=1039>
So, if you develop Macintosh products, I’ve created a list of the seven deadly sins of product releases, any of which can prevent your product from getting the attention you might like. There are so many online Macintosh press outlets now that you’ll probably get some coverage no matter what you say, but you should never pass up an opportunity to distribute accurate information to your audience. Monthly print publications have limited space, so failing to make your product’s news clear may keep it out of those magazines, and no one in the industry press can spend hours sifting through publicity materials looking for hidden pearls.
One: Not Announcing Anything — Most developers realize that the first step to finding customers is letting the world know about their product. But you would be shocked to hear how many products never take that first step. A full-blown press release through Business Wire may cost as much as $500, but there are inexpensive alternatives for getting the word out. MDJ has a special email address <[email protected]> for announcements; so do TidBITS <[email protected]> and most other electronic media outlets. Sending an announcement by email won’t cost much, if anything.
<http://www.businesswire.com/>
The bottom line is that your customers need to know about your products, the trade press needs to write about your products, so you should announce them. A good rule of thumb: if it’s not important enough to announce, it’s not important enough to release.
Two: No Web Site Information — Some developers announce a product and point people to their Web site, then fail to publish any product information there for press and potential customers. Amazingly, this often affects the biggest developers, possibly because they have large Web sites where making changes might involve layers of bureaucracy and coordination between different departments. But making sure your Web site is updated is important – if a potential customer sees a product announcement, either via a press release or in a publication, and can’t find more information on your Web site, you’ve lost a sale.
Everyone who’s built a Web page knows that a good one takes more than twenty minutes to throw together, so plan your Web site updates as part of your product release process. Don’t think you can do it a few days later: by then your product is no longer hot news, and most publications won’t print information twice because you left something out the first time. The days when such tactics were crafty ways to get more press are long gone. These days, such tactics merely irritate journalists, which never helps your coverage.
Your Web site should also include an up-to-date archive of all your press releases. Publications work on varying schedules, and to ensure optimal coverage, you need to have information available both immediately and a week or month later for print magazine articles and in-depth reviews.
Three: Not Describing the Product — Have you ever visited the Web site for a hot new product and still had no idea what the product did? Some people might feel that way your product.
I’ve noted two related sins of omission in product descriptions. The first is buzzword hell, a spiritual location reserved for companies that throw jargon around instead of providing a clear and concise description of what the product does. The goal of your announcement should be primarily to inform, and only secondarily to impress. Your product should do all the impressing.
The second sin of omission is one of familiarity. Don’t assume everyone already knows what your product does. Provide clear descriptions of your product’s purpose and functions that are understandable to people who have never heard of your product – even if it’s been around for 15 years.
Creators of highly technical or specialized products may argue that they must speak the language of their target market, and that’s true – announcements for a product like Mathematica shouldn’t leave out details of new advanced mathematical capabilities. However, the announcement shouldn’t assume everyone knows Mathematica is "a system for doing mathematics by computer." After all, the strongest brand names are not always descriptive. Think Q-Tips, Coca-Cola, and Macintosh: if you’d never heard of them, would you know that they were cotton swabs, a soft drink, and a computer? You need to strike a balance between describing changes and describing the product itself.
Four: Not Describing Changes — Many developers include great overall product descriptions but seem to think the words "release notes" are an ancient Sanskrit infertility curse. It doesn’t matter how minor you think a release is: you must include release notes with a product update, even if it only fixes one bug.
Release notes don’t require mind-numbing detail. Every product release includes minor and obscure bug fixes that are difficult to describe in user-level documentation. But if a bug affects more than a couple of users, you should describe the bug in the update itself and on your Web pages – you waste everyone’s time and bandwidth when you force users to download a huge update to find out what it fixes. By publishing quality release notes, the press will be able to tell your customers why they should care about the update, customers will know whether the update applies to them, and users who previously gave up on your product might try it again.
Hardware developers are, to me, an enigma wrapped in a mystery. With the explosion of USB and FireWire devices (plus the now-standard PCI cards), new drivers are released literally every day – and almost none of them have any release notes. Lack of information never produces good upgrade decisions – you can’t make users upgrade, and they won’t waste their time downloading a 2 MB archive unless they know it will fix a problem. And if you don’t describe your updates in release notes, your technical support staff will have to do so on the phone, which costs you money.
Five: Not Revealing the Price — You’re probably laughing, but this sin is rampant and especially distressing to reporters, who must include pricing information in most stories. Don’t think that failing to publish a price helps in any way. If you can’t look someone in the eye and explain why your product is worth every penny, you’ve set the wrong price. You need to lower the price until you can justify it, or enhance either the product or your knowledge of how people use it until you can justify your price. Pricing software or hardware based on what you need to earn, rather than its worth to your customers, will get you in trouble every time.
Commercial developers who distribute products through resellers might hesitate to mention a price because pricing may vary by vendor; developers don’t want to undercut local stores or force them to match direct pricing. There’s a solution: the time-honored "retail price." By publishing a clearly identified retail price, commercial developers can clue in both customers and the press that the product will typically cost less than that amount. Developers can also speak in terms of a "street price," and people will understand this means the product can be found for about that price at most retailers.
The main page for your product’s Web site should either clearly mention the price, or link to a page that has the price. Don’t hide it, and don’t make people chase after it.
Six: Too Many Releases — Remember when there was no Internet? News of major new releases was spread by advertising and editorial coverage in print magazines, and sometimes by direct mail. Campaigns were carefully planned to maximize the appeal of the new product.
The Web changed all that. If you find a bug and fix it, you can post a new version on your Web site at any time, drop a note to various daily publications, and have your update on tens of thousands of systems in a couple of days. This is a definite improvement, making it easier to release frequent updates.
However, just because you can doesn’t mean you should. There are excellent programs that commit none of the first five sins but have multiple new releases per week. I’ve watched a certain network game go from version 1.5.2 to version 1.8.4 in a month and a day – sixteen releases in thirty-two days. This short-changes everyone. Not even your most dedicated customers want to download a new version of your product three times a week. What’s more, you cease to be news: releasing new versions too quickly overloads the information industry upon which you rely to spread word of the changes.
Seven: No Product, Just Hype — Sometimes developers distribute flamboyant releases implying a product is available, but when users (and the press) get to the product’s Web page they find tiny text indicating the product will be available "this fall" or at some point in the future. Congratulations: the goodwill and genuine interest garnered by your announcement has turned to irritation and suspicion.
If your product is guaranteed to be available when someone receives your announcement, clearly say so in your release and detail where to find the product. If you’re announcing that your product will be available in the future, clearly say so and state when users can expect to download and/or purchase your product. Don’t use seasonal phrases like "this fall" which only apply to one hemisphere. Failing to distinguish between a product release and a product announcement can be disastrous: potential customers will distrust you, and the industry press will treat your future releases with skepticism.
Improving the World, One Product at a Time — Ralph Waldo Emerson knew about releasing software. "A foolish consistency," he wrote, "is the hobgoblin of little minds." In truth, little here is carved in stone. For instance, your product may need frequent public updates because of its special nature: failing to give the level of service your customers need because some writer thinks you’re publishing too many updates is not a winning trade-off. If you disagree with any of these suggestions and you can back up your viewpoint with solid reasoning, then you’re right by definition. Only you know your business. Don’t cling doggedly to dogma when your business or customers demand flexibility.
Avoiding these sins may sound like a lot of work. Don’t despair. The time you invest up front will make things easier on your customers and on the members of the press, who help unite you with those customers. And it’s not as hard as it looks. Don’t forget – people want to use your products. That’s why you spent so much time creating them. Don’t lose your audience at the last minute by hiding information they need: what your product does, how much it costs, where to get more information, and what’s new. Tell people what they need to know the first time: you won’t have to answer the same questions repeatedly, and potential customers can evaluate your product, instead of searching for other solutions because they couldn’t tell whether your product would fill their needs. That alone should be enough reason to ditch bad release habits.
[Matt Deatherage is a former Apple Developer Technical Support engineer who has published articles in magazines like develop and MacAddict. He is the CEO of GCSF, Incorporated, publisher of MWJ, the Weekly Journal for Serious Macintosh Users. He is busily preparing for the return of the daily journal MDJ, plus other surprises. You can learn more about MWJ and check out a free three-issue trial subscription below.]