Good tips for a Technical presentation

Question

I am planning to give a Technical presentation for a product we are building. Intended audience is Technical developers. So, most of the time, I will be debugging trough the code in Visual Studio, performance analysis, some architecture review etc.

I have read couple of blogs on font sizes to use, templates to use on Visual Studio, presentation tools, among other very useful tips.

What I am looking specifically for is how to keep the session interesting without making it a dry code walkthrough? How to avoid making people fall asleep? Would be great to hear some stories..

Update1: Nice youtube clip on zoomit. Glue Audience To Your Presentation With Zoomit.

Update2: New post from Scott Hanselman after his PDC talk - Tips for Preparing for a Technical Presentation

Answer 1

Put interesting comments in the code.

// This better not fail during my next presentation, stupid @#$@#%$ code.

Don't talk about them, let them be found by the audience.

Answer 2

This is something that was explained to me, and I think it is very useful. You may want to consider not going to slide heavy at the beginning. You want to show your listeners something (obviously probably not the code) up front that will keep them on the edge of their seats wanting to learn about how to do what you just showed them.

Answer 3

FYI, that Hanselman article has an update (your link is from 2003).

Answer 4

You should read Mark Jason Dominus excellent presentaton on public speaking: Conference Presentation Judo

Answer 5

Use stories. Even with code examples, have a backstory: here's why someone is doing this. To increase audience participation, ask for examples of X where X is something you know you can demo, then phrase the walk-through in those terms.

Or maybe you have war stories about how it was different or how it normally takes longer or whatever. I find people identify with such things, then as you give your examples they're mentally tracking it back to their own experience.

Answer 6

I've recently started to use Mind Mapping tools for presentations and found that it goes over very well.

http://en.wikipedia.org/wiki/Mind_map

Basically, I find people just zone out the second you start to go into details with a presentation. Conveying the information with a mind map (at least in my experience), provides a much easier way for the information to be conveyed and tied together.

The key is presenting the information in stages (ie, your high-level ideas first, then in more detail, one at a time). The mind-mapping tools basically let you expand your map, as the audience watches and your present more and more detailed information. Doing it this way lets your audience gradually absorb the data in smaller stages, which tends to aid retention.

Check out FreeMind for a free tool to play with. Mind Manager is a paid product, but is much more polished and fluent.

Answer 7

Keep your "visual representation" simple and standard.

If you're on Vista hide your desktop icons and use one of the default wallpapers. Keep your Visual Studio settings (especially toolbars) as standard and "out of the box" as possible. The more customizations you show in your environment the more likely people are going to focus on those rather than your content.

Keep the content on your slides as consisce as possible. Remember, you're speaking to (and in the best scenario, with) your audience so the slides should serve as discussion points. If you want to include more details, put them in the slide notes. This is especially good if you make the slide decks available afterwards.

If someone asks you a question and you don't know the answer, don't be afraid to say you don't know. It's always better than trying to guess at what you think the answer should be.

Also, if you are using Vista be sure to put it in "presentation mode". PowerPoint also has a similar mode, so be sure to use it as well - you have the slide show on one monitor (the projector) and a smaller view of the slide, plus notes and a timer on your laptop monitor.

Answer 8

I recommend Scott Hanselman's post (previously mentioned). I've written up a post with some tips, mostly for selfish reasons - I review it every time before I give a technical presentation:

Tips for a Technical Presentation

If you're using a console prompt, make sure the font is readable and that your paths are preset when possible.

Take 15 minutes to install and learn to use ZoomIt, so your audience can clearly see what you're showing off. If you have to ask if they can see something, you've already failed.

Probably most important is to have separate Visual Studio settings pre-configured with big, readable fonts.

Answer 9

Have you heard of Pecha-Kucha?

The idea behind Pecha Kucha is to keep presentations concise, the interest level up and to have many presenters sharing their ideas within the course of one night. Therefore the 20x20 Pecha Kucha format was created: each presenter is allowed a slideshow of 20 images, each shown for 20 seconds. This results in a total presentation time of 6 minutes 40 seconds on a stage before the next presenter is up

Now, i am not sure if that short duration could be ok for a product demonstration. But you can try to get some nice ideas from the concept, such as to be concise and keep to the point, effective time, space management etc..

