Monday I wrote about Joel Spolsky’s wonderful demo of Fog Creek’s new products. Joel did one other thing at his presentation that I found very interesting. He didn’t introduce himself (nor was he introduced by anyone else).

Pretty much everyone in the [...]]]> I’ve been writing this week on demos and presentations.

Monday I wrote about Joel Spolsky’s wonderful demo of Fog Creek’s new products. Joel did one other thing at his presentation that I found very interesting. He didn’t introduce himself (nor was he introduced by anyone else).

Pretty much everyone in the audience knew who “Joel Spolsky” was, but few would recognize him by sight. It didn’t matter; from the context, it was quickly clear that the speaker — and bug reporter — was Joel. (Just in case someone was still unsure, when he filed the bug report his name was on the onscreen form.) I’m pretty sure that if you went to that invitation-only demo, you know about Joel.

I wonder in my own presentations how much to say about myself, assuming I haven’t been introduced. One school of thought says, “What you’re selling is your credibility, so you need to establish your bona fides up front.” I don’t buy that, in most cases. If I’m part of a panel discussion, that’s one thing, but in most of my presentations people are coming to hear me. Over time, I’ve eliminated any self-introduction entirely, other than my name on the title or walk-in slide. I may start by saying, “Hi, I’m Steven Levy,” but then I jump into the initial content.

I’ve learned that people are there for the content. When I say they’re coming to hear me, what I mean is not that they’re looking to me to deliver the word from the mountaintop, but rather they’re coming because the topic interests them and they have some idea who I am, rather than walking into a room where the topic is known but the presenter is an unknown factor. I may weave occasional “bona fides” facts into my talk — e.g., “I saw in my decade and a half at Microsoft that….”

I sat through a demo Wednesday where the speaker spent the first ten minutes telling us about his life — and was proud of presenting himself in this manner. I found it profoundly uninteresting — and worse, a waste of my time. I am determined not to inflict that upon others.

So I appreciated Joel simply getting up and starting to speak. We knew who he was, even if we couldn’t have picked him out of a lineup. We’re ready to listen; now give us something worth listening to.

I wrote Monday about Joel Spolsky demoing his product “in passing,” without overtly appearing to demo it. It was a terrific idea, brilliantly carried off.

However, few of us demo products whose use can be woven into the presentation itself. (Think of demoing PowerPoint itself for the [...]]]> I’m writing this week about presentations and demos.

I wrote Monday about Joel Spolsky demoing his product “in passing,” without overtly appearing to demo it. It was a terrific idea, brilliantly carried off.

However, few of us demo products whose use can be woven into the presentation itself. (Think of demoing PowerPoint itself for the ultimate you-can-demo-it-without-appearing-to-demo-it product.)

I designed one of the early Microsoft demos for Internet Explorer. Version 3.0 was the first version that was really a usable browser. The demo didn’t sell Internet Explorer per se; rather, it told a story about how we’d be using the web in the future to shop. Internet Explorer was simply there as demoers walked potential customers through buying a shirt — a welcome-back video, personalized pages, a rotating image so you could see the shirt from all sides, a checkout cart that remembered your information, etc.

These are all things we take for granted today, but nobody was doing them in 1995 because the technology wasn’t ready. People expected we’d get to something such as we showed, but they were amazed to see it working. As a byproduct, they took away two important messages that we delivered subliminally (and then probably pounded into them in what we said afterward): Internet Explorer was now Netscape’s equal, and you should look to Microsoft technology if you wanted to ride the next wave on the web.

I loved giving the demo (and teaching others how to give it), because I wasn’t demoing technology; rather, I was walking through a scenario that had everyone fascinated — it was 1995, after all.

I hated traveling somewhere to give the demo, because it required carrying two 15-pound portable computers, a network mini-hub, and other gear, in addition to schlepping my luggage (I hadn’t heard of wheels on luggage yet) and wearing my suit jacket so it wouldn’t get wrinkled. But in the end it was worthwhile.

