1 - Let me find that tab…

The town hall facilitator clicks the next slide. It’s an engineer’s turn to demo the new feature that she’s built this week.

“Okay. Let me share my screeeen…”

“Can you see my screen?”

(A few people: Yes)

“Okay, let me find that tab. Where is my tab…”

This person starts talking about the feature. Under the spotlight, she is nervous and talks faster than she normally does. She also spends a lot of time talking about how the feature works and too little time explaining why the feature was built.

Recordings will remove most of the nerves. It will also give us the chance to review whether our demo strikes a good balance of providing context of the problem that we’re trying to solve and showing a feature.

2 - Instant share-ability even if live demo is skipped to save time

Just yesterday we had a town hall (a digital one) that had an unrealistic schedule with too many presenters and topics and it overran its allotted time in our calendars.

This is normal. It’s not great, but it’s very common. And the right thing to do when time is running out at a town hall is to always cut it on time. Despite the enthusiasm that every presenter and the leadership team has, I believe the truth is most employees do not care to spend a single minute more attending a call with tens, hundreds, or thousands of people where they have zero agency.

So, what happens to demos that were supposed to happen but didn’t, when a town hall gets cut short?

I’ve seen 3 outcomes over the years:

It gets pushed to next week’s town hall. This creates work for the facilitator to remind presenters for the next week. It’s also going make demos a little bit stale, because the feature being demoed would have already been live for another week. It gets forgotten. Bye bye air time for feature and momentary recognition for the maker. Product managers “encourage” engineers to do a recording and share it in Slack This is a great reason to prefer recording your demos.

If a town hall runs out of time before your turn to demo, you are one upload away to sharing your demo with the organisation. Done. Walk away and do something else.

3 - Atomic re-watchability

Some organisations will record their town halls. Some will always forget to do it.

This means that people who miss the town hall won’t be able to know what they missed. It becomes a gap in their knowledge of how the product has evolved that sprint.

We can take things into our own hands as the makers and builders of an organisation by always recording our individual demos.

This creates atomic re-watchability.

Town hall wasn’t recorded? Doesn’t matter. We’ve done our part by uploading the demo in a public channel so that at least this feature doesn’t fall into someone’s knowledge gap.

4 - Demo effect can’t touch this

The “demo effect” is Murphy’s Law applied to demos. Anything that can go wrong will go wrong (over a long time horizon).

I don’t know about you, but I find it annoying to watch someone formulate a new plan to demo something when they encounter a bug while demoing. And on the other side of the fence, I find it terrifying to be in that position.

Recordings are superior to live demos because the demo effect can’t touch them.

When I encounter a bug while recording my demo, I stop recording and look into the issue and reassess. Is this vital for the demo? Can I skip this and not lose fidelity in my walkthrough?

Then I simply start recording again once I’ve decided what to do.

I find that the finished product — a recoded demo — is always higher in quality than a live demo because the demo effect can’t touch it.

Over the years, as I defaulted to recording my demos, I’ve noticed my mentality change. The demo is part of the product feature. A well implemented feature that’s poorly communicated is only a mediocre feature (because either nobody knows about it, or nobody knows how it solves their problem).

We’re not giving a commencement speech to rally and inspire the graduates, we’re presenting information. Recordings are fine a net positive.