Bluescreen

There’s a big difference between a polished demo for a member versus an internal demo for your team. Internal demos should be a relaxed & low-stress since you’re presenting work-in-progress to an understanding and receptive crowd.

For a large project that’s geographically distributed however, the demos need to be somewhere in-between polished and informal.

My current project has 40 people spread across 3 offices - Chicago, DC and Chennai. We’ve found that these demos are an important tool to keep the team functioning as a cohesive unit. There’s no more efficient (and fun) way to raise awareness of what everyone’s working on and it’s often the catalyst for deeper, offline conversations.

We’ve found that these tips will make the most of the time & keep the demos engaging, so your team will look forward to sharing what they’ve done every week.

1. Always start with context

Before jumping right into your feature, spend a minute (no more usually) explaining how it fits into the bigger picture.

In other words, speak to the person sitting in the back of the class… who is not directly engaged with your feature.

Of course you need to assume folks have some level of context for an internal demo, but it’s not always the case that everyone will have an idea of exactly where your feature fits in. This is especially true with larger teams spread across cities, summer interns, etc.

Note: I’m talking notepad/wiki here - not Powerpoint. A few bullet points & a simple picture should should do the trick.

2. Dry run

This should go without saying, but take a few minutes to make sure things will actually work! Scratch out a rough script… what windows will you be switching between? What connections might need to be refreshed? Etc.

If you find that you’re not ready - just bow-out of the session. If you’re holding these demos every week it shouldn’t be a big deal.

3. Timing - Use cooking show tricks

Related to #2, think about how to handle steps that will take more than a few seconds to run. Some tricks…

Kick-off a build in the background, then talk through some other steps while it’s running

If the final step will run for a long time (e.g. a report run), kick it off live… but then pull out a “pre-baked’ result, i.e. the product of your dry-run

I’ve seen some folks record their dry-run, then present that as the demo video, fast-forwarding through slow spots.

4. Avoid pulling up code

Not always applicable, but in general… this is a demo, not a code review. Also code isn’t easy to read over a projector or GTM.

5. Disable pop-up notifications

It’s distracting & can be embarrassing. Things on this list are things like….

Skype, Jabber, Slack

Outlook new messages, Chrome notifications - e.g. gmail popups