Successful Shareware Successful Sharewareby Rick Holzgrafe
of
Semicolon Software
The first thing you have to do is choose a product to create
and sell. This is one of the hard ones, actually. There's a lot
of software out there already, and thinking of something new to
build can be a stumper. I think most shareware authors just wind
up building something they want to build, rather than something
they think will sell. There's nothing wrong with that. You're
more likely to stick with your project and produce a good piece
of work if you're interested in the work itself. But there are
a number of attributes that any product has to have if it's to
sell well. Knowing them may help you decide among several different
projects you're considering, or they may show you a way to change
your product to improve your sales.
Let's say you think paleobotany is a totally fascinating subject.
You've just spent two years creating a killer application, using
your programming skills and your deep understanding of paleobotany.
Your program is so powerful and useful that's it's an absolutely
essential, must-have tool for every person in the world... who
is a paleobotanist specializing in the early Cretaceus period
and who uses a Macintosh Powerbook in the field. How many copies
are you going to sell?
That's right, not many. A successful product must be attractive
to a wide audience. There have to be a lot of people who might
want to own your product; otherwise your sales will be few and
far between.
That might sound obvious, but apparently it isn't -- not to everybody,
anyway. I've heard more than one aspiring author describe an application
almost as limited in audience as that paleobotany tool, and complain
bitterly that no one was buying it.
Here are a few examples of successful products that have a wide
audience:
Interarchy,
by Peter N Lewis. Interarchy (formerly "Anarchie")
is an Internet file transfer application. Ten years ago this might
have been a niche product with a small audience. But with the
explosion of Internet use, nowadays nearly everyone with
a computer wants something like Interarchy.
Kaleidoscope, by Greg
Landweber and Arlo Rose. This Macintosh utility gives windows
and buttons and menus a fancier look than the standard classic Mac
appearance. It's of potential interest to everyone who owns a classic Mac.
Solitaire Till Dawn,
by (ahem) your humble servant. If there's a human being alive
who doesn't enjoy an occasional game of solitaire, I've never
met him.
You can also have excellent success with products that are of
interest to a large enough category of users, even if they aren't
in the majority. Image-processing programs come to mind, for example:
not everyone uses them, but the audience for them is still large.
Your product must be used often: daily if possible, and constantly
is even better than daily. I remember one author complaining that
no one was buying his product. It turned out that his product
was used only once by any user: it made some tweaks to the system
software on disk, and once made the tweaks were permanent. This
made it easy for users to use it and forget about it.
The author was right to complain that people were using his product
without paying for it. That's piracy, and it shouldn't happen.
But the sad truth is that it does happen, and complaining about
it won't change a thing. We'll talk more about getting people
to pay a little later. For now, the point to remember is that
most users won't pay for a product unless they're constantly reminded
about how useful or fun it is.
The same three products are good examples of programs used regularly.
Interarchy is probably used at least weekly by anybody who likes
to download software and updates from the Internet, and many people
use it many times a week. Games like Solitaire Till Dawn are addictive,
and people play them frequently. And Kaleidoscope is in constant use
if it's installed at all: its effects show in every window,
every button, every menu.
Experienced salesmen know the value of a good elevator presentation.
That's a description of your product and its benefits that is
short and clear enough to be explained to a stranger while you're
riding together in an elevator. (The stranger, to most salesmen,
is a company exec who has power to influence purchasing decisions,
and the elevator ride is the one up to the conference room where
the salesman will make the longer pitch to the other execs.)
There's a lot of shareware out there -- thousands and thousands
of products, and more coming out every day. Getting anyone to
pay attention to your product in the middle of that stampede of
shareware is tough. Nobody can download and try out all the shareware
there is, so they download only the ones that sound useful and
interesting. You've got about a paragraph (on a Web site, in a
short review, in the Info-Mac Digest -- wherever) to catch people's
attention and make them believe they should take a longer look
at your product.
I'm not going to give any examples of products without good elevator
presentations; it would take too long, if you see what I mean.
But again Interarchy, Kaleidoscope, and Solitaire Till Dawn are all good
examples.
Interarchy -- an Internet file transfer program (great start -- four words and
the reader knows basically what you're selling, and now you've
got another 85 seconds to list your best features. I won't bother
with that here.)
Kaleidoscope -- Give your Mac fancy window frames, controls, and
a cool color scheme! (A few more words than Interarchy, but still
got it out in under five seconds, and still plenty of time left
to mention all the cool features.)
Solitaire Till Dawn X -- Over sixty solitaire card games (bingo,
again we're basically done. Everybody knows what solitaire is
and why it's fun. Once more the rest of the ride is a list of
cool features.)
Here's one I'll bet you all understand, but it bears repeating: your
product must be robust. No crashes, no bugs, no misbehavior --
no excuses! It needs to "just work."
Well, perfection is difficult to achieve. I don't know anyone
who has never shipped a bug. But you've got to hate doing
that, and you've got to fix bugs as soon as you hear about them,
and put an update out.
Testing is a tremendously important part of your development process.
Initially, of course, you will be testing your product yourself.
When you reach the point where the major features are working
reasonably well, find a few people you can trust and have them
use it a while. The point of this phase is not so much to find
bugs but to learn about usability. Your testers will tell you
if any part of the program is hard to use or to understand, and
they'll have suggestions for improvements.
Keep working and testing on your own until you think the product
is done, perfect, ready to ship. At that point you must resist
the temptation to ship! Instead, begin beta testing.
There are two approaches to beta testing. You can collect a small
group of "elite" testers, taking care to pick people
you can trust to test hard and submit good, clear, detailed bug
reports. Or instead you can collect a larger group of testers.
A small group lets you work closely with each tester, and you
can choose your group so that every tester is a valuable contributor.
But with a small group it's hard to get wide coverage of different
versions of system software and hardware, and different kinds
of use patterns. A large test group provides that wide coverage,
but you'll have to settle for inferior bug reports (on the average)
and you won't have time to maintain a relationship with every
tester.
Whichever way you go, you must have a beta test! Every time I've
started a beta test, I've been convinced that my product was already
perfect. I viewed beta test as just a sort of "rubber stamp"
approval process, and expected my testers to report no problems.
Every time, I've been wrong. The testers always report major bugs
that I somehow missed in my own testing. Don't be lazy, don't
be in a hurry: run a beta test before you release your product.
Allow at least two months for it, and be prepared for it to last
much longer than that if significant bugs keep turning up.
Finding beta testers is usually easy. If you post a call for testers
to some relevant newsgroup, you will have plenty of volunteers.
You won't have to pay them anything more than a free copy of the
product under test. (Sometimes you can't even pay them that, if
your product is freeware! But they'll still volunteer in droves.)
I have usually worked with small, carefully chosen test groups.
To find good people, I post a long and detailed set of requirements
in my call for testers. Anybody who doesn't read my posting thoroughly
and follow all of its instructions is automatically rejected:
they're not careful and conscientious enough. I require them to
tell me all about their system hardware and software, and to describe
themselves and their families, their experience with testing,
their experience with products like mine, their experience with
computers in general. I use the answers both to separate the good
testers from the bad, and also to ensure a wide range of testers.
I want people with all sorts of systems, and with all amounts
of experience, from beginners to old pros. If you decide to test
with a larger group, of course you'll have to be less picky.
Run your beta test until the latest test version of your product
has gone at least two weeks without any problems reported. Nobody
will buy a shoddy product. Make it work!
This is a tough one: even though you're shareware, you've got
to be as good as a commercial product. Anything less looks cheesy.
It's best if you can be as good as or better than your best commercial
competitor. That's not always possible, of course -- few shareware
authors can match the efforts of the army of programmers, artists,
and tech writers that Adobe unleashes on every release of Photoshop,
for example. You can still have good success with a lesser product,
provided it's a good one, and provided it's a lot cheaper than
your competition. You can then be perceived as an economical alternative
for users who don't need or can't afford the high-end product.
One example that comes to mind is KeyQuencer: not as fancy as
QuicKeys, but cheaper and still a very fine, very powerful product.
Which brings us to the next point: pricing. Fans of shareware
usually list bargain prices as one of the attractions. If your
product is really as good as its commercial competition you might
get away with charging as much; but my belief is that you're better
off setting a noticeably lower price point. Remember that commercial
products come with floppies or CD's, fancy bound and printed manuals,
and often other materials. Those are benefits your customers won't
receive (true for most shareware if not all), and they represent
costs that you don't have. Pass along some of the savings to your
customers.
The Next Chapter: Patience
Introduction Product Patience Polish Pay Up Propagation Promotion Politics Links