Giving good demos

December 11th, 2017 — 5 min read

by Martin Jernberg
by Martin Jernberg
No translations available.Add translation

This week was exhausting! I hit two big milestones for projects I've been working on for a long time. I finished the second of two React courses for egghead.io and Jamund Ferguson and I gave a demo and the announcement of paypal-scripts at work. And it went super well! Hooray!

Hooray!

The paypal-scripts demo was a big deal for me because I know the impact that paypal-scripts can have on JavaScript engineers at PayPal and I want it to be well represented so folks will give it time. It also is a big deal because I've been working on it for so long and it's always good for folks to know and appreciate that what you've been working on is worthwhile 😅.

Knowing how important it is that this demo went well, I worked hard to prepare so it would. I thought I'd share a few of the things I did to make sure that this worked out. I hope you find it helpful in making your demos better in the future!

Start with "Why"

If you haven't had the chance to read the book "Start with Why" I highly suggest you give it a read (or listen as I did). It will change the way you approach communicating with others to be more effective in getting your message across.

What does this mean for paypal-scripts? Well, we started by establishing the problem that paypal-scripts was built to solve. We talked about how at PayPal we have thousands of configuration files for tools like ESLint, Babel, and Webpack. Extrapolating from that (and other factors), we determined that it costs PayPal over $1 million per year configuring tools over and over again. 😱 By starting things out this way, it made the need really clear.

Know your audience

It helps even more if you can relate the problem to the people you're illustrating. It almost makes the people listening think: "We really need a solution to this problem!" To help them feel this way you need to speak to them in terms they understand and about things that are important to them. In our case we included both the developer productivity as well as the problem in terms of money because those are things that are important to the audience to whom we presented.

Make things as quantitative as possible

It can often be hard to measure technical things, but put forth an effort to make estimates. This puts things into perspective for folks who may not be as familiar with the problem space. Amount of money is often a good number for most folks 🤑

Pre-record any demos

The first part of your presentation starts by establishing and getting sympathy for the problem and the demo shows off the solution. Nothing ruins your efforts to capture your audience more than a demo that goes wrong. So if possible, make a recording of the demo. Edit out all the fluff. I highly suggest following the guidelines in this free egghead.io course from John Lindquist about creating great screencasts.

Making sure the demo goes off without a hitch is one reason to pre-record it. Another reason is it respects the audience's time and keeps their attention. For example, my demo of paypal-scripts was 12 minutes long recorded. Giving the same demo live would have been well over twice that time. There's a tendency to ramble when you're talking about stuff like this. If you pre-record it, you can edit that unnecessary and distracting rambling out and focus on what you really want to get across. Doing this will help you avoid this:

cookie monster thinking

That said, make sure that you'll be able to deliver a live demo in case folks have questions about things not covered in the recording, or if people want to verify that what your demo is not just smoke and mirrors 😉

Practice

Before we gave the presentation, Jamund and I ran through it. We discovered some technical difficulties with the presentation that would have been real problems during the presentation. We also noticed some deficiencies in the slides and thought of more things we could say to clarify important points. When we actually gave the presentation we nailed it. Things went super well because we had already done it before.

Conclusion

You can be the best developer in the world, but if nobody knows what value you bring to the company it wont do you or your career a whole lot of use. Make sure to maximize the impact of your communication by preparing well for demos like this. Good luck!

Kent C. Dodds
Written by Kent C. Dodds

Kent C. Dodds is a JavaScript software engineer and teacher. Kent's taught hundreds of thousands of people how to make the world a better place with quality software development tools and practices. He lives with his wife and four kids in Utah.

Learn more about Kent

If you found this article helpful.

You will love these ones as well.