3 DOs and 3 DON’Ts When Announcing a Product Release
There’s a right way, and an extremely wrong way, to tell your customers about a new release of software.
The right way greases the upgrade wheels, clearly describing the added value customers will gain, while at the same time reinforcing their decision to trust you to deliver them a high-quality product.
The wrong way seriously undermines your credibility. At best, you’ll have a support issue as customers refuse to take a risk by upgrading, but if the release announcement is really bad, customers might start to question whether your product is worth paying for.
If this sounds elementary, it is, but I’m rehashing basic release announcement rules because I’ve seen some very scary release notes go out from well-intending, extremely ambitious software entrepreneurs as recently as yesterday.
Development delays slowed this company’s release plans, so when they finally had a product that could go out as promised, they rushed the release announcement and made what I believe are 6 serious errors in the process.
It was too late for me to stop them (I saw the release note at the very same moment their customers did), but what I can do is stop other entrepreneurs like them from making these same mistakes.
Before you hit the “send” key on your next release announcement, here’s a list of DOs and DON’Ts to avoid doing harm to your good name.
Release Announcement Rule #1: DO always test your links.
Customers are busy people, so asking them to upgrade once is already an intrusion on their time. Asking them twice –- first with a link that doesn’t work, then later with a link that does –- shows you didn’t thoroughly test before sending your message, and if you didn’t test something as simple as a link, they’ll begin to wonder if you really tested your software.
Release Announcement Rule #2: DON’T rely on friends or Microsoft to catch your spelling errors.
Microsoft’s spell checker won’t catch silly yet oh-so-embarrassing mistakes like “rear” instead “rare,” and friends, frankly, don’t have enough skin in the game to make sure your work is flawless.
The mind can trick our eyes into seeing what we want to see, but our ears never lie. As a copywriter I personally learned this valuable lesson a long time ago, which is why I swear by TextAloud, a $30 dollar software that reads your text back to you.
But don’t just take my word for it. If you still think you can rely on someone else to catch your mistakes, I dare you to try TextAloud free for 15 days. Run something you’ve written by a friend, and then run the same piece through TextAloud. If you’re like me, you’ll never go back to proofreading the old fashioned way.
Release Announcement Rule #3: DON’T have your development team write the release note.
Lest you’ll end up with a message that sounds more like a development status report to management. Most developers live in a techie silo with little outside contact, so most don’t know how to explain bug fixes and enhancements from the customers’ perspective, and most don’t know how to deliver less-than-ideal messages without scaring the crap out of people. I know, because long ago I used to be a developer.
To clearly articulate value, give the job of writing the release note to someone in your organization who understands your customers and the value they derive from your product.
Release Announcement Rule #4: DO sell new value before diving into what wasn’t fixed.
This rule is a carry on to what I said about not scaring the crap out of people. If you ask a developer to write the release note, they’ll probably try to put a positive spin on the release by describing it as “more robust and bug free.”
Okay, but if all you’re selling is less bugs, I’m not buying.
I recommend you structure your release to first emphasize new capabilities. Second, move into major bugs that were fixed, but don’t go into bug-fix minutia. Finally (and only if you must), spell out what you didn’t fix.
Release Announcement Rule #5: DO take your T-I-M-E!
A rush job makes you look sloppy, and sloppy translates to all areas of your business — including your code.
The release announcement is the first impression you’ll leave with your customers, so make sure it’s a good one by taking your time to do it right.
Release Announcement Rule #6: DON’T inconvenience your customers with extra work.
In today’s software-mature world, I believe upgrades should happen auto-magically without any intervention by customers, especially when it’s a minor release from say, 3.0 to 3.1.
When you ask customers to uninstall your existing product before installing the new version, you’re basically telling them a) your time is more important than their time, and/or b) your software is so complicated and/or spread out that it’s hard to clean up via scripts.
Not only does the uninstall take more time on their part, there’s a greater likelihood of errors (which translates into more support costs), and the mere request could unnerve them as they silently wonder:
* Will I lose work I created with the prior version?
* Will the uninstall and re-install trash my computer?
You’ll eliminate all risks, doubts, and friction if you take the time to create an install process that handles the upgrade, including removing old software components.
Follow these 6 rules whenever you create a product announcement, and you’ll leave your customers with a warm and fuzzy feeling about you, and your software.
Sue Anderson
Marketing Lure, Inc.