Volume Number: 20 (2004)
Issue Number: 6
Column Tag: Programming

Software Marketing

by Dave Woolridge

Defining the Upgrade Path

Building a Relationship with Existing Customers

In past issues, we've focused primarily on marketing methods for attracting new customers. Some of these techniques included the use of press releases, listings on software sites (like VersionTracker.com), web site promotions, e-mail newsletter mailing lists, etc. And while all of these marketing vehicles are also a great way to announce new product updates to your existing customers, it places the responsibility on the customer to seek out the latest news.

The problem with this approach is that you lose control of the information delivery. You have no idea if and when the majority of your customers will find out about your new release. Sure, you could send out an e-mail to your customers, notifying them that a new version is available, but with the current state of frenzied mail blocking programs battling the never-ending onslaught of spam, your e-mail could accidentally end up in spam trash folders as a false positive. You have no way to guarantee that your e-mail will be read by every recipient.

Controlling the information flow to your customers is important for five reasons:

Prevents your marketing message from getting diluted or blurred. Instead of simply posting your press release, some news sites write their own editorial spin on your new product update announcement. Often, some of the primary phrases and new features listed in your press release are omitted from the news story, leaving out key-selling points that would convince many customers to upgrade.

Helps keep your customers satisfied. Customers who are able to quickly resolve bugs by installing the latest maintenance update as soon as it is available are less likely to get frustrated and more likely to remain a loyal customer.

Removes obstacles. Let's say you just released version 4.5 of your product, but you still have some customers who are using version 3.0 because they are holding out for a desired feature to be added before committing to pay for the latest upgrade. These are customers that are ready to give you their hard-earned money - all they need to hear is that their requested features have been added to the latest release. Effectively communicating those magic words to these specific customers should be a priority when announcing new product updates. A great customer service technique is to include the customer's name and e-mail address in your feature requests records. Each time a feature request is implemented in a new release, send a quick e-mail to that customer, notifying them that their requested feature is now available in the latest version. They'll appreciate the personal touch and more often than not, reward your efforts by buying the major upgrades and remaining a loyal customer.

Improves your sales potential. The more customers that are aware a paid upgrade is available, the greater chance that you'll see an increase in upgrade orders.

Allows you to provide proactive customer service. Customers who find out about limited time upgrade offers AFTER the expiration date are going to be very upset that they missed the sale opportunity. They'll be furious that you did not inform them in a timely manner. Even if you did send them an e-mail (that was mistakenly trashed by their spam filter), they'll still blame you for the mishap. In this situation, you should extend the expired upgrade offer to them in a good faith effort to salvage the customer relationship. They'll walk away happy, but they won't forget the fact that they were inconvenienced.

Making sure your customers receive product update announcements in a timely manner goes beyond notifying the uninformed. Even if customers do see your latest version listed on one of the software sites, they may not realize that it's a different version than the one they already have installed. As developers, we tend to be very conscious of software version numbers, always staying on top of the latest updates. But many consumers (if not most) don't know what version of software they are running, let alone where to even find the version number. It seems logical enough to us to click the "About..." menu item to find the version number, but don't forget that we all make software for a living, so we have a slight advantage in this department. Ask an average consumer what version of QuickTime they have installed and more often than not, they'll reply, "I don't know... whatever version came with my iMac."

Customers who are aware they only have QuickTime 5 will know to upgrade to QuickTime 6 since it is obviously a major update. Where the waters get murky for most consumers is when dealing with minor releases (those mysterious second and third digits) such as 5.0.1. So even a well-informed customer may not recognize that the latest minor maintenance release (5.0.1) is different from his version because it followed so quickly on the heels of the major 5.0 release he just installed. As the developer, you desperately want him to install 5.0.1 since it fixes several bugs that could prevent unnecessary tech support requests and customer frustration.

So how do you control the information delivery to existing customers to ensure that they're not only aware of the latest product updates, but that they know the latest version is different from the one they have installed? And if it's a paid upgrade, what's so special about it? Why should they care enough to spend their hard-earned money?

