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 best way to help people understand them quickly and easily, hence: show the thing.
And they’re important to do well. 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 a live demo, we mean one that’s happening now. 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 anything 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 things can be improved. Do away with “demos” that amount to status updates. Status updates are useful, but not interesting. 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, which is beyond pointless.
What to demo
So 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 of these 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. For example, we’ve found showing design tokens as text strings helps make them tangible and easy to understand. 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:
It’s OK to show a small unit of work. It works well if it’s something people have been asking for. It shows you listen and sweat the details. So long as it’s interesting in some way, demo it.
But, if you don’t have at least 15 minutes of stuff to show and talk about, it’s not worth the time and effort—for you or others.
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—and an interesting one—nobody cares. Gauge by interestingness of work, 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, demoing weekly is great. On longer projects, we tend to demo every few weeks. It can be 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 can build a regular audience, you can build a positive culture around your demo series. That’s a good thing for visibility and trust.
Who should present
Try to never 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 wrap-around 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 speaking or presenting should focus only on that. The other person can assume a support role. They can note any questions dropped 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 have slides that:
- Name the thing we’re demoing, with the date
- Show the agenda
- Link to previous demo decks
- Introduce the demo and change in speaker
- Show a roadmap of what’s next
- Prompt audience questions at the right time
- Let people know where they can follow progress
Remember that you can’t control how your slides will be shared. Simple, concise slides are better, but each slide should have enough context to make sense to people who weren’t there.
Doing presentations has great advice for putting together slide decks. It’s optimised for "big" presentations, but there’s plenty of good stuff 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 in the way that a sales pitch to a new client is. 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. In the past, we’ve taken 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 well and what didn’t. Then make any tweaks that are needed.
Get a feel for how long the demo 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 to think about. 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 this to everyone attending. It’s easier to communicate, field question, get feedback and gauge the general 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 lights directly behind that make you hard to see)
- Use the best camera and microphone you have
- Avoid emphatically banging your desk (wobbles your camera)
We choose to avoid blurring our backgrounds on calls when possible. That’s an aesthetic choice, and we know there are very 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-sharing.
If you’re using Microsoft Teams, keep in mind that 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
- Doing presentations has great tips on the performance side of presenting
- You’ll improve with practice (demos are a reasonably low-jeopardy way of developing presenting skills)
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 charming, 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 then 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 distracting 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. But 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. But every hitch is a chance to do it better next time.
Top comments (0)