Lesson 6.1: Running a demo that lands with any audience
Planning a demo is half the job. Learn to read the room, tell the story, handle hard questions and budget the time so the people watching act on what they saw.
By the end of this lesson you will be able to give a demo that changes what people in the room do next. You will learn to read who is in the audience and what each kind of person wants, to tell a short story with the software in it, to answer questions well, including the hard and hostile ones, and to budget the time so that the conversation gets as much as the showing. You will see three demos for three different audiences and use a simulator to check that your plan fits the slot. This lesson opens Module 6, on customer communication. In Lesson 4.4 you learned how to plan work around a regular demo and how to take feedback. This lesson is about the performance itself, the thirty minutes in front of people, and it assumes you have something real to show. No technical background is needed.
A demo can go well in the narrow sense, with software that runs, nothing breaking and the clock respected, and still fail. The audience nods, says "very interesting" and does nothing. Nobody makes a decision, nobody changes their mind and nobody asks the question that would move the project on. A demo lands when people leave with a clearer view, a decision made or a worry settled. That depends less on the software than on how you frame it, who you aim it at and what you do in the conversation.
What landing means
Before you plan a demo, decide what you want to happen afterwards. Write it as a sentence that begins with a person and a verb: "The head of collections approves the extract", "The nurse managers agree to try the screen for two weeks", "The security officer withdraws the objection to the cloud account". If you cannot write such a sentence, you do not yet have a reason for the demo, and you will probably show everything and achieve nothing.
A demo can land in four ways, and it helps to know which you are after.
A decision. Someone with authority says yes: approves a budget, a data extract, a go-live date.
A change of mind. Someone who doubted the project sees something that answers their doubt.
Information. You learn something you could not have learned without showing: the corrections, the missing cases, the way the work is really done.
Commitment. People agree to do something, such as take part in a pilot, supply data or train their team.
Most demos aim at one of these. Choose one, and shape everything around it.
Know the audience
The same software needs a different demo for different people, because each cares about something else. A short list of the common audiences, and what each wants, will serve you in most projects.
The sponsor or executive. They want to know whether it is working, whether it is on track, what it will cost and what they must decide. They have little time and no patience for features. Show the result, in numbers they care about, and make one clear request. Ten minutes is plenty.
The users. They want to know what changes in their day. Will it make their work easier, harder or riskier? Do they have to learn something new? Will it be used to judge them? Show a real task from their own work, in their words, and let them try it. Give them time to react and listen for objections, which are information.
The technical or security team. They want to know how it works, where the data goes, what it connects to and what could go wrong. They will probe. Show the architecture, the access, the logging and the failure handling, and be ready to say "I do not know" and to follow up.
The sceptic. Someone who doubts the project, as in Lesson 2.2. They want to find the weakness. Do not try to avoid it. Show it yourself, early, and say what you are doing about it. A sceptic who sees you name the flaw first often becomes an ally.
A mixed room. Meetings often combine several of these. The rule is to serve the person who decides, and to make sure nobody else leaves feeling ignored. Tell the room at the start: "I will show the main flow for about ten minutes. Then I would like to hear from each of you."
Find out who will come before the meeting. Ask the sponsor, "Who will be there, and what does each person care about most?" The answer shapes the plan, and it shows you who to speak to in the corridor beforehand.
Tell a story, with the software in it
A demo is not a tour of features. It is a short story, and the software is the way the story gets resolved. A story has a person, a problem, a turning point and an ending, and it is the form that people remember.
A simple structure for a demo story looks like this.
The person and the problem. "Meera is a caller. Every morning she has two hundred overdue accounts and no way to tell which will pay without a call."
What happens today. One or two sentences, drawn from the customer's real work.
The turning point. "Here is what she sees tomorrow morning." The screen, the list, the message.
The effect. "The first group is sixty accounts that will probably pay after a reminder. She calls the other hundred and forty."
The question. "Is that the right split for your team?"
Notice what this does. It uses a named person from the customer's world. It uses real numbers. It moves from a problem to a resolution in a few minutes. And it ends with a question, which turns the audience from watching to taking part.
Keep to one flow. It is much better to show one task from start to finish than five features each for a minute. If the audience wants more, they will ask, and the questions will show what they care about.
Say what you are doing in terms of the task, not the system. "Meera opens the list and sees the accounts sorted" is better than "the application queries the database and renders a table". The audience cares about Meera's morning.
Predict first: you have thirty minutes with the head of collections and three of her team leaders. You can show ten features. How many do you show, and how do you decide? Think of your rule before reading on.
Show one flow, perhaps two, chosen by the outcome you want. If you want the head of collections to approve the extract, show what the data lets her do: the sorted list for one team. Leave out the other nine features. They are real, and mentioning them as "there is more, ask me" is enough. The reason is that attention is limited, and every extra feature dilutes the one that matters. A demo that shows everything is remembered as busy. A demo that shows one thing well is remembered as clear.
The story in the example puts a number on the problem and on the change. The chart shows Meera's morning list, split as the demo describes it.
The shape of the time
How you spend the time matters as much as what you show. A common failure is to fill the slot with showing and leave a few minutes at the end for questions. But the questions are where the value is, because they reveal what people actually think. A good rule is to use no more than half the time to show.
A useful shape for a thirty-minute slot:
Two minutes for the frame: the purpose, the stage of the work and what you will ask at the end.
Eight to twelve minutes for the story and the flow.
One minute for what is not done yet.
Fifteen minutes for questions and discussion, with the decision or request at the end.
A small buffer for late starts and technical hiccups.
The simulator at the end of this lesson lets you test your own plan against the slot, with the audience size and the questions you expect.
Taking questions
Questions are the heart of the demo, and answering them well is a skill. A few habits make a large difference.
Listen to the whole question. Many people begin to answer before the person has finished, and answer the question they expected. Wait, then repeat the question in your own words: "You are asking whether this would send a message to someone who paid yesterday?" This checks that you understood, gives the room a moment and gives you time to think.
Answer first, then explain. Begin with the answer in a few words: "Yes, it checks the payment file every night." Then add the detail, if needed. People who wait through a long explanation to hear the answer lose patience.
Say "I do not know yet" when it is true. Then say what you will do: "I do not know. I will find out and tell you by Thursday." This is stronger than a guess. A wrong answer, given confidently, will be remembered. An honest gap, followed by a prompt reply, builds trust. Write down every such promise, and keep it.
Park what does not fit. If a question goes outside the scope or the time, say so politely and write it on a visible list: "That is a good point for the next phase. I have noted it." People see that it was heard, and the meeting stays on track.
Keep answers short. Aim for thirty seconds. If an answer needs more, offer to continue after the meeting.
Check that you answered. Ask, "Does that answer your question?" It often does not, and the follow-up is the real question.
Hard and hostile questions
Some questions are uncomfortable: "Why is this late?", "What if it gets it wrong?", "Why should we trust a system built in three weeks?", "We tried this before and it failed." They are also valuable, because they show what the person fears. A few principles help.
Do not get defensive. A hard question is rarely an attack on you. It usually reflects a worry, often a reasonable one. Treat it as information.
Acknowledge before you answer. "That is a fair concern." A short acknowledgement lowers the temperature and shows you are listening.
Find the fear behind the question. "We tried this before and it failed" may mean "I do not want to be blamed again". Ask: "What went wrong last time?" The answer tells you what to design around.
Answer with facts and a plan. If the concern is that the system might send a wrong message, show the review step and the test results. Do not argue with the fear. Address it.
Admit what is true. If the criticism is right, say so, and say what you will do. Few things disarm a hostile questioner like agreement.
Stay calm in your voice and posture. Slow down. Do not interrupt.
Take it offline if needed. If one person is dominating or the discussion is going in circles, offer a separate conversation: "I would like to understand this properly. Can we speak after the meeting?"
A hostile question can also be a gift in public. When you handle it well, the room sees how you deal with problems, and the person who asked often becomes quieter and more cooperative.
Remote and recorded demos
Many demos now happen on a video call, which changes some things.
Check the setup early. Log in to everything, test the screen share and the sound and close anything on your screen you would not want others to see, such as notifications and unrelated tabs.
Keep it shorter. Attention drifts faster on a call. Aim for a few minutes of showing before you ask a question.
Ask more often. Without the room's cues, you cannot see confusion. Check in: "Is that clear so far?"
Use the chat. Invite people to type questions as you go, and have a colleague watch it.
Name people. "Priya, you work with these accounts every day. Does this match what you see?" It draws in people who would otherwise stay silent.
Have the fallback ready. A recording or screenshots, as in Lesson 4.4, in case the connection fails.
A recorded demo, sent ahead or afterwards, is a useful supplement: people who missed the meeting can watch it, and it lets you show a flow slowly. But it does not replace the live conversation, since the questions are what you came for.
Leave something behind
What people remember a day later is much less than what they saw. A short leave-behind makes the demo last. It should be one page, sent within a few hours: the problem in one line, the key result or picture, the questions that were asked and answered, the decisions made and the next steps with names and dates. It repeats the request you made at the end. A page that people can forward is also how the demo reaches those who were not in the room, which is often where the real decision is made.
Worked example 1: the users' demo
The engineer is showing the lender's reminder prototype to twelve callers and their team leader, the people whose days it will change. The aim is information and commitment: to learn how the work is really done and to get two callers to try it.
The engineer opens with the problem, in a caller's words: "Most of you told me you spend the morning deciding whom to call." Then they show one flow: a caller's list sorted into two groups, with a sample of three accounts. They stop after eight minutes. The first question comes at once: "What if the system puts someone in the easy group and they do not pay?" The engineer repeats it, answers first ("They come back to your list after seven days"), shows the place where it happens and asks whether seven days is right. One caller says five. Another says that some borrowers always pay on the last day of the month, and the system should know. These two comments change the design.
By the end, two callers volunteer to try it. The engineer sends a one-page note with the corrections the same afternoon. The demo landed because it was about the callers' day, because the questions got half the time and because the engineer answered them with attention instead of defence.
Worked example 2: the sceptical security officer
The lender's security officer has said, in an earlier meeting, that she is not comfortable with a vendor engineer having access to customer data. The engineer has twenty minutes with her and a colleague.
Instead of avoiding the concern, the engineer opens with it: "I understand you are worried about access to the data. I would like to show you exactly what the access would be, and where I think the risk still is." The demo is not of the product, but of the controls: the narrow account with read-only access to three tables, masked phone numbers, the log of every access, the plan for ending access and the place where data is stored, inside the lender's own account. The engineer then names two weaknesses unprompted: that the engineer's laptop must be covered by the lender's device rules, and that the message sender needs the full phone number.
She asks sharp questions, and the engineer answers each directly, saying "I do not know" twice, and promising an answer by the next day. At the end she asks for two changes, which the engineer accepts. A week later, the approval arrives. The demo landed because it answered her doubt in her terms, showed the weak points before she found them and kept its promises.
Worked example 3: the executive demo that did not land
The engineer has ten minutes with the group's chief operating officer and prepares a ten-minute demonstration of the bed screen, walking through its features: the colour coding, the filters, the history view and the export. The COO watches politely, asks one question about the colours and says, "Thank you, this looks good. Let me know when it is ready." The meeting ends with nothing decided.
The engineer realises afterwards what went wrong. The COO did not need a tour. They needed to know whether it worked, what it was worth and what was needed from them. The engineer had a result, a median of nine minutes against eighteen to find a bed, and a request, an hour from each hospital's IT lead for the next two hospitals, and said neither.
The second attempt, a week later, takes eight minutes: the problem in one line, a single live view of two hospitals, the measured result, and a plain request. The COO approves on the spot. The software was the same in both meetings. What changed was the aim of the demo and the audience it was built for.
Does your plan fit the slot?
The simplest way to protect the conversation is to check your plan against the clock. The conversation needs time in proportion to the size of the audience: more people means more questions, and each answer takes a minute or two. If you plan fifteen minutes of showing for a slot of thirty and eight people, you will overrun.
The simulator below does the arithmetic. Set the number of people in the room, how many questions each is likely to ask, the minutes an answer takes, the length of the slot and the minutes you plan to show. It shows the time the questions will need, the total time your plan needs, how far it overruns or how much is spare, and the longest demonstration that fits. It plots the total time needed as the audience grows.
The numbers are estimates, and the model is crude, since questions are not evenly spread. But the picture is true: the larger the audience, the less time you have to show, and most plans are too long. The usual fix is to show less.
Try three experiments. First, keep the defaults and read the overrun. Second, cut the planned demonstration time to the longest that fits and see what a realistic plan looks like. Third, set the audience to three and see how much more you can show to a small group.
At the defaults, eight people each asking one and a half questions of two minutes need 24 minutes, and the fourteen minutes of showing brings the total to 38, eight more than a thirty-minute slot allows. The longest demonstration that fits is six minutes. This is why experienced presenters show far less than beginners expect. If the slot is a hard limit, the rest of the content goes in the leave-behind.
Common mistakes
No aim. Decide what should happen afterwards, in a sentence beginning with a person and a verb.
One demo for every audience. Executives, users, technical teams and sceptics want different things.
A tour of features. Tell one short story, with a named person and real numbers, and show one flow.
Showing for the whole slot. Use no more than half the time to show.
Answering a different question. Listen to the whole question, repeat it and answer first.
Guessing. Say "I do not know yet" and promise a reply, then keep the promise.
Defending against hard questions. Acknowledge, find the fear and answer with facts and a plan.
No leave-behind. Send a one-page note within hours, with the request repeated.
Ignoring remote basics. Test the setup, ask more often and have a fallback.
Key takeaways
A demo lands when people leave with a decision made, a doubt settled, information you needed or a commitment. Decide which before you plan.
Know the audience: executives want results and a request, users want to see their day, technical teams want how and where the data goes, and sceptics want the weakness shown.
Tell a short story with a person, a problem, a turning point and a question, and show one flow in the task's terms.
Use no more than half the time to show. The questions are where the value is.
Listen, repeat the question, answer first, say "I do not know yet" when true and keep your promises. Meet hard questions with acknowledgement, facts and a plan.
Leave a one-page note behind, and check your plan against the slot before you start.
Check yourself
1. What are the four ways a demo can land?
A decision, a change of mind, information you learn, or a commitment from the audience.
2. What does an executive want from a demo, and what do users want?
An executive wants the result, whether it is on track and one clear request. Users want to see what changes in their day, using a real task from their own work.
3. Someone asks a question you cannot answer. What do you do?
Say "I do not know yet", say when you will find out and tell them, write it down and keep the promise.
4. With 6 people each asking 1 question of 2 minutes, a 30-minute slot and 12 minutes of showing, how much time is spare?
The questions need 12 minutes, so the plan needs 24, leaving 6 minutes spare.
5. Why name a person and use real numbers in a demo story?
It makes the problem concrete, ties the demo to the audience's own work and makes it more memorable than a list of features.
Try this
This exercise takes about forty minutes and gives you a demo plan for a real audience. Use a project you know, or a tool you use that you could show to a colleague.
1. Write the aim as a sentence beginning with a person and a verb: "The team leader agrees to try it for two weeks."
2. List who will be in the room and what each person cares about most. If you do not know, write who you would ask.
3. Write the story: the person, the problem today, the turning point, the effect and the question you will end on.
4. Choose one flow, and write what you will say in the task's terms, not the system's.
5. Use the simulator to check that your plan fits the slot, and cut the showing to what fits.
6. Write five hard questions the audience might ask, and your short answer to each, including one where you would say "I do not know yet".
7. Give the demo to one real person for ten minutes, then ask what they would do next. Write down whether they did what you hoped.
8. Write the one-page leave-behind.
A good result is a one-sentence aim, a story, one flow, a time plan that fits, five prepared answers and a leave-behind. Having done this once for a colleague, you will give your first customer demo with much more confidence.
Sources
The three demos, the question tally and the simulator's figures are the author's illustrations for teaching, not data from real meetings. The audience types, the story structure, the question-handling habits and the time shape are practical methods written for this lesson, not industry standards.
Tags: Forward Deployed Engineer Customer communication Presenting Demos Beginner