An effective solution is to let your software application do most of the work! Since your customers will already have your product installed, build a version checking feature into your application that periodically alerts customers to new updates when the software is running. Take a look at some of the applications you have installed on your computer and you may find that some of them already include this convenient feature. A perfect example is Apple's Software Update feature that's built into the Mac OS. Within Software Update's preferences, you can set how often Apple's servers are checked to find updates for any of the Apple software you currently have installed. Any new updates are displayed in a window list, ready for you to download. Select an item and a brief description of the update is displayed in a field below. Check the boxes of the software you want, then click the "Install" button, and your Mac does the rest, seamlessly updating your installed applications. It's a shame that Apple has never opened up Software Update to third-party developers - imagine how automated your life would be if Software Update also updated all of your commercial and shareware applications. But recreating your own implementation of Software Update within your products is actually not as complicated as it might sound.

On Mac OS X, the most intuitive and popular place to put your "Software Updates" menu item is either in your Help menu (see Figure 1) or in your Application menu (beneath "Preferences"). Don't feel obligated to use the phrase "Software Update." Many applications use "Check for Updates," "Check for Upgrades," or some similar variation.

In order for your software application to check your web server for new versions, it obviously requires the user to have an active Internet connection. Even though roughly 40% of Internet-enabled Americans have broadband connections that are always "on," you don't want to be insensitive to those users who are still using dial-up connections or do not have online access when they launch your application (such as a laptop owner on an airplane). If someone selects your "Software Updates" menu item, the most considerate approach is to display a window with a "Check Online for Updates" button, giving them fair warning that this feature requires an active Internet connection (see Figure 2).

The more automated approach is to code your application to silently check for an active Internet connection every time it is launched. If a connection is found, then your application can query your web site and automatically notify the user that a new update is available. If a connection cannot be found, then a dialog message is displayed ("Would you like to check online for new software updates?"), giving the user an option to either Cancel or Continue. Automatically attempting to connect to the Internet without first asking for the user's "consent" can irritate some users, which is not the desired reaction you're aiming for when a built-in version checker is supposed to improve their software experience, not hamper it.

Figure 3 and Figure 4 show real world examples of this automated approach. Aladdin Systems' Stuffit Expander checks for an Internet connection when launched and if a new version is available, the utility displays the dialog message in Figure 3 after unstuffing an archive. For promoting new paid upgrades to registered BBEdit customers, Bare Bones Software periodically displays the dialog message in Figure 4 within its popular text editor.

The important thing to remember is that all of these version checking examples inform existing customers of new updates without forcing them to download them. These built-in dialog windows usually include a "Download" or "More Info" button that, when voluntarily clicked, either downloads the new version or sends the user to the official product web page online.

Another convenient option is to include a button that allows users to disable the version checking feature. Pop-up windows are annoying to many people, so even though you are providing them with helpful information, including a "Disable" button is a nice touch. Even if you use an automated approach, you should still include a "Software Updates" menu item in your application so that users can check for new updates at any time. This is especially important if a user decides to turn off the automatic version checking by clicking the "Disable" button. Having the "Software Updates" menu item available gives them a way to still access this valuable feature.

So beyond the interface considerations of your built-in version checker, once an existing Internet connection is found or a new one is established, your application can then grab the latest version data from your web site. You can store the data on your server in a simple ASCII text file or an XML file, whichever you prefer. There is no set standard for this kind of version checking, although using an XML-based file will provide greater flexibility when attempting to read and parse more than one string of data, such as your version number, release notes, list of new features, status of update (free or paid upgrade), etc.

With the immense popularity of XML, if your favorite programming language does not include built-in support for XML parsing, there's no shortage of code snippets and tutorials available online to help you with this task. Probably the most important factor is the design of your XML document. You need to establish an XML format that allows you to add additional tags in the future (if needed), yet remain backward-compatible with older products that can only parse the first version of your XML file.

