Battle-Tested Demo Prep Tips & Tricks

01 May 2020 by Lior Kamrat

A major part of our industry and what we do, involve with creating and performing live demos. In this post, I will be sharing with you my own Battle-Tested demo buildout and prep flow tips & tricks. Hopefully, it will make you go “ha, that’s a good one”.

Doesn’t matter if you are rocking in front of 300 people or doing it online with only 10 in the session, there is nothing like a good, solid, quality demo, executed flawlessly. It’s a great feeling right?!

In the past 4.5 years at Microsoft, I performed numerous numbers of demos as well as creating demos for Azure CTO, Mark Russinovich. These had to meet the highest standards which made me come up with some new methods as well as embracing new ones I learned from my previous team members.

TL;DR

This post is long by design and shows some of the good practices I’ve collected along the way when it comes to demo prepping. If you want, you can directly jump to the “Demo Script” template.

Demo Written Script

Always, always have a written script!!! Not just that, I also highly recommend having it print out (yes yes, a physical local copy) which will help you a lot. Worst case, you’re not going to use it but when you have 1 monitor, this is gold.

As for the format, Markdown is the best in my opinion for the obvious reasons. Being able to easily do code versioning, commands-friendly, works great on the common IDE’s and just the overall syntax is what makes it my preference.

You should have the following sections in this script.

  1. Demo Desired State (Cleanup & Reset) - The things you will have to do in order to bring the demo environment back to its original (desired) state.

  2. Demo Flow Prep - The order of things in the way you will use it throughout the demo.

  3. Demo Steps - The actual steps you will perform throughout the demo.

Let’s start breaking these up…

Demo Desired State

Often, people tend no to invest a lot of time thinking about automating the process of cleaning and resetting the demo environment but sometimes, this can be the difference between a successful demo or fall flat.

For example, what happens if you are relying on environment variables and close the terminal session?! This can happen as a result of a reboot or just because you didn’t think about it when you closed it. In that case you can say goodbye to these variables.

Always have a demo cleanup/reset script. Most of the time, it will be a combination of an actual script that runs a bunch of commands and some actions you need to make. Here are some examples for these things no one remembers besides running the script:

  • Open Demo Script README file on a separate screen

  • Bring code files & web pages to the right position (i.e desired code line)

  • Align all IDE/browser tabs in the right order (consider using incognito mode & clean browser history)

  • Reset timer (if you are using one)

  • Close interruptions (few examples)

    • IM apps
    • Outlook
    • Browser notifications
    • Auto-Updates (which can pop with no warning)

Left-to-Right Flow

In demos with many elements, you’re usually going to switch between multiple apps, windows, files, etc. Those can also be broken down into multiple screens, tabs, workspace and more. You get my point…

This goes for both the order you will need to use the applications throughout the demo but also the windows or tabs within these apps.

For example:

  • You start with PowerPoint to show the demo architecture diagram

  • Switch to VSCode showing a couple of files

  • Open the web browser, going over 3 websites

  • Go back to VSCode, running a few commands in the terminal (or even using the OS terminal outside of VSCode) as well as opening a couple more files.

  • Switch back to the browser to show a couple more pages

  • Eventually back to a closing slide on PowerPoint

What I usually like to do for these kinds of scenarios, is to organize everything from left to right and document it. Not just the actual apps, the internal use of it as well. The “Left-to-Right” address to the app location in Windows Quick Lunch or macOS Dock.

a note about IDEs and code snippets in GitHub: when documenting, be specific about the code line number(s) you will need. That way you won’t have to get lost in your IDE - simple and easy!

Here is how Left-to-Right flow will look like in my doc, based on the example above.

Open from left to right:

  • PowerPoint - Slide #3

  • VSCode
    • Open tabs:
      • File1.something (line 75)
      • File2.something (line 9)
      • File3.something (line 23)
      • File4.something (line 10)
    • Open integrated terminal (make sure right path)
  • Microsoft Edge
    • Open tabs:
      • GitHub Repo 1
      • Azure Portal
      • GitHub Repo 2
      • localhost:port
      • Azure docs

The goal here is to have your apps and inner flow ready, in the order you will use it as the demo progress. Doesn’t matter if you are jumping between apps, have the inner tabs/windows ready in the right order.

Detailed README / Instructions

Practice makes perfect but it also needs to be quality practice - one that makes you execute at the highest standards. You will be surprised how many people go by saying “I know this demo inside out” but choke on game day.

The best approach I found is to document your steps and more importantly, document the ones that YOU find too picky. What is too picky?! It depends on the demo and what you consider to be an important small piece.

For example, writing something like “open browser” might not work if you have two browsers. Instead, I like to be specific and write “open Chrome” or “open Edge”. I will explain later why no detail is too small.

“Cricket Moments”

You know how you are running a command and it takes 30 seconds to complete or waiting for some data to show up on a webpage and you have this awkward silence?! This is what I like to call a “Cricket Moment”. It’s that moment that is so quiet, you can hear, well, crickets.

These moments are even worse when you are not physically on stage and and performing the demo in an online session.

Knowing where and when those moments are in your demo is 90% of the solution. The other 10% is coming up with how to fill those moments with relevant content and/or talking points.

The reason I like using a markdown format and use GitHub for my demos is so I can have good visualization on the specific moment, I like to use the :bug: icon. It’s no cricket but it’s close enough :wink: (More icons can be found here).

These moments are all about finding the right flow and create efficient time usage. Here are some ideas I am using for filling a cricket moment:

  • Talk slower :wink:

  • Show a GitHub repo or a webpage - see next section around “Browser Moments”

  • Run the required command and then talk about the code (in case running a command is what causing the crickets)

  • Provide a quick recap. Something like “so far we did this, this and that and once this is done we will move on to doing that”.

  • Ask if there are any questions (if that’s something you fill cool with in a middle of a demo)

“Browser Moments”

Another real-life example: you are working your magic, everything is going well but at the end of the demo you remembered you wanted to show that cool website or GitHub repo.

Why is that? The ones we forget are usually the ones that do not serve a critical demo functionality. These pages are the “sugar pages”, the ones that make a demo a lot sweeter. There is also the possibility you might forget about a “functional page” which will make you lose more points, demo wise. A couple of examples:

  • Functional page - after performing a rolling update to a web service, you need to open localhost:port in the browser to demonstrate how the update is now working.

  • “Sugar Page” - a GitHub repo of project which you used throughout the demo. If you think about it, using the project does not mean you always have to open the repo, right?!

This very much depends on the demo and what you want to show. My advice here is to mark these demo steps with a visual sign, same way as you might do for the “Cricket Moment” mentioned earlier. For this, I like to use the :earth_americas: icon at the end of the demo step.

Use “Browser Moments” in “Cricket Moments”

So you decided to use a “Browser Moment” to fill a “Cricket Moment”. Here is an idea of how that would look like in your demo script.

Multiple Demos COULD BE == to Multiple Environments

What if you are doing a 75min presentation with 4 demos, each being performed on a different environment?! For example, 2 demos on an Azure VM you are ssh’ing/RDP’ing to and 2 demos being performed locally on your laptop.

What I like to do is to create a small table with the demo number, name and the environment. I then print it and have it in front of me.

Demo # Demo Name Environment
1 Cool Demo Laptop
2 Lame Demo Azure VM
3 Awesome Demo Laptop / Azure VM
4 Fun Demo Laptop

In the midst of performing a demo with the stress comes with it, this table will do magic and will give a bit of extra focus you might need.

Comments are closed for this post.