In a previous post I wrote about the benefits of having various team members run demos. Now let’s talk about making these demos really smooth. The point is to identify concrete steps you can take before a demo to avoid common issues and build up your confidence. We’ve all done or seen demos where people are late, VC doesn’t work or application breaks. Most of these issues are completely avoidable if only you prepare in advance.
I want to focus on the preparation, not so much on “becoming a good speaker”. There’s plenty of resources that can help you learn about crafting compelling stories and on-stage behaviour. For instance you could look at how TED conferences are run (try HBR article “How to give a killer presentation” or TEDx instructional site on speaker preparation).
Demos are relatively easy to get right in terms of basic content, but they can be hard to get right in terms of smooth delivery. After all we don’t usually have a finished product, just a prototype on a test environment. Of course, your Product Owner may not expect a fantastic story or a bulletproof delivery – we’re not artists, and this is a demo, not a product launch! But why not get better at it and make yourself and your team look good?
- You’ve got something to show (the sprint wasn’t a total failure)
- You know some of the people in the audience personally so you can easily ask them for help on the Client site if you’re not there personally (e.g. get them to show up early and test the video connection)
- You have time to do a dry run (if you don’t, it may be worth mentioning to the audience that you had to compromise and not everything is going to be super smooth this time)
- “It’s a performance. This demo reflects on the team. I don’t want to blow it by lack of preparation.”
- “Dry runs are easily dismissed as not necessary. I won’t skip them. I want to speak intelligently about what the team has built and I want to know what can go wrong during the demo ahead of time.”
- “The audience is probably not familiar with details of what we’re doing here. I’ll give them lots of context.”
- “It can be stressful. I’ll have backup resources available in case things go wrong.”
Preparations before the demo day
DECIDE WHAT TO SHOW (content of the Presentation)
I assume you have something to show, typically a product increment after a sprint. Generally, you have two options. Either show the complete product as it stands today (mentioning what was done recently if you like), or only show what’s new, i.e. the difference between what you have shown on the last demo and what you have just finished.
If you have a new audience, or it’s the last demo in the project, I suggest showing everything.
If you meet with the same people every few weeks, don’t waste their time and just say what’s new.
Ask the Product Owner or Project Manager on the other side who should be invited. The point is to invite the right people – decision makers, subject matter experts, anyone who feels responsible for the progress of your project.
Who you invite should match the features you are showing. This is a bit of a chicken and egg problem. If you are unsure who to invite and what to show, ask the PM or BA, they should be able to suggest some names.
If possible, include supportive people on Client side. They can help you “defend” if someone else in the audience has negative attitude.
Make sure you know the focus of each person in the room (not always possible, but definitely worth it). What’s their area of expertise? Is there anything they already asked about in the past? What could interest them? What question can you ask them during the demo that could help you or them? Someone from Marketing team will focus on different aspects than IT Project Manager.
If you are especially proud of current product increment or even the whole project, invite as many people as you can, and have the audience as varied as possible (don’t stop on IT; get other departments in as well).
Give people time to respond to the invite. Don’t invite them for the next day. In a typical organisation people are busy and may be unhappy that you didn’t really give them a chance to participate. Often times we tend to think “it’s a demo for them, why won’t they come? It’s just half an hour”. This isn’t fair. The complexity of many workplaces and the way people manage their calendars makes it hard to respond to such invites. A week in advance is a good thing to aim for.
Invite your own team if this isn’t standard procedure.
Optionally, invite a few people from outside of the project if you are confident in your progress. Give them a brief intro if they aren’t unfamiliar with it, and explain why you’d like them there: to get feedback, to share your progress, or just to have them invite you back later if they like it. Too often we stay in our projects and forget that there are many other projects around us. It’s useful to actually see the demo from another project, see what other people are working on, what issues they are having, what kind of tech they are working with, how clients respond to our work.
DECIDE HOW FANCY THE DEMO SHOULD BE
Don’t over do it. Sometimes it’s enough to show up, log in to the application you are building and say a few words. Decide based on your project’s nature, audience, and typical level of formality you experience in meetings with the Client.
The better you want the demo to look, the more preparation you’ll need to put into it.
If you want it to be a quick informal chat with just the Product Owner and you know them very well, you can easily skip 80% of this checklist.
For the remainder of this blog post I’m assuming you want the demo to be very nice.
BOOK THE ROOMS
Duration: If you need an hour for the demo and it’s supposed to start at, say, 2:00 PM, it would be a mistake to book the room from 2 to 3 PM. What you want is to book it from 1 PM to 3:15 PM, or longer depending on how things usually go with your audience. Why?
You will spend the additional hour on: kicking other people out of the room, testing the equipment, and doing a dry run of the whole demo.
Have backup time for overruns booked on the other side as well.
Ask a trusted person on the Client side to book an appropriate room with a VC equipment. Test the connection.
Write A Script
Some of us can talk eloquently without preparation, but it’s really hard. Make it easy for yourself by preparing a script. You will get consistent good results if you plan your content and put it down on paper.
Below you’ll find an example demo script. It’s a short one, loosely based on one of my own scripts from last year. Notice there are plenty of hints what to ask and say, not just things related to the application itself.
- Ask Mary and Gary what they expect from the demo – is there something in particular they would like to look at or see?
- Explain that it’s a test environment, and how instability of environments has made things harder recently and how it may affect the demo.
- Open: http://localhost:123/demo/app/
- Login as: DEMOUSER / DEMOUSER
- Explain menu and header.
- Find by ID: 18175 – explain the bug we have when multiple entities with same ID exist
- Find by name: Horace Smith
- Complex query example: 2765 Emma -London
- Account detail view:
- Explain popup content: name, linked accounts, data freshness.
- Mention we are still having a UI design discussion.
- Ask for feedback:
- Find out what they think about data freshness and complex queries.
Dry run is key. Here’s what it allows you to do:
- Practice what you say – so your words are clear to the audience, and you don’t stutter too much. The more you get stressed when speaking foreign language in front of others, the more this practice should be useful, but even if you’re using your native tongue it will help.
- Discover technical issues – it’s the last moment to test that correct data is available, demo environment is working properly, you can actually log into the application without issues etc.
- Time the delivery – if you have booked a 30 minute call but you talk for 45 minutes you won’t show what you need to show and there won’t be time for questions.
- Adjust demo script – based on time it took you to walk through it all and discovered issues (e.g. you need to open different items in the UI than you thought because).
What should happen during a dry run?
- put the script in front of you
- imagine the Client is in the meeting with you
- speak as if you were actually doing the demo – don’t whisper, speak out loud
- if you find an error in the application or a problem with the script, fix it, fix the script, take a step back and talk through that point again
I recommend doing a dry run a day or two before the demo. This should let you talk to your team and fix any issues you discover. You could also do a dry run on the demo day, especially if the stakes aren’t high, but that gives you less time to adapt.
Prepare the equipment. Test VC connection. Connect your presentation device and either do a full dry run or at least log into the app / go through the first few steps of the demo.
Ask someone from your team to fetch everyone.
The moment people walk in the room you should have all the equipment ready. This saves everybody’s time (except yours! But you have to do this anyway; they really don’t need to watch you connect the cables, log into laptop, into the app etc.)
If you want, ask someone to be the facilitator: ask them to give some background and/or take notes if necessary. You focus on talking about the product increment.
GIVE the demo
Introduce yourself if you’re new to some people in the audience.
Talk about the system from the user’s or audience’s perspective; be mindful of the difference between the two.
Give lots of context.
Example: imagine showing a new feature you just added. You should aim to explain all of the following to the audience:
- who you are impersonating
- what is the aim of that user
- what they do just before attempting to use the new feature and why
- what steps they take in the application (show)
- what then happens then inside and outside of the system
- delivery status
“Let’s say I’m the chief engineer in Your Company Ltd. It’s the beginning of the day and I need to review the status of my team’s delivery. I log into the system as usual. [show] That opens the dashboard, which you can see right now. [show] So this is kind of a landing page for the engineer.
Each table represents one of the teams, and it shows the list of all my people and their current top tasks, as well as status of these tasks. [highlight an example item] So here’s Main Team, a person called Steve, his task “Sign off platform design” is green, that means it’s on track to be delivered today [show]. If I see a lot of green, I know things are going well and I can skip the review for now and do other things. If something is shown in red this is where I need to focus, so I click an item’s title to get details. [show]
This feature was built in the sprint we just finished. It uses fake data for now, and we’ll be pulling real data from external systems in the upcoming sprints.
Before we go into detail view, do you have any questions about this?”
If there are any issues which need highlighting, mention them but don’t go into detail. Example: “We are still working on making this fast on mobile phones. Desktop version should be very fast already.”
At the end of your part, ask the audience if they have any questions. After Q&A is over, thank everyone.
After the demo
Discuss feedback with the team, decide what to do with each comment or suggestion – should it be a new User Story? A bug? Something to discuss with someone else?
If you’ve gotten no feedback whatsoever, try emailing the Client in an informal tone. “What were your thoughts after the demo? What did other people say? What do you think about the feature we showed?”
Running a smooth demo is mostly a matter of preparation. I hope this checklist will help you avoid common issues.
If you have your own tips & tricks that improve your demos, share them in comments below, I’d love to hear them!