Thursday, February 17, 2005

How often do customers want new software?

Prompted by a thread on (How often do
customers want new software?)

Frequent releases are good for development. The more often you can get
the software in the hands of the users, the quicker you can get
feedback. The sooner you get feedback the easier it is to incorporate
your new learning into the software.

Users sometimes shy away from any form of update or upgrade, and
traditionally they have good cause. New release s frequently represent a
gamble. "Will the new bugs be worse than the ones it fixes." This is
however not true for all software.

Virus checkers by there very nature support risk free updates. Users
trust that each update will only make the software better. AVG virus
checker for example allows you to specify the frequency that it checks
for updates. On finding an update it downloads it and prompts you to
accept the change. If you turn off auto update the application still
warns you when the bug data it is using is considered old/out of date,
thereby prompting users to update.

Another product that I have the same trust with is ReSharper from
Jetbrains. Through their 'early access program' (EAP) they frequently
release new builds. By subscribing to watch the download page I get
emailed when a new build is available. I usually download and installing
it that day. I trust Jetbrains to fully regression test each release
(and haven't been let down once yet), so I consider the risk of each
install is very small. I accept the occasional bug in a new feature as
this is the nature of the EAP. The risk is further reduced by the
ability to uninstall the current version in favor of an older build.
Most of the time I just avoid using the broken feature until the next
build (a couple of weeks at most). I am naturally an early adopter, and
so gain value from having the latest version at my fingers.

Jetbrains also caters for more careful customers by updating their main
site each time a new badged version is released. The EAP builds tend to
initially focus on new features, then on bug fixes until the new
features are working in everyones environment. They relying on the EAP
community to feed them bug reports to gain this vital feedback. This
'bug reporting' mechanism therefore needs to be as pain free as possible
to maximize the feedback you get from this process. Once the important
bugs are fixed a badged version is released to the wider community.

Within any user base there are early adopters, hungry for any and every
new feature. These guys are the key to making frequent releases work. If
you can build trust with these people you can gain access to the
valuable timely feedback you require as product developers. This trust
can only be built through maintaining a high level of quality for each
release and being responsive to all feedback. Users stop giving feedback
if its ignored, so always respond quickly and with a human voice. Not
everyone is an early adopter though, so this process needs to be 'opt in'.

What can you do to make more people early adopters?

* Minimize the cost of change
One or no-click upgrade process.
* Make benefits obvious.
Provide access to a list of changes represented by the update
* Minimize the risk.
Guarantee the quality of each release, and provide a mechanism to roll
back an upgrade if required.
* Make giving feedback painless and valued
Let people know that the feedback was received and provide a way for
users to be kept updated with the progress of the issue.

No comments:

GitHub Projects