Answer 10

If you use slides at all, follow Guy Kawasaki's 10/20/30 rule:

• No more than 10 slides
• No more than 20 minutes spent on slides
• No less than 30 point type on slides

Answer 11

One of the best pieces of advice I ever got for doing demos is to just plain record them in advance and play back the video, narrating live. Then the unexpected stuff happens in private and you get as many stabs at it as you need.

You still usually need some environment to use as a reference for questions, but for the presentation bit, recording it in advance (and rehearsing your narration over the video) pretty much guarantees you can be at the top of your game.

I also like to put small jokes into the slides and that recorded video that make it seem like the person who made the slides is commenting on the live proceedings or that someone else is actually running the slides. Often, I make absolutely no reference at all to the joke in the slide.

For instance, in my most recent demo presentation, I had a slide with the text "ASP.NET MVC" centered that I was talking over about how I was using the framework. In a smaller font, I had the text "Catchy name, huh?". When I did that demo live, that slide got a chuckle. It's not stand-up worthy by any stretch of the imagination, but we're often presenting some pretty dry stuff and every little bit helps.

Similarly, I've included slides that are just plain snarky comments from the offscreen guy about what I'm planning to say. So, I'll say, "The codebase for this project needed a little help", while the slide behind me said "It was a pile of spaghetti with 3 meatballs, actually" and a plate of spaghetti as the slide background. Again, with no comment from me and just moving on to the next slide as though I didn't even see it actually made it funnier.

That can also be a help if you don't have the best comedic timing by taking the pressure off while still adding some levity.

Anyway, what it really comes down to is that I've been doing most of my demo/presentation work just like I would if it was a screencast and then substituting the live version of me (pausing the video as appropriate if things go off the rails) for the audio when I give it in front of an audience.

Of course, you can then easily make the real presentation available afterward for those who want it.

For the slides, I generally go out of my way to not say the exact words on the screen more often than not.

Answer 12

If you are showing code that was prepared for you then make sure you can get it to work. I know this is an obvious one but I was just at a conference where 4 out of 5 speakers had code issues. Telling me it is 'cool' or even 'really cool' when it doesn't work is a tough sell.

Answer 13

The #1 rule for me is: Don't try to show too much.

It's easy to live with a chunk of code for a couple of weeks and think, "Damn, when I show 'em this they are gonna freak out!" Even during your private rehearsals you feel good about things. But once in front of an audience, the complexity of your code is multiplied by the square of the number of audience members. (It becomes exponentially harder to explain code for each audience member added!)

What seemed so simple and direct privately quickly turns into a giant bowl of spaghetti that under pressure even you don't understand. Don't try to show production code (well factored and well partitioned), make simple inline examples that convey your core message.

My rule #1 could be construed, by the cynical, as don't overestimate you audience. As an optimist, I see it as don't overestimate your ability to explain your code!

rp

Answer 14

Since it sounds like you are doing a live presentation, where you will be working with real systems and not just charts (PPT, Impress, whatever) make sure it is all working just before you start. It never fails, if I don't try it just before I start talking, it doesn't work how I expected it to. Especially with demos. (I'm doing one on Tuesday so I can relate.)

The other thing that helps is simply to practice, practice, practice. Especially if you can do it in the exact environment you will be presenting in. That way you get a feel for where you need to be so as not to block the view for your listeners as well as any other technical gotchas there might be with regards to the room setup or systems.

Answer 15

Besides some software like Mind Manager to show your architecture, you make find a screen recorder as a presentation tool to illustrate your technical task. DemoCreator would be something nice to make video of your onscreen activity. And you can add more callout to make the process easier to understand.

Answer 16

I once wrote a series of blog posts with tips for better delivery of scientific presentations. Actually, most of the time scientific presentations are a special case (a subset) of technical presentations. These tips to not cover the techniques of technical presentation delivery, but rather give small additional points to improvement. Here you are:

• Serve presentation aperitifs
• Surprise them - make sure something unexpected happens every now and then, so that your audience doesn't fall asleep
• Make them feel uncomfortable -- At the very beginning stress the points that the major part of your audience doesn't know but will learn by the end of the presentation.