[A picture of private offices at Fog Creek Software]

Joel on Software

How to demo software

by Joel Spolsky
Friday, November 16, 2007

It’s already all a blur. 26 cities. 6 weeks. 2913 attendees. $160,000. 23 hotels, one Cambridge college, one British library, and a “Sociëteit Het Meisjeshuis.” (“Gesundheit!”)

Somewhere, I don’t know where, I’m standing exhausted outside a hotel ballroom right after the umpteenth demo, and someone is giving me some ridiculous objection. “Well, it’s all good and fine what FogBugz does, but we won’t use it, because we need PROJECT MANAGEMENT.”

Excuse me, SIR? Do you have some kind of SUDDEN AMNESIA? Traumatic HEAD INJURY maybe? Did you WATCH the demo?

(I didn’t really say that.)

While I was trying to think of a nice way to reply, another potential customer, standing right there, says to the guy, “Why not try it out on a little project? Won’t cost you anything.”

A bit flips. The guy suddenly stops shaking his head and starts nodding it. “Yeah, that’s a good idea. I’ll do that,” he says, smiling. SOLD.

WTF just happened.

No matter how much I talk, I’m just one person. And no matter how much I try to sell people on FogBugz, it’s all coming from me, so that can only add up to a certain amount of credibility, and it just wasn’t passing the credibility threshold for Mr. Amnesia. It wouldn’t matter what I said. He was in “I object!” mode, groping around for some reason not to buy FogBugz, even if he couldn’t come up with anything rational.

The minute a second person—his doppelganger! Same height! Same grey hair! Dressed just like him!—said something, BLING! It was like triangulation. Oooooh! Now he’s seeing it from two different angles. It’s 3D. Must not be an optical illusion.

Social proof, Robert Cialdini calls it. That gave me an idea. I knew from the registration forms that in every city, about 30% of the attendees were already using FogBugz. I started asking a question at the beginning of the demo: “How many people here use FogBugz?” Hands go up. That’s nice. Everybody looks around. Wow, they think. People actually use this software. It’s not just some downloadable piece of shareware some guy wrote in his basement. I started getting comments like, “I didn’t realize so many people in Austin were already using FogBugz!”

The one thing you can say about the 26 public FogBugz demos that I just did is that the first one (Vancouver) was pretty weak, and the last one (Copenhagen) was much, much better, and it was pretty much continuous improvement along the way. If you ever have to do a public demo of your software, here are some of those things that I learned.

Biggest turnouts
FogBugz World Tour

  1. London
  2. Toronto
  3. Seattle
  4. Austin
  5. Boston
  6. Arlington, VA
  7. Amsterdam
  8. Vancouver
  9. Dublin
  10. Denver (Boulder)
  11. Cambridge, England
  12. San Francisco
  13. Mountain View, CA
  14. Dallas
  15. New York
  16. Atlanta
  17. Copenhagen
  18. San Diego
  19. Waterloo
  20. Emeryville, CA

Picking cities

It’s a good thing we did a survey to figure out where to go, because the number of attendees in each city was nothing like we expected. If you can only go to five cities, go to London, Toronto, Seattle, Austin, and Boston. Notice I didn’t say San Francisco or Silicon Valley. Those were 12 and 13 on our list, respectively. I have no explanation for this, other than that the huge tech community in the valley has so many damn opportunities to go to tech demos that they find them boring. Shown at right are the 20 biggest turnouts we got for the FogBugz demo.

Booking the room

