Presentations are rarely any fun to give or attend, and could be – if the presenters pay attention to some details.
The first problem, in a nutshell, is focus. The second problem is focus. The third problem? Well, that’s way different: it’s focus.
If you, as a presenter, recognize that you have to focus – hard – on what you’re presenting, then a lot of things fall into place. Your job as a presenter gets far easier, you stress less, and your audience learns more.
It applies to sales demonstrations just as much as it does conference presentations, or screencasts, or podcasts. It’s any dog-and-pony show, where “dog-and-pony show” refers to any staged demonstration to make a point or convince someone.
Sadly, it’s hard to boil down any tips past the “FOCUS!” tip – but I’d like to walk through a few aspects of focus that will help any presentation.
Define The Purpose
Any presentation needs to have a single primary takeaway point. You could lead off with it: “In this screencast, we’re going to show how GigaSpaces XAP dynamically allocates new JVMs to adjust to your application’s memory usage,” for example. With this, you’ve defined scope, and the moving parts, and the main point to watch for.
This is your map.
Since it’s a map, you need to follow it. All the secondary stuff about what XAP is, or why new JVMs are necessary, well, those are uncomfortable parts of the whole – but the purpose allows you to define them as prerequisites and sidebars.
This secondary information may be necessary for complete understanding of your presentation, and you probably want to include it as much as you can, but it’s also easy to lose your point for all the preamble.
Don’t do it. Zero in on your point. If you have prerequisite information, hit it as fast as you can and move on. If you spend more time on prerequisites than you do your main point, you’re doing it incorrectly and your focus is wrong.
Sometimes this requires a prerequisite presentation. It’s a tough problem to tackle, but if I had to look at the most common problem I’ve seen presenters have, it’s this: they didn’t define the purpose of their presentation well enough, or they didn’t follow the purpose of their presentation.
Leave Nothing to Chance
We’ve all snickered at famous presenters – Bill Gates, Rod Johnson, et al – who’ve gotten up on a large stage to demonstrate their latest and greatest… only to have things crumble around their ears. It’s embarrassing. It’s ugly. It’s distracting.
So leave nothing to chance. You need to control everything that your demonstration needs.
I’ve seen presenters fail from the silliest things: spotty networks (like that ever happens at conferences…), incorrect video cabling, firewalls, multicast support, even disk space.
Even worse… they might need to use the, um, facilities. Or leave their fly open. These are just things to think about before downing those four bottles of Coke before presenting. Look in a mirror.
Even further: they might fat-finger their demo. They mean to type “4”, and fat-finger a “5” — or maybe they fat-finger a numeric one for the lower-case l. In regular coding, no big deal – but catching syntax errors or repairing mangled configurations in a demo can be distracting and, in some cases, destructive.
There are a few things you can do.
One thing, the most obvious and comfortable to a technical audience, is to actually bring in a router and a server. Control your own network. Isolate it from everything else, so that one talented joker doesn’t take over your network; if you want to share access, go ahead, secure that you know how the network is configured, because you configured it. If you need a server available, bring it. If this presentation is important enough, you can pony up for a small server you can carry around… maybe even a set of them.
This still leaves you vulnerable to poor typing.
I understand the “do-it-now” mentality – and some of the most impressive presentations I’ve ever seen have been ones where the presenter fixes bugs that affected his presentation during the presentation. Distracting, to be sure, but very impressive. This is the ‘do-it-now’ mentality on steroids, and can be very effective… at portraying your expertise.
It really doesn’t do much for the topic of your presentation, actually. The presentation where the bugs were fixed instream? I think it was a JRuby presentation, but I’m not sure. I definitely don’t remember the primary focus of the presentation.
So what to do? Well, you can be really careful, or you can … record your presentation. Doing a deployment to Glassfish? Go right ahead – on your own time, under tightly controlled circumstances.
Record it as an animation. If you screw something up, rerecord.
Then play the animation during your presentation. Speed it up if that helps focus your point (a five-minute deployment… brutal. But animated, you can time-lapse that puppy such that it takes the one minute you need to talk about it.)
You don’t have to lie to your audience about it; of course it’s prerecorded! Tell them why. Tell them what they’re looking for, which is “can it be done? how?” — which your prerecorded bit will show.
With this, you remove reliance on external resources. All you have to have is your animations.
Keep it Small
Your presentation should have a laser-beam focus on your purpose. If you have to have lots of moving parts, it diffuses your point; this is not good.
It makes your task look complicated. This is not good, either.
The whole purpose of a presentation is to communicate a point – and anything you add to the presentation that hides the point is bad.
Keep it simple. Keep it small.
People don’t have the patience to wander through a maze of twisty steps, all alike. If you’re telling them about all the things they have to be aware of – or worse, master – to do what you’re doing, your point becomes difficult to take away.
So zero in on your purpose, your thesis. Support it like mad. Cut away everything that doesn’t have to be present.
If you can’t cut stuff out and pare your presentation down to its essence – then please, have mercy on your audience. Reiterate the thesis, simply and often.
We’re almost through with the example deployment. However, we have to do this now, because otherwise the frobnigator isn’t widgeted properly…
Of course, if you recorded the presentation’s actions, you don’t have to worry about that – you can just make a reference to any ancillary steps, without losing focus.
Use What Your Audience Knows
You have to use terms and tools your audience is familiar with.
You have to know your audience. If you don’t know your audience, try to find out what you can as early as you can – and use that knowledge. Be prepared.
For example, I attended an otherwise informative presentation once, where the presenter asked the audience what development environment was used. Eclipse was the most common, as expected for most similar groups… and the presenter shrugged and went on with IDEA.
I like IDEA, to be sure. But I would hope that you’d have had to slap me upside the head with a bucket of Crisco before I’d have done that.
He then asked if the audience knew Scala. A few hands went up, maybe less than ten percent of the audience. So which language did he use for the demonstration to a Java User’s Group?
Scala.
He then went on to demonstrate some fairly esoteric concepts… with Scala… using IDEA. Most people didn’t know what those concepts were, didn’t know Scala, wondered what Eclipse plugin looked like such a great editor.
They never had a chance.
So: use the tools your audience knows, use the jargon your audience knows, and use the techniques your audience understands. Focus on your thesis.
If your thesis requires that you do the unfamiliar – and to some degree, it’ll have to, because otherwise you’d only be preaching to a choir, and who needs that? – then your goal is to stray from the well-trodden path as little as you can, and only when you have to.
The Unmentionables
There are some unfortunate aspects to presenting that are unavoidable. The best thing you can do is to try to be aware of them, and try to compensate the best you can.
I hate this.
Look: I don’t speak well. I get my tang all tungled up, I get nervous when I’m part of a crowd, and my perfectionism cripples me when I have a chance to fail.
I know how it is, you poor devils with stage fright, or thick accents. (Meanwhile, the voice in my head, from the Deep South, says “theyick acceyents? Whut’re yew tawlkin about? Ain’t nobody got no theyick acceyent chere.” Like I said, I know how it is.)
You can always do vocal training, or standup comedy, to learn to get past these things… but for most of us, these are resources we just can’t use. (“I ain’t that funny!”)
The alternatives? You could always be less effective than your potential should allow, of course. But that’s lame.
The good alternative is honesty. So you are a native Hebrew speaker, like so many people I know? Well, try to mitigate it as much as you can… and where you can’t, admit it. Roll with it. Own it.
Are you chopping out necessary things you need to do in order to stay on topic? Admit it. Tell the audience that they’re not seeing things they would see in real life.
Tell them that you’re warping time, to compensate for the lack of resources.
Fix where you can, compensate as much as you can when you can’t fix it, be honest about it. Own it.
The Big Finish
So what we’ve talked about is the need to approach a presentation – of any kind – as if it were an essay, really, with a thesis and supporting points.
Just like in an essay, you want nothing that takes away from your thesis – everything should build it up and reinforce it.
That means:
- Knowing your thesis and staying on topic.
- Focusing on your point and eliminating everything that detracts from that focus.
- Controlling your presentation so that random events can’t screw you up.
- Staying on topic, not introducing anything extra your audience doesn’t need to understand your thesis.
- Using what your audience knows to help educate them, by introducing as few new concepts as you can.
- Accepting human limitations in the process of your presentation.
Most presenters do a great job, honestly. But there’s room for improvement; I’ve tried to outline the things I try to keep in mind when attempting effective presentations.