Live demos are a staple of digital teams. They’re the most efficient way to show progress and get feedback about your project. Seeing working products, services and features in action is the easiest way to help people understand them. Hence: show the thing.
Good demos build trust in what you’re building, and the people building them. But because they’re so ingrained in our work cycles, they can become stale.
Here’s what we’ve learned works well over our years of practice. Hopefully this will help keep your demos interesting and useful to others. (Feedback welcome!)
What we mean by live demo
By live demo, we mean one that’s happening in the moment, not pre-recorded. But not necessarily in person. Online demos have become normal. They’re easiest for large, distributed organisations, which is why we advocate for remote-friendly tools.
We’re working on the assumption you’ll use your organisation’s preferred calls and screen-sharing app, whether that’s Teams, Zoom, Hangouts or whatever.
What, when and who?
We recommend breaking out of the cycle of demoing any old thing just because a sprint schedule says it’s time. If you have something interesting to show at the end of a sprint, great.
If you find yourself wondering what to demo, that’s a sign that the cadence can be optimised. Do away with demos that amount to status updates. These are useful, but don’t warrant getting everyone together. Write week notes instead.
Another benefit: you’ll break the pattern of different teams demoing at the same time. This can mean teams end up demoing to themselves.
What to demo
What should you demo? For us, there are three criteria:
- Is it visual?
- Is it interesting?
- Will people understand it?
If the answer to all three is yes, demo it. Especially if you’re showing something that’s new to the organisation. Design systems are a great example.
When we say visual, we don’t mean pretty. We’ve found showing design tokens as text strings helps make them tangible.
If you’re not familiar with design tokens, you can think of them as small pieces of a brand’s design system that are likely to be used again and again, like the font on a button. They’re easier to see than imagine:
So long as it’s interesting in some way, demo it. It’s OK to show a small unit of work. This works well if it’s something people have been asking for. It shows you listen and sweat the details.
But, if you don’t have at least 15 minutes of stuff to show, it’s not worth the time and effort.
For example, code refactoring is important work, but doesn’t make a good demo. Neither do things you’ve built and thrown away. Unless they contribute to a broader narrative, nobody cares. Gauge demo-worthiness by interestingness, not value.
When to demo
Share things as soon as possible to get feedback early. Constructive feedback is like sunblock: better sooner than later.
Demo frequently. If a project is likely to run for a few months, weekly is great. On longer projects, we tend to demo every few weeks.
It’s OK to leave longer gaps over summer and winter festivities when people are less likely to be around, or as engaged. Trust your instincts around the organisation’s working culture.
Who to demo to
Invite everyone who may have interest in your project, however tangential. Prompt attendees to let other people know.
In a big organisation, you won’t know everyone with a vested interest. Casting the net wide at the early stages gives you the best chance of winning hearts and minds, and can prevent friction later on.
If you build a regular audience, you build a positive culture around your demo series. That’s good for visibility and trust.
Who should present
Try not to demo alone. Bring at least one pal. Wrap your demo inside a short presentation with a slide deck. This will help you figure out who does what and when.
The deck should tee up the demo, set context, and invite questions and feedback at the end. A non-demoing team member can do these bits.
Have a person who helped design or build the thing do the actual demo. They’re best placed to show the detail, explain the rationale of your approach, and field questions.
At any one time, the person presenting should focus only on that. The other person can assume a support role. They can note any questions in chat, keep an eye on time, and deal with any issues that come up, technical or human.
It can be helpful to invite experts who aren’t part of your team. They can field broader questions about your project’s place in the organisation. You might invite engineers or brand people if your work has a bearing on their strategies.
Designing your deck
Your slide deck should introduce and set the context of your demo. It should explain:
- What you’re demoing
- Its purpose
- Goals it contributes towards (this is persuasive and powerful)
- Why it’s relevant to the audience
Our decks also have slides that:
- Show the agenda
- Link to previous demo decks
- Signpost the start of the demo
- Signal changes in speaker
- Show a roadmap of what’s next
- Prompt audience questions
- Let people know where they can follow progress
You can’t control how your slides will be shared. Simple, concise slides are best, but each slide should have enough context to make sense to people who weren’t there.
Doing presentations has great advice for putting slide decks together. It’s optimised for “big” presentations, but there’s plenty you can apply to demos, including how to make your deck a useful stand-alone resource.
How much to prepare
It’s hard to know how much to prepare. A demo isn’t a high-pressure presentation like a sales pitch to a new client. But it does need to be clear and concise, so take as much time as you need to do that.
New teams and projects will mean more prep time, but it does get easier and faster. We can take a day or two to prepare to demo a new project. But we can get this down to a few hours as we find our groove.
Do a dry run
Do at least one practice run with everyone involved. If possible, invite a few people you trust to be the audience. Ask for frank feedback about what worked and what didn’t.
Get a feel for how long it will take and find ways to make it shorter. Cut flab. If you’re clocking in at over an hour, it’s too long. Make it as short as it can be but as long as it needs to be.
Have a contingency in case technology fails on the day. If you’re demoing live software, you’d ideally have backup screenshots or a pre-recorded screen capture if you have time.
The practical stuff
There are always practical considerations. A tricky one is cameras on vs. cameras off. As presenters, you should have cameras on.
If your work culture encourages it, you may like to suggest everyone attending has their camera on too. It’s easier to communicate, field questions, get feedback and gauge the vibe. But if the culture welcomes cameras off, do respect that.
You should also:
- Present from a quiet location
- Present from a well-lit location (but avoid having bright light directly behind that makes you hard to see)
- Use the best camera and microphone you have
- Avoid emphatically banging your desk (which wobbles your camera)
We choose to avoid blurring our backgrounds on calls when possible. That’s an aesthetic choice, and we know there are good reasons for people to mask their background. Do what’s best for you.
Doing the demo
Everyone presenting should join the call 10 minutes before start-time. If you’re demoing alone, ask a friend to join early. Test everything, including microphones, cameras and screen-shares.
If you’re using Microsoft Teams, it will announce to everyone that the meeting has started. You might like to drop a “no need to join yet” message into a channel.
Unless policy prevents, record the demo so people can catch up. If you’re presenting to a new organisation, check that this is OK. You may prefer not to record if the topic is sensitive. If you are recording, let everyone on the call know before you push the button.
The rest comes down to how you present and communicate. There’s a world of considerations to developing these skills. A few things we’d highlight:
- Pace is important — not too fast, not too slow
- You’ll improve with practice (demos are a reasonably low-jeopardy way of developing presenting skills)
- Doing presentations has great tips on the performance side of presenting
Fielding questions
Encourage questions, but on your terms. Decide in advance whether to allow them during the demo, or save them till the end. You may prefer to do them last if you’re presenting to:
- A new, unknown group
- A large group
- People you know may derail the demo (in a well-intended sort of way, of course)
Sticky wickets
It’s OK to pivot to questions at the end if things get tricky.
A big risk is someone senior dominating with questions and feedback, or talking over your demo. If that person is an important stakeholder, you might decide to accept this. The important criterion is their role in your project, not their seniority.
If it’s not an important stakeholder, it’s best to politely but firmly insist on questions at the end. This will help your demo go smoothly, which is foremost a benefit to your audience.
An important skill to develop is being chill in the face of conflict. No one wants conflict, but it does happen. Being the unflappable person in the room will only build trust. That doesn’t mean having all the answers, but it does mean thinking before responding rather than reacting.
It helps to have your project spiel down pat. If questioned, be ready to articulate what you’re doing and why. These questions could come up when unfamiliar project teams and leads come along.
Duck into chat
You can prompt people to drop questions in chat. This can be distracting, but may be less so than letting chat go un-moderated. If you’re not presenting in that moment, reply to questions in the chat.
If someone voices a question when they shouldn’t, support the presenter by policing the situation. It will help them keep the thread.
At close of play
Leave at least 10 minutes for questions at the end. Less than that isn’t enough, and sends the message you’re not interested in feedback.
Let everyone know follow-up questions are welcome and where to put them. It’s good if this is in an open channel, so everyone can benefit.
Following up like a pro
Put your helpful hat on as soon as the demo’s over. Copy-paste the chat history somewhere safe so you can follow up on unanswered questions, or ones you can now answer more fully. It’s a nice touch to re-share contributions and links shared by attendees too.
Share the slide decks with everyone straight after the demo — and not only with people who attended. Check your speaker notes first. Some may not be useful. Some may cause embarrassment.
If you have time, review the recording to check that spoken questions were answered well. You might like to re-share the spoken questions and answers in text format. Share the recording too.
Track follow-up conversations in chat and field any new questions that come up.
If your demo was one in a series, ask attendees to let other people know about future demos.
Not following up properly can undo effort you’ve put into demoing well. It shows you value people’s time, and their right to be informed.
It gets easier
There’s a lot to think about, but demos don’t have to be scary. If we’ve given the impression that demos take a lot of time, it’s because they probably will for the first few goes.
But it gets easier. With practice, you’ll hone skills, processes and tools. When there’s a hitch, remember that people probably won’t notice, and almost certainly won’t care. People are kind, patient and understanding.
Try to have fun. You won’t get everything right in the early stages. Every hitch is a chance to do it better next time.
Top comments (0)