If you have any control whatsoever over the place where the demo is going to take place, here are three things you absolutely have to do.

  1. Get the nicest venue in town. Big, shiny, sparkly, modern, glass and marble and wood everywhere. Your prospective customers start out with no visual image to associate with your company. The demo is the one image that’s going to stick in their head. It has to be nice. We weren’t as careful about this as we should have been, and booked a couple of frightful old relics before we realized what a bad impression we were making. Before you try hotels, look for libraries, museums, and universities: many of went into debt building beautiful, modern lecture halls and now they’re trying to rent them out to pay for all that nice blond wood paneling and the 265 built-in powered Bose speakers.
  2. Get a room that is exactly the right size. You’d much rather have a packed room with a people standing in the back and the hotel staff rushing to set up a few more rows of chairs. This is far better than a half-empty room where the audience feels like maybe this isn’t really the hottest tech event ever to hit Kitchener, Ontario. Most hotel rooms can be set up “theater style” (just rows of chairs) or “classroom style” (chairs and desks). They can fit in twice as many chairs theater style. That gives you plenty of flexibility after you book the room to change the layout so the room feels full.
  3. Get a room with very high ceilings. You’re going to be doing a demo on screen. Everyone has to be able to see it. Usually hotels have two kinds of rooms: smaller meeting rooms, with low ceilings, and ballrooms, with high ceilings. In the meeting rooms, it’s impossible to put the screen high enough for everyone to see it. Don’t trust the hotel on this. We were careful to ask every hotel if the screen was going to be visible throughout the room. They always told us it would. They were almost always lying. Just ask for the ceiling height of the room. They’re not smart enough to lie about that.

Setting the stage

Serve coffee. Coffee contains caffeine, which makes people cheerful. If you’re lucky, they’ll attribute their cheeriness to your software instead of the caffeine.

Play upbeat music while you’re waiting for everyone to arrive. The kind of popular, upbeat, Margaritaville music Americans love to listen to when they’re on vacations in warm places. Give people name tags so they introduce themselves to one another and socialize while they’re waiting. Crank up the music so they have to speak loudly. Loud music and loud conversation and a crowded room adds up to the sensation that this is the hot event.

Cover the place in professionally-produced, high-quality logo stuff. We had brochures, pens, pads, and big FogBugz banners. Wall-to-wall kiwis.

Dress exactly one level better than your audience. Too dressy, and you’ll look like you think you’re better than your customers. Not dressy enough, and the audience will get the feeling that you don’t really care.

With geeks, it’s probably enough to put on a nice Banana Republic black jacket over your polo shirt or turtleneck. Do NOT, for the LOVE OF ALL THAT IS GOOD, wear any clothing with writing on the outside. I know how much you love your JavaOne T-shirt, with the happy little waving tooth. Wear that to your wedding or something, not when you're on stage. Lose the sneakers, too.

Set the screen to 800 x 600. Make everything as big as possible. If you’re demoing an application that needs more than a half million pixels, go back home and redesign the app.

Notice the lights shining on the screen? That’ll be a problem. Find the guy who can turn them off. Sometimes there’s no switch for those particular lights. Find the guy who will come with a ladder and unscrew them.

Lock the doors until the room is ready. Otherwise people will start wandering in an hour and a half before the demo is due to start watching you change out of your beloved t-shirt, running around taping cables down on the floor, and putting brochures on every chair. This makes you look like a gopher and removes some of the authority you’re going to need to convince people to buy your software.

Bring someone with you to take care of mechanical details: passing out nametags, setting up microphones. The more people you have with you, the more legit you’ll look.

Blow them away

A common, but boring, way to design a demo is to start by stating the problem, and then explaining how your magical software solves that problem. Another boring way to design a demo is with PowerPoint slides and lots of bullet points. An incredibly boring way to design a demo is to talk about your company and how many employees you have and how many millions of kroner of revenue you make every year. Nobody cares.

The only interesting way to design a demo is to make it a story. You have a protagonist, and the protagonist has a problem, and they use the software, and they… almost solve the problem, but not quite, and then everybody is in suspense, while you tell them some boring stuff that doesn’t fit anywhere else, but they’re still listening raptly because they’re waiting to hear the resolution to the suspenseful story, and then (ah!) you solve the protagonists last problem, and all is well. There is a reason people have been sitting around telling stories around campfires for the last million years or so: people like stories.

One of the stories from the FogBugz demo: Your boss asks you when you’re going to ship, and you look at the EBS report and discover that you only have a 6% chance of making it on time, so you suggest ditching low priority features, and that doesn’t go over very well, so you drill down to the individual developer’s schedules and… (pause for long lecture on EBS algorithm) …you realize that Milton needs some help making his estimates better, and Jane needs to give some of her work to Brandon, and then you can ship on time. Ta da!

As you go along, be sure to accidentally bump into all the nice little “fit and finish” features of your product. Oh look, that column is halfway off screen. No problem. I’ll just drag it over. (“Wha!” the audience gasps, “you dragged a column in HTML?”) Oh, look, this feature is supposed to be done by next Tuesday. I’ll type “next tuesday” in the due date box. (“OMG!” they squeal. You typed “next tuesday” and it was replaced with “11/20/2007”). Those nice little touches you put so much hard work into are not the meat of the demo, so don’t talk about them, just act nonchalant. What, doesn’t every web app let you resize and drag columns?

As you go through your speech, make sure you say all the important points two ways. People tend to daydream a bit. They may have missed your point the first time. They might not be native speakers—maybe one of the words or expressions that you used is not in their vocabulary. Don’t repeat the exact same sentence twice, which is annoying and pompous. Word it differently the second time.

If you’re not an experienced public speaker, watch a videotape of yourself. Have your colleagues give you brutal and honest feedback. You may be discover that you’re doing really annoying things while you speak: fidgeting with a pen, scratching your nose (on the outside!), whatever.

As you do demos, pay close attention to what works, and what doesn’t. Vary things a little bit every time… you might stumble on better ways of doing things. The first FogBugz demo in Vancouver started with two (lame) jokes. By the time I got to Copenhagen, I had stumbled on about ten jokes that made the whole audience laugh. I had better answers to questions. I even discovered better ways to do things in FogBugz. As time goes on, if you let the demo evolve, it’ll get better and better. You can practice in front of a mirror or your colleagues, and indeed, you should, but that only gets you so far… there’s nothing like a live audience to refine a demo. (By the way, that’s why you still find Jerry Seinfeld showing up unannounced at little hole-in-the-wall comedy clubs in New York. He’s testing material.)

Follow up

Ever wonder what the difference is between sales and marketing?

The official definition is that marketing creates demand, while sales fulfils demand.

Giving demos is marketing, not sales.

You need both the pull of marketing and the push of sales to actually sell products. It’s like trying to clean out the inside of an alligator with a rope: one guy has to pull on the rope from the back, the other guy has to feed the rope in the front. Following up means contacting people who came to the demo, finding out if they have questions, answering their objections, and doing a normal sales process. It doesn’t mean being pushy or slimy. It’s just recognizing that even the people who showed up and liked your product might go back to the office and have other things to work on, and weeks might pass and they might forget the warm fuzzy feeling they got from seeing your great thing, and they might never buy it unless you call them and ask for the sale.

I screwed up the sales part. I didn’t really plan in advance for the dramatic increase in customer interest in FogBugz 6.0 that the world tour drummed up, so right now there aren’t enough people at Fog Creek to follow up with every lead… we’re struggling to keep our heads above water just answering incoming questions, which have roughly tripled since 6.0 shipped. We're getting thousands of people making FogBugz trials, so while I was in Malmö, Babak and Michael put $65,000 worth of new servers on my credit card to handle the demand. This is what I always told myself would be “a good problem to have,” but it’s a problem, nonetheless. As a bootstrapped company we didn’t really have the luxury of hiring in advance of anticipated demand, but now that the demand has materialized, we gotta hire some more great people, stat. If you're smart and get things done, please apply for a job at Fog Creek.


Have you been wondering about Distributed Version Control? It has been a huge productivity boon for us, so I wrote Hg Init, a Mercurial tutorial—check it out!

Next:

Talk at Yale: Part 1 of 3



Want to know more?

You’re reading Joel on Software, stuffed with years and years of completely raving mad articles about software development, managing software teams, designing user interfaces, running successful software companies, and rubber duckies.



About the author.

I’m Joel Spolsky, co-founder of Fog Creek Software, a New York company that proves that you can treat programmers well and still be highly profitable. Programmers get private offices, free lunch, and work 40 hours a week. Customers only pay for software if they’re delighted. We make Trello, which lets you organize anything, together, FogBugz, enlightened issue tracking software for bug tracking, and Kiln, which provides distributed version control and code reviews. I’m also the co-founder and CEO of Stack Exchange. More about me.

© 2000-2014 Joel Spolsky