Demoing Software for Fun & Profit
Wednesday, January 4, 1995 by Dave Winer.
This essay was originally written as a guide for participants at Stewart Alsop's first "Demo" conference, held in Palm Springs, CA in May 1991. It was updated in December 1994.
Demoing at Demo 
This conference is loaded with bigshots whose opinions are listened to.
Don't be nervous!
Seriously, having a product that's interesting enough to demonstrate at Stewart's conference doesn't guarantee that the demo itself is going to be interesting. It's important that you think about your demo before doing it, that you make your mistakes before showing up in Palm Springs.
Experience is everything
Experience demoing a product will help you understand what features turn people on. Your first demos will be filled with nothing but surprises. By the time you've done your twentieth or thirtieth demo there will be no surprises.
Demo to yourself first. Go through, step by step, reviewing the features. Take detours, try things out. Use the product to solve the kinds of problems it was designed to solve. Put in some real time using the product.
Then you want to demo to non-critical people. This is a double entendre. They should be non-critical meaning that they're pre-disposed not to criticize you. And non-critical because if they don't like it they might give you another chance before they tell their friends that the product is slow, unnecessary, or crashes a lot. Your ego will need a lot of support in the early demos.
If you're part of a company, demo to your tech support people. They will appreciate being in the loop with product development; and will immediately recognize why certain features are there. And they'll tell you which features you missed. Try demoing to small groups of people. Take them out to lunch afterwards and talk about the product. Listen to what they have to say.
Crashes are not funny
Crashes make you look silly. Sure, everyone understands, so they say, but in practice there's nothing worse than the awkward feeling of watching the machine reboot after a crash.
Learn what makes your software crash, and avoid doing those things! Run through the demonstration over and over, each time you get a new version from development. If the new version doesn't demo without crashing, use an older, more reliable version instead.
If your program is crash-prone, remove as many INITs, TSRs or DLLs as you can from the boot process so that reboots will happen as fast as possible. And memorize a good joke you can tell while the machine is rebooting.
Fuss over the product
The best demoers are people who have access to the source code and are inclined to fiddle with the user interface and performance of the software to make it demo better and use better. Take time in advance to make some changes to the product so it demos better.
Appreciate every feature in the product you're demoing. If you don't like the product, if you don't use it yourself, it will show.
A demo is not a tutorial
I've been given countless demos by people who think that I have to understand and appreciate every small little niche of the product. In some settings you have as much as a half hour to show off the features of your product, sometimes longer. In a tradeshow or conference setting, five minutes is the max.
Generally, you want to focus on results you can accomplish with the product, not how you accomplish those results. Complete understanding of most software products can take days, weeks, even months. If you dive into corners of the product, you must be leaving out major chunks of what the product does. The prospect walks away thinking your product is a word processor when in fact it's an integrated file manager and word processor. Bad news.
Don't start with talk
Start with your hands on the keyboard or the mouse. Make something happen on the screen while you're telling them that your product is the latest, wizziest multimedia presentation system and with an integrated information superhighway browser. No speeches! These people came to see your product, not to hear you pontificate.
Get the saliva going in minute #1
If you have five minutes to tell your story, make sure that by the time minute #1 is over, the prospect has seen enough to be totally blown away. Surely there must be one thing you can show that will make almost anyone start salivating. If not, your product has a real problem.
I remember getting my first demo of a spreadsheet in 1979, from Dan Fylstra, the president of Personal Software. Dan understood some of the basics of giving a good demo. Before minute #1 was over I had seen him enter a new number in one cell and watched the numbers ripple down and to the right. I know it was a great demo and a great product because I still get goosebumps thinking about it! Of course you can't expect to have a product as revolutionary as VisiCalc was in 1979, but there must be something that wows 'em every time. Don't save that for the end. Put it up front where it belongs.
By the way, the first feature you demo is going to be the one people talk about. You might want to vary it. If you have three killer features, rotate them through the first slot. That way when Mr. X and Ms. Y are talking about your product later in the day, one will say, "Did you see how it recalced?" And the other will say, "I think people are really going to love the way it paginates on the fly!"
OK -- let's assume you've floored them with the killer feature in minute #1. Now that you've got their attention, don't let up. Your prospect is going to be predisposed to thinking your product is great, so show some more great stuff.
Make it personal
When we were rolling out MORE at Living Videotext in 1986, I liked to show tree charts first. I'd start by typing in the name of the company president. Then ask, "Who reports to the president?" I'd enter a list of the direct reports. Then flip the switch, and voila! -- a beautiful little graphic tree chart, with their names in it. No fuss no muss. I'd flip the switch five or six times and watch their faces light up each time. Involving the prospect in the demo makes it hard for them to shift their attention. It also shows you care about them.
Can you make it funny?
Humor definitely does have a place in demos. If you're demoing an accounting program, hide a little embezzlement for your prospect to "discover." Show it to them if they don't catch it.
Eye contact is important
The demo stations at the Demo conference have been set up so that eye contact is not impossible. Look at the faces of your prospects as often as you possibly can. If you see their eyes glazing over, show them something visual that will wake them up. Don't let their boredom rattle you.
A little nausea can be a good thing
You should show at least one hard-to-understand feature in each demo. This may sound cynical, but I learned this the hard way. At Living Videotext we fussed and fussed over the first version of ThinkTank to push all of the hard features out of the initial release. At the time (1983) ease-of-use was the big industry buzzword. We fell right into the trap.
People came away from demos thinking the product was trivial. Some competitors boasted that they could have an outliner on the market within months, if not weeks. We knew that it would really take them years to match the features in ThinkTank, but the product earned a reputation for being almost insignificant.
That's why we added a dizzying feature called cloning to the second release of ThinkTank. "Great technology!" people said. Our competitors stopped sniffing.
I believe in showing off one deep feature of every product, knowing full well that most prospects won't get it. On the other hand, don't use up more than twenty or thirty seconds to show this feature, and for the most part stick with trying to build an understanding of what your product is really all about.
Prepare your materials before hand
No one wants to sit there (or stand!) while you type "Now is the time for all good men to come to the aid of their country..." If you're demoing a text product, have a memo or report on your disk so you can show the features working on a real document.
Don't get me wrong -- I think you have to do at least a little typing if only to prove that it's a real product and not a Visual Basic simulation of a product.
Here's a scene to avoid
You're in the middle of demoing your second killer feature to a group of five important prospects. A newcomer arrives with a pressing question. "Does your product do circular redundancy algorithms?" Do you stop your demo and deal with this jerk? No way!
Stick with your script. Accept detours only if you're sure it will be a turn-on for everyone getting the demo. If you can handle requests from the audience gracefully and smoothly you'll impress them. But you're courting disaster if you've never rehearsed the feature.
The wrong thing to do is to abort the five minute demo and answer the challenge. "Let's talk later," would be an excellent response.
By the way, the person with the big problem is probably a competitor.
Do a demo script
Once you've done twenty or thirty demos you'll be ready to teach other people how to demo the product. Then it pays to sit down with an outliner or word processor (if possible the product itself) and outline the demo, step by step. Put the keystrokes and mousestrokes in the major heads and the words you say in subheads.
Confidence is the most important thing
You must have confidence in your product, and confidence in your ability to sell it. The only way to get there is to practice, to think about demonstrations, and play Monday-morning quarterback. Refine your demo, and maybe even the product, and experiment and rehearse until you win every time.
About the author
Dave Winer, 39, has been a commercial software developer, marketer and software demoer since 1979. Winer pioneered the category of outline processing, shipping ThinkTank for the IBM PC, Apple II and Macintosh in 1983 and 1984; Ready for the IBM PC in 1985 and MORE for Macintosh in 1986. MORE won MacUser's first Product of the Year Eddy in 1986. He founded and was president of Living Videotext, Inc., which merged with Symantec in 1987. Winer served on the board of Symantec before founding UserLand Software in 1988. He is one of the two primary developers of the UserLand Frontier scripting software. Frontier won MacUser's Eddy award for best new development tool in 1992. Winer holds a MS in Computer Science, (University of Wisconsin, 1978) and a BA in Mathematics (Tulane University, 1976).
See you tomorrow morning with a report from MacWorld Expo!
Dave Winer
5/21/99 Postscript: Never demo on a development server.