Here's where things get interesting... You could build your own simplistic XML format for storing the latest version number, release notes, etc., but why reinvent the wheel when you can kill two birds with one stone? In previous issues, we've discussed listing your product with online software sites such as VersionTracker, MacUpdate, and MacShareware.net. While many of these Mac-related sites still require you to manually submit this information via web forms, MacShareware.net has created a new updating format called MacPAD. PAD, which stands for Portable Application Description, was created by the Association of Shareware Professionals (http://www.asp-shareware.org/pad/) and has become a standard mechanism for Windows developers to easily submit/update their listings on many Windows-based software sites. Instead of filling out a lengthy web form, these PAD-enabled Windows sites simply ask for the URL of your software's PAD file (located on your web server). PAD is an XML-based format that includes tags for all the usual data one might expect to deliver like product name, description, system requirements, release notes, version number, and more. The founders of MacShareware.net (and other contributing Mac developers) thought the PAD format included too many redundant and unnecessary fields that were not applicable to the Mac world, so they decided to modify the PAD format to be more Mac-centric. Hence, the new MacPAD format was born. Since MacPAD was developed as an open standard, other Mac software sites beyond MacShareware.net are being encouraged to use the format. Since you should be creating your own MacPAD file for submitting your software to MacShareware.net, why not simply use the same MacPAD file for your built-in version checking feature?

MacPAD is an XML-based format that uses the Mac OS property list file extension (.plist). Creating a MacPAD file is extremely easy. Simply download MacShareware.net's SDK from http://www.macshareware.net/sdk.html. Included in the SDK is a Mac application called MacPAD that presents you with a simple form. All you have to do is fill out the form and click save and the application outputs your MacPAD file. The SDK includes complete documentation on MacPAD's template, but here are the specific XML fields that you might want your version checker to parse: productVersion, productDownloadURL, productDescShort, productReleaseNotes, fileReleaseDateM, fileReleaseDateD, and fileReleaseDateY.

Once your MacPAD file is finished, upload it to a permanent location on your site such as http://www.mycompany.com/myproduct.plist. Now you're ready to begin testing your version checker code with your new MacPAD file.

In your application code, you could compare the installed version number with the MacPAD version number to determine if the user has the most recent update, but that may be more complicated than it needs to be. Comparing multiple decimals (such as 5.0.2 versus 5.0.3) may be trivial enough, but don't forget about alpha and beta versions. Your code would need to be smart enough to differentiate between 5.0.3b1 and 5.0.3b2.

<key>productVersion</key>
<string>5.0.3b1</string>

While comparing the two version numbers can certainly be done, don't waste your precious time when the MacPAD format includes three wonderful release date fields for day, month, and year.

<key>fileReleaseDateD</key>
<string>19</string>
<key>fileReleaseDateM</key>
<string>04</string>
<key>fileReleaseDateY</key>
<string>2004</string>

If you save the release date as constants in your application, then your version checking code can simply compare the installed version's release date with the MacPAD file's release date. If your MacPAD file boasts a more recent release date, then that proves the currently installed application is not the latest version, so your version checker can notify the user accordingly.

Knowing how you plan on delivering product updates may affect how you compile and distribute your application, so it's best to have a strategy in place before the first version is released. On Mac OS X, if your application bundle stores a lot of user support files inside the bundle, then dragging the bundle to the trash and replacing it with a new version may cause that customized data to be lost. To avoid this problem, many developers use installers to "patch" the existing application bundle, updating/replacing only specific embedded components, leaving all other data untouched. While, this strategy may work fine for large, trusted companies such as Adobe or Microsoft, consumers may be wary to use an installer from a small, independent shareware developer. If your application requires components to be installed in several places in order to run, then an installer is your only option, but if your application can be installed by simply copying it to a user's hard drive, then an installer is probably overkill. Mac OS X disk images make it easy for users to safely drag an application or folder from the disk image to their "Applications" folder without worrying about installer mishaps. With this in mind, if your application needs to save user resources and support files, save them in the user's "Documents" folder. This way, your customers can easily replace their installed version with your latest update without fear of installers and without fear of losing their support files.

Define a system for determining which updates will require paid upgrades and which updates will be provided to registered customers for free. Most commercial developers set all major version numbers as paid upgrades (such as 4.0, 4.5, 5.0), while minor releases typically indicate free maintenance releases for improvements and bug fixes (such as 5.2 and 5.2.1). If you set this kind of pattern into place, your customers will expect you to follow it. No one likes surprises and customers certainly don't like feeling that their loyalty is being exploited with excessive or unexpected paid upgrades.

It's typically a good idea to add the key-selling features to your major version releases. This way, your customers will feel that paying for the upgrade is a worthwhile expenditure. If you continuously add cool new features to your free minor updates, it devalues your paid upgrade releases. For example, if the free 5.2 and 5.3 updates each included four new features, and yet the 6.0 paid upgrade only includes three new features, customers are going to question the upgrade price. It doesn't matter that programming all of those free features devoured a lot of your time. Consumers typically don't amortize an upgrade price by factoring in all of the free minor releases they already received. In their eyes, many will find it hard to justify spending money on three new features when they're used to receiving dozens of new features for free in previous updates. Use your minor releases for issuing bug fixes and performance enhancements, while saving your big feature attractions for your major version paid upgrades.

After finalizing the feature set for your product's first 1.0 release, there will obviously be features that are left for inclusion in future versions (not to mention new feature requests that your customers will submit). Be careful to spread out new features over the course of several versions in order to provide a healthy upgrade path and lifecycle for your product. This is a precarious balance since you want every major new version to contain the right feature sets to satisfy user demands and effectively compete with other products, but if you pour everything but the kitchen sink into version 2.0, you run the risk of the "feature well" running dry for version 3.0, leaving each successive release appear lackluster. The trick is to exceed expectations with each major new release without setting a precedence so high that subsequent versions fall short in the eyes of customers and reviewers.

The last factor to consider when planning your upgrade strategy is price. It's important to remember that happy customers remain loyal customers. If they are satisfied with your product, then odds are, they will be very interested in upgrading to new versions. The nice thing about selling to your customer base is that, unlike potential new customers, existing customers are already hooked on your software. If you've done your job right (providing excellent customer service and support), then convincing loyal customers to upgrade to the latest version does not take nearly the amount of effort that it takes to successfully market your product to newcomers. So don't abuse this amazing relationship. Reward your customers' loyalty with cost-effective upgrade prices that quickly motivate them to purchase. Upgrade prices should be enough of a discount from the full price that people consider their status as a longtime customer to be a significant benefit with each new release.

Since customers already have a working version of your software installed, upgrading to the latest version may get delayed indefinitely due to busy work lives and general procrastination. Give them an incentive to upgrade sooner rather than later by offering a limited time promotion. Some software companies offer a special upgrade price that is even less than the usual upgrade price, while others throw in free bonus software as an incentive. The key is to place a time limit on the special offer, so that after a certain date, customers will be forced to pay the usual upgrade price. This is where your MacPAD file and built-in version checking feature can really help you. If you place the upgrade offer in the productReleaseNotes XML field, then your version checking code can parse and display this information within your application when it notifies customers that a new paid upgrade is available.

<key>productReleaseNotes</key>
<string>The new 5.0 includes more than 
120 new features for only $69.95. For a 
limited time only, registered customers 
can upgrade for only $19.95 (regularly 
$29.95 after June 1, 2004).</string>

This may not be exactly what the MacPAD founders had in mind when they defined this particular XML field, but since you're utilizing the MacPAD format to support two separate needs here, it's up to you to squeeze every possible benefit from this technology to best serve not only the Mac community, but also your own marketing efforts and customers.

Maintaining a strong relationship with your customers is an important step to a long and profitable product lifecycle. By communicating through your software, you can stay connected with your customers without having to send a barrage of e-mails. And rewarding customer loyalty with special upgrade prices and other benefits will earn their devotion and respect. Happy customers will recommend your software to their friends, family, and co-workers. Take care of your customers and in return, they will take care of you.

Dave Wooldridge is the founder of Electric Butterfly (www.ebutterfly.com), the web design and software company responsible for HelpLogic, Stimulus, UniHelp, and the popular developer site, RBGarage.com.