So while it’s rare that you’re demonstrating something where the setting itself can provide context for your product or offering, take advantage of it when and if you can.

More importantly, consider the lesson here — people care about scenarios, not products. And more than just scenarios, people care about scenarios that match what they do in their life — work life, home life, commute life, whatever. Don’t demonstrate features. Don’t demo your product. Solve a problem. The trick is to pose the problem with as little setup as you can get away with.

Demoing an app for tracking software bugs? What setup could be better than a bug that shows itself to your audience.

Demoing a browser? I showed the “Internet lifestyle” in living color and real-live-before-your-eyes bits, and let the audience make their own connections between an experience they wanted and the technology I was showing.

You’ve all seen the cartoons about the door-to-door carpet cleaner salesman who dumps mud on your carpet. You don’t have to go that far… but if you want to sell me a vacuum cleaner, show me how it cleans up a mess with no fuss and no work. (I hate vacuuming, and I have to vacuum the house when I get done writing this article.)

————

Friday I’ll talk about one other aspect of presentations that came up in Joel Spolsky’s demo.

It was delivered by Joel Spolsky, the brains behind Fog Creek Software and a brilliant thinker about various computer issues.

To set the scene, he and his team were doing a roadshow tour of Fog Creek’s new releases, the unfortunately [...]]]> I’ll write this week about demos and presentations, based on a terrific software demo I saw Thursday.

It was delivered by Joel Spolsky, the brains behind Fog Creek Software and a brilliant thinker about various computer issues.

To set the scene, he and his team were doing a roadshow tour of Fog Creek’s new releases, the unfortunately named FogBugz 8.0 and Kiln. FogBugz is a terrific software-project-management tool, and Kiln is geekware beyond what I want to write about here. (It looks like pretty good geekware; if you develop software for a large team, you might want to check it out.)

For the 30 minutes preceding the scheduled start of Joel’s presentation, the screen showed a cartoonish countdown timer with a Fog Creek logo. Right on time, Joel heads up to the rostrum, the timer goes to zero… and it crashes/bluescreens!

Joel looks at it as the crash result fills the screen with white-text-on-blue-background gobbledygook. He says something to the effect of “Sorry, it shouldn’t do that. I’ve seen this before. Let me just enter a bug to make sure it gets fixed.” He does, and starts his presentation.

A minute later, he gets a popup EMail “toast” — that blue ghost-thing that Outlook pops up at the lower right of your screen until you get smart and turn it off — saying it’s already fixed. We all can read it, and he too gets distracted by it. He looks at us and says, “I don’t think it’s fixed. At least the developer’s on line and working today. Sorry, let me just see what he’s talking about.” He goes into FogBugz, pulls up the referenced “fixed” code, and says — to an audience made up mostly of programmers — “That doesn’t look fixed to me. Sometimes, you just have to do this stuff yourself.” Now totally distracted — but with the programmers all staring at the buggy code, of course — he changes a line of code and says, “That’ll probably work now.”

Anyway, as you’ve probably figured out, it’s all staged. He keeps interrupting his talk to look at the bug, fix it, check his fix with another programmer, and so on. Meanwhile, he’s demonstrating key features of his product in a context that couldn’t have been attained in a straight demo, the audience rapt with attention. (Every programmer has had the experience of his or her code crashing during an important demo.)

He pulled it off superbly. He never winked at the “joke,” nor did he ever acknowledge that it was staged; rather, he trusted his audience to figure it out and go for the ride along with him.

Wednesday, the idea of demoing-without-demoing… which isn’t some Zen concept, but an occasional opportunity from which we can take away lessons for more quotidian demos.

A lot of discussion centers on the complex chart topping the NY Times article. Ex-McKinsey consultant and PowerPoint guru explains (and partly defends) [...]]]> There’s a lot of brouhaha today stemming from a report in the New York Times about PowerPoint negatively affecting the US military apparatus. Super-smart graphics maven Nancy Duarte, for example, chimes in here.

A lot of discussion centers on the complex chart topping the NY Times article. Ex-McKinsey consultant and PowerPoint guru explains (and partly defends) the chart here.

Most of this noise, I think, is sadly misguided.

First, PowerPoint is being used synonymously with “presentation software,” with an undercurrent of Microsoft-bashing. Exactly the same charts, good and bad, can be created with Apple’s Keystone, Open Office, and so on.

Second, presentation software doesn’t make us stupid. Taking that comment out of context is more stupid than the comment. It’s a great sound bite, but like most sound bites it lacks substance. It’s like someone quoting the Bible with “money is the root of all evil.” The original quote is “the love of money is the root of all evil” — and even that appears to be a mistranslation of “the love of money is a root of all sorts of evil.”

No, what’s making us stupid in the field of presentation software — and I don’t argue the “making us stupid” part — is twofold. Bad presentation design is making us stupid. Bad presenters are making us stupid. The use of bullet points without verbal explication and detail is making us stupid. Most of all, our relying on this stuff unquestioningly is making us stupid. To wit:

Bad presentation design is making us stupid: Nancy Duarte touches on this aspect, as does Edward Tufte. PowerPoint and its ilk are tools designed to support a presentation, not replace it. As numerous presentation specialists have said, presentation software works best when the images augment and provide a visual context to what the presenter is saying. Presenters who expect the presentation itself to carry the content are part of the problem.

Now sometimes there is deep content that goes up on the screen. Whenever I reviewed budgets or sales numbers in a group, for example, I threw them up on a screen, whether from Excel or PowerPoint. (I used Excel if we were working solely on the numbers, PowerPoint if this data was part of a larger discussion.) And then we took considerable time to understand, study, and comment on the data. Having it onscreen helped me or others point to specific items with everyone in the room understanding what was being pointed out. In other words, even here the data played second chair to the discussion. I didn’t flash this stuff and move on.

Likewise, it’s been years since I used bullet points for anything other than a meeting’s-end (or training-session’s end) summary. Bullet points are fine in this context, because the people in the room have context. They don’t present information; they help people organize information they already have received.

If you’re presenting, you carry the message. Let the visual image augment it and help make it stick. The exception is detailed data — which should also be available to participants in print or on their laptops, if possible, so they don’t have to squint at the screen.

Bad presenters are making us stupid: If you read your slides to the attendees, shame on you. But that’s only part one of a two-part sin….

The use of bullet points without verbal explication and detail is making us stupid: If you put up information-bearing bullet points without further explanation, shame on you. (A summary has — or had — further explanation; so does an agenda, which also might look like bullet points.) Bullet points are like headlines; use the headlines to highlight the story, not replace the story. I like Twitter, but its 140-character streams don’t carry a lot of information; look behind the sound bites, or texting bytes.

Here’s where the military, according to the article and the quoted book Fiasco, got in trouble. Bullet points aren’t information; they are the headlines surrounding the information cache. If you can’t open the cache, there’s no “there” there.

If you need to convey highly detailed information, the best format is a written document. That’s Word, not PowerPoint. If you’re trying to motivate people, encourage discussion, or convey core information, then use your presentation skills — which is not PowerPoint, but youPoint.

Our relying on this stuff unquestioningly is making us stupid: Sound bites make us stupid, because we stop thinking, stop analyzing, stop looking into them. Too many PowerPoint presentations, unsupported by the speaker, are nothing more than a succession of sound bites. Above, I called shame on the presenters for doing this. Here, I call shame on us for allowing it.

That doesn’t mean you have to interrupt, though sometimes you should. Rather, make sure you recognize that you’re hearing/seeing a sound bite; if that’s all the presenter is giving you, make it your business to go behind the screens and gather the information yourself before making a decision, whether that means exchanging mail or having an offline discussion with the speaker or going to the source material.