work

Giving Great (Remote) Software Demos

Giving great software demos is both science and art. Here are some tips on making the most out of every demo opportunity, even when you're stuck at home!

Published on 15 Jun 2020

❤️ 18 Likes 🔁 4 Reposts

Introduction

I've been in technical pre-sales for about ten years, and software demos have been a part of my role since day one. I'm still working on perfecting my demos, but I do have some tips on getting the best results from the short time you have with your clients.

Key takeaways for those in a hurry:

demo to the people in the meeting
no demo should be the same as another
start with the "aha!" moment and work back
only show the features that matter to the customer
always prepare for a strong five minute open and close

Technical sales / solution engineering / pre-sales is (in my humble opinion) one of the best roles you can have in tech. It combines technical skill, creativity and sales skills and is critical to the success of complex software sales.

Demonstrating software is one of the most fun and high-impact tasks for a pre-sales engineer. You have the opportunity to use your expertize and experience to deliver a powerful, customized demo which could be the difference between a sale and a lost opportunity!

It is easy in life to settle into routines, and we are all guilty of giving the same demo a few times. Spending a little time to think more about your customer and your demo can result in a more engaging, more enjoyable and more successful meeting. In the following sections we will walk through some key steps to help achieve this.

Preparing for the Demo

No matter what demo you're giving, preparation is key to success. Some of this can feel a bit nosey or intrusive, just remember that the goal is to give you background information which can help direct the demo.

Know the Customer

Your sales representative will have done some work here already, but there are a few steps that you should take as a pre-sales engineer, and it only takes a few minutes to get a feel for the company:

Do they have a tech blog? Take a look at what they've been publishing lately.
Are they a public company? Take a look at the CEO's message in the latest annual report.
What is the output of their marketing? Take a look at Twitter & LinkedIn to see what they are talking about.

Know the Audience

Note that this is separate from knowing the customer, this is about getting to know the individuals you will be working with. You should have a meeting agenda with the email addresses of all attendees, hopefully at least a few days before the demo! Book half an hour in your diary before the meeting to do some research on Twitter, LinkedIn, blogs etc.

Researching the attendees is not meant to be creepy, and it is unlikely that you would (or should) use anything that you learn explicitly in the call. Understanding the background of the attendees will help you spot opportunities, focus the demo and prepare for obvious objections.

Know the Technology

This entirely depends on the solution that you are demoing, but it is important to know the technology in place. If your solution is web-based, use a tool like BuiltWith to see what is being used already. This allows you to prepare for objections, technical complications and good synergies with other products.

You will need to do a bit more preparation if you are in a competitive position with an incumbent supplier. Make sure you know who you are competing with and your relevant strengths and weaknesses. Be prepared to handle objections based on the competitive solution(s).

Know your Demo

There are three software demos you are likely to give, in order of the maturity of the opportunity:

The Qualification - "Ooh shiny!"

The Confirmation - "This solves all of my problems!"

The Proof - "Now I've seen it with my own data, here's my credit card!"

It is important to be mindful of which stage the customer audience is at, and give the correct demo accordingly. Are you giving the same demo for all three stages? No worries, most of us do. Differentiating between these, even it's only the first few screens that change, can turn a low-engagement demo into an "I can spare another thirty minutes for this, please carry on" demo. You could be months into an engagement with many demos delivered, but it's likely that you need to give a qualification demo if you have to present to someone new to the company or the solution.

Whatever the demo, ensure that you follow tell-show-tell for each feature you include:

Tell them what you're going to show them and what problem it solves
Show them how your solution solves their problem
Tell them what you showed them!

The Qualification Demo

You have two goals in the qualification demo:

Create enough interest in the customer to progress to a proof of concept (or close the deal, if you're lucky!)
Qualify that your software actually meets the customer's requirements

We often forget the second point in our enthusiasm for our solutions. Both sides should be evaluating whether this is a good fit, just like in a job interview.

It is tempting to jump straight into talking about you: your company, your product. It is critical to understand the customer's pain before showing any software screens at all. Push back if you have been invited to a meeting by a salesperson without any qualification or background, your management and leadership should definitely support you here. It is the salesperson's job to qualify opportunities and share that information with you.

It is quite likely that at some point you will find yourself in a meeting with a new customer without any background information. This is not your fault, and can be recovered: start the meeting with questions. This is actually an opportunity to build a trusted advisor role earlier in the relationship than normal, although obviously not ideal overall. Stick to open questions about their business, with a leaning towards the problems that your software solves:

"How do you solve challenge X at the moment?"
"How successful do you feel that is?"
"How important is X to the business?"
"If you could change anything about X, what would it be?"

In fact, do this even if you do have a good qualification document from the salesperson. Why wouldn't you ask these questions, two heads are better than one and there's a good chance that the answers you receive may give you more information. These questions have three effects on the rest of the meeting:

It demonstrates that you care about the customer
It gives the customer an opportunity to discuss their challenges with a technical advisor
It helps to build rapport and establish two-way communication

All of this helps to avoid the dreaded radio broadcast demo, where the customer sits in near-silence for an hour or more. This can happen remote or in-person, and is awkward for both sides!

Once you have built rapport and understood or confirmed the qualification, it's time to demo! Remember the goals for a qualification demo are two-fold: show the customer that it solves their problem, and qualify your software does actually solve their problem.

Think back to your last qualification demo where the customer had an "aha!" moment. What was the first screen of your software you showed? Now think to the "aha!" moment, what screen were you showing then?

We often have a number of linear demo flows we follow, building "bridges" from customer challenge to software solution. In fact, the cover for the (very good) pre-sales book Demonstrating to Win! is a bridge!

Whilst this is great in a software training session or a late stage demo, it can be cumbersome in the qualification demo. Remember the screen from the "aha!" moment? What was it showing? Show that first. Use this as the conversation starter, and build a flow from here to key features based on the feedback from the audience. It can feel awkward at first, but try giving a five minute walk-through of a single screen, no clicking around! Once you have talked through this screen, confirm that the customer understands what you've shown them and ask if they have any questions. Leave the silence to hang for 20 - 30s, this allows people time to think and un-mute. It's important to get feedback at this point, if no-one asks any questions, turn it back on the audience and ask a leading question to a friendly in the audience by name. For example, you might ask "Jane, is this what you were expecting to see? What do you think would be most important to see next?"

During the demo, take note of where the audience appears most engaged or asks the most questions. This will help to build your closing summary, and should help you build your business case.

The Confirmation Demo

The confirmation demo may be combined with the qualification demo, depending on the complexity of your software and the maturity of the opportunity.

Think about your goals for a confirmation demo. If you offer free trials or proofs of concept, the goal of this demo is to skip the free trial. If you can sell your software without a trial you will save time, cost and Salesforce administration! Other CRMs are available 🙂

I would expect an opportunity to be in a reasonably mature stage by the time you are preparing a confirmation demo. This means that this demo should prove to the customer that you know what they need, and that your software solves those requirements. This means that you should be investing the majority of your time on this demo, and you should have the following prepared:

Attendees and roles for the demo
Personal needs for each attendee
A list of key requirements (perhaps from an RFP or procurement)
The name of the decision maker

This is a lot of information, and a lot of work to prepare. The majority of this should be provided by your sales representative, but you can (and should) reach out to folks who will be on the demo to ask them questions about what they would like to see, what problems they hope that you can solve and what their role is in the purchasing decision.

A demo flow comes quite naturally once you have this information prepared. Don't start your demo with a demo, but a summary of this information. For example you might say:

Thank you everyone for speaking with me over the past few days. It seems to me that the critical requirement is xxx, that the selected solution should also provide yyy. Does that sound right?

Then let the silence hang for 10 - 20 seconds. It will feel uncomfortable, but it is really important to get confirmation at this point. You will also find out who is your 'friendly' from the customer at this point, make a mental note of their first name and use it once or twice in the demo to ask for confirmation. This makes you part of the team, and helps to break down the sales / prospect barrier.

Once you have confirmation of the requirements, now we can show a single screenshot / screen of the solution. It might be worth preparing a few, in case your assumptions above are wrong, but the key is to have a single screenshot which showcases your solution solving the critical requirement.

Talk through this screenshot and discuss how it solves their requirement. Once you are satisfied that you have spoken to their requirement, ask them for confirmation. If they agree, ask them what else they would like to see. Once you have noted everything that the audience mentions, quickly build a demo flow based on their requirements. Then for each requirement, take the shortest possible route in your software to show how you solve the requirement. If your software requirement cannot solve a requirement, start with a very brief objection handling statement to qualify the requirement:

"I hadn't heard that requirement before, is that something we need to cover off now or can we take it offline?"

Once you have gone through a requirement, confirm with the requestor that you have satisfied them. Asking this question can come off as combative, especially if it is phrased such as "Does that answer your question" or "Is that what you wanted to see". It is possible to take the edge off the question by adding humility:

"I hope that answers your question", "it seems to me that should meet your requirements, would you agree".

The Proof

This is my favorite demo. It's normally the culmination of weeks or months of work, has lots of pressure and lots of attendees! It is your opportunity to show off how great your solution is, and how well you can meet the customer's requirements.

By this time in the sales process, you should know exactly what the customer needs to see in order to confirm that your solution is the right fit for their challenges, it makes sense then that your demo shows these features and nothing else. If you only need to show 10% of your features to show the deal, only show those 10% of features! There is strength in simplicity, and value in closing a meeting early if you can.

While I suggest that you should keep the demo as short as possible, it is critical to make sure that the customer knows what they're about to see and how it solves their problem. People have bad memory, so you'll also need to recap it at the end. A good structure for this demo might look like:

Introductions
- Include the names and roles of everyone in the meeting. If you don't know someone, politely ask who they are and what their interest is in the solution: "Hi Joe Blogs, I don't believe we have met before? What would you like to see in today's demo?"
Background of all of the customer's relevant challenges
- Specific challenges
- Solution requirements
- Potential value of solving the challenges
Challenge 1
- More background of the customer's challenge ("you told me that...")
- Specific capabilities of your solution which would solve this challenge
- Value of solving the challenge (hours saved, $ gained, insight provided)
- Shortest path to demo the capability
- Confirmation - "would you agree that this solves your challenge?"
Challenge 2, 3, 4...
Summary
- Confirmation of challenges - "we heard from you that..."
- Confirmation of solutions - "we have you shown that..."
- Confirmation of understanding - "is there anything I have missed or could make more clear?"
- Confirmation of intent - "based on this information, it seems that our solution meets your requirements"

I've seen a lot of these demos start with a few slides about the pitching company's history, position in the market, how amazing they are etc. Why? This meeting is about your customer, not you. Leave that out, or have some slides in your pocket in case you are challenged on your ability to deliver. Otherwise, keep everything in the demo about your customer.

Pitfalls

With a customer-driven demo, there are a few pitfalls to avoid. It becomes much easier to handle these once you know how to recognize them.

The rabbit hole

The rabbit hole is when we spend a disproportionate amount of time on a small feature of the solution or customer challenge. This can come from either the demonstrator or the customer, more commonly from a confused or belligerent customer. It's also possible if you have a favorite or 'safe' feature which you are comfortable spending time in, or if you have a particular affinity for a specific feature.

The escape route is relatively simple, once you have identified that you're in the rabbit hole. If you need to leave a feature, just ask a closed leading question of the audience: "I'm conscious that we have a limited amount of time to cover a lot of requirements, is it ok if we move on and come back if we have time at the end?".

The drunkards walk

Often a symptom of a lack of information before a demo, the drunkards walk is a seemingly random jump from feature to feature. This will end up confusing the customer and making your solution seem more complex than it is.

When giving the demo, don't be tempted away from a feature until you have given a summary. If a customer asks about something that will take you away from your current flow, take a note and let the customer know you'll get to it:

"Great question! That is covered in another part of the solution, I've taken a note to cover that when we get to it. Please remind me if I miss it out!"

The harbour tour

"This is what you've been training for!" you think as you prepare your demo, a checklist of the full feature set of your software ready in front of you.

It is incredibly tempting to try to show every single feature of your product in a demo. The logic is pretty solid: if you show every feature then the customer will understand how powerful the solution is! Unfortunately it doesn't work out that way, a harbour tour of your software - moving from feature to feature - will likely have the opposite effect. It is often hard to tell a story with your software during the harbour tour, making the transition from one feature to the next jarring for the customer. Demonstrating every feature can also lead to quite a dry demo, and may even give the impression that your solution is overly complex, or does more than the customer could ever need.

The harbour tour is differentiated from the runaway train and the drunkards walk as it is, in most respects, a great demo! The challenge here is knowing when to stop. Remember to focus on the minimum viable demo, what are the key features which will close the deal? Let the customer tell you if you've missed anything that is important to them, rather than throwing everything against the wall and seeing what sticks.

The runaway train

Probably the most common pitfall in technical demos, the runaway train is the well-rehearsed step by step walk-through that has been delivered hundreds of times before, which stops for nothing! This is generally delivered by veterans who have honed their demos over time, or newbies who are following a safe demo path (and likely the product training). A robotic demo routine can be both dull and fragile, customer questions can throw you off your tracks and disrupt your flow for the rest of the demo.

The solution for the runaway train pitfall is simple, let the customer drive the demo! Ask confirmation questions after each feature and get feedback as often as possible. It can be hard to break this pattern, so try practicing with a colleague: ask them to be the customer and 'drive' the demo, then follow their lead. Once you've done this a few times it will feel even more natural than your well-rehearsed demos!

The endless objection

Some customers are just there to make your life difficult! If you have a member of the audience who constantly throws objections (or will not let an objection go) there are two potential solutions.

If the objections are valid and following a theme, you need to address it as soon as you can to prevent it derailing your demo. You can do this by acknowledging the objection and defer the responsibility to another time: "great question, I think it would be best for me to follow up by email with a complete answer. Would that be ok for everyone?". By using the word "everyone" in the confirmation question you put the pressure of the objection back on the person raising it, it is their decision to use everyone's time on this question. It also leaves an opening for someone else on the call to confirm the objection, in that case it really is important to handle it in the demo!

You are likely to be sharing your screen in either remote or in-person demos. Whilst the technology to do this is generally robust, it can open you up to some unnerving possibilities.

Enable Do Not Disturb mode on MacOS from the notification center

In all cases, it makes sense to mute your notifications. On MacOS this is as simple as ⌥ + click on the notification center icon. Windows makes this a little more tricky - you need to head to control panel to disable notifications.

Disable Windows notifications in Notifications Settings

One of the most cringe-inducing moments of a demo is the "can you see my screen?" awkward beginning. Save yourself some time and frustration by getting prepared to make this silky smooth. If the screen sharing software is not your normal software, e.g. if the customer has shared theirs, make sure you practice sharing your screen before the meeting. If you are on MacOS Catalina, you will be familiar with the screen sharing permissions issue. This new permissions setting means that new apps are not allowed to record your screen or audio until you allow them, and allowing it might require restarting the app! You will know how frustrating this is if you've had this happen to you on a call with a customer. Thankfully there are a couple of ways to avoid this nightmare.

The first trick is to avoid the native applications! Almost every video conferencing product supports joining via the web, in order to be compatible with Linux and ChromeOS. They might hide this ability, but if you look hard enough you will find it 🙂 The benefit is that it will inherit your browser's permissions, so you only need to give the permissions once.

The second tip is to proactively give permission. The app you have to download might not ask for permission until you attempt to share your screen, and you might not be able to share your screen until your meeting starts! In MacOS, head to System Preferences -> Security & Privacy -> Privacy -> Screen Recording and enable the app.

Preemptively give apps Screen Recording & Microphone access

Once you are able to share your screen, let's make sure that starting your screen share is as smooth as possible. If you are presenting from a slide deck, make sure you are in presenter mode before you share your screen, this makes it easier to share the correct app or screen and will make the process more smooth.

There are a few methods to avoid the dreaded "can you see my screen?" intro. Most simply, agree with another person on the call (from your company) that they will let you know when they can see your screen, ideally via an internal chat tool that you can see from your phone. A slightly more involved option is to join the meeting twice, once as a presenter and once as an attendee. This way you will see exactly what the customer sees! There are obvious drawbacks here, especially if you have limited bandwidth available, but there's nothing like seeing the customer view to give you confidence about what you are presenting. I do this for very important meetings or webinars with an iPad on my desk, so I can see at a glance what the presentation looks like.

Screen-sharing becomes quite simple with multi-monitor setup. Use your secondary monitor for the demo / presentation and share the whole screen. This means that you can switch between apps without having to re-share them.

If you have to switch between screens or windows, have these staged and ready to go. On MacOS I recommend using multiple desktops - this allows you to easily switch between full screen apps using a three-finger swipe or control + →. On Windows, have your apps lined up in the task switcher so you can quickly move from one to the other.

Sharing your screen becomes a little tricky if you only have one monitor. If you are physically plugging in to a projector or TV - you can avoid this by setting it as a second monitor, not mirrored! If you're presenting remotely you will have to make do with the one monitor you have. A good option is to only share the application you need to. In many cases, you can spend 100% of your time in a browser window. Use a web-based presentation tool (Google Slides or HTML!) and get your tabs set up in the order that you will need them. Use ⌘ + [n] to switch tabs where [n] is the tab index, i.e. ⌘ + 1 will switch to the left-most tab.

If you have to share your whole screen, for example if you need to switch between multiple applications, make sure your workspace is as clear as possible. In MacOS, multiple desktops are your friend here, just make sure your other applications (email, IM etc.) are minimized so you don't accidentally flash them to your customer when you confuse swiping left for swiping right!

High Resolution Displays

If you have a newer laptop or a nice high-definition external monitor, you will likely have a horizontal resolution between 3,000 and 4,000 pixels. While this is great for productivity, it can be a nightmare for screen-sharing. If your customer is showing the display on a 720p projector, or a window on their 1080p display, your monitor will be scaled back significantly. If we take the 720p example, each projected pixel will have to squeeze in nine pixels from your 4k monitor. Ever heard customers say that it's hard to read text from your screen? This could well be why. Sharing at 4k might also consume significant resources on your machine as it tries to compress the information to share it over the internet.

There are three options to resolve this issue. No matter what route you take, it's worth confirming with your customer that they can read the content you are sharing without straining their eyes.

Zoom in! This is the simple option, most apps will respond to ⌘ + + or control + + to zoom in.
Share a window. Instead of sharing your full 4k screen, share an application window which is scaled to a quarter of your display.
Change your monitor resolution. This is something that often happens automatically when you connect to a projector, but not in remote presentations. In MacOS you can change the scaling in display settings, and in Windows you should be able to change the display resolution in Control Panel.

screenshot of macos resolution settings — Adjust your effective resolution in Display preferences

It is quite likely that you will be sharing your browser window at some point in a demo. This can be a bit risky! There are two options to reduce how much information is shared when you share your browser. The first is to have a separate user profile for your demos. Most browsers support multiple profiles which isolate bookmarks, credentials and extensions. The challenge can be making sure you have all of the credentials set up correctly in the demo profile!

It is also a good idea to tidy up your browser before sharing your screen. This can be as simple as making sure your 'new tab' page is a blank page, and hiding your bookmarks and extension bars. You can quickly toggle the bookmark bar in Chrome on MacOS with ⌘ + ⇧ + b. Your extension bar should have a grab handle so you can shrink it. Removing these distractions allows your audience to focus on what you're showing them, and prevents you from revealing anything you shouldn't.

Remove distracting bookmarks and extension icons

Ending a Demo

How you end a demo will influence your customer's impression more than you might expect. A good ending cements the messages you want to convey in the demo and will be remembered more than the other 55 minutes. This is the logic behind tell-show-tell:

Tell them what you're going to show them
Show them
Tell them what you showed them

The demo is only there to confirm the points that you have pitched at the beginning. The end, then, is to summarize those points and confirm understanding with the audience.

A weak ending puts the whole demo at risk, so make sure you are prepared to make it concise and impactful. The following four points should give a good structure to a ~2.5 minute close before the sales representative takes over:

"At the beginning of the call we said..."
"During the demo you have seen how we can solve your challenges..."
"Is there anything else you were hoping to see in this demo?"
"Would you say that this solution solves your challenges?"

Hopefully the customer responds with a yes to the last question! Don't be afraid to wait 10-20s for an answer. If the silence hangs too heavy, you can follow up with an open, leading question to give the customer an opportunity to share any objections:

"it seems like you are not 100% sure that the solution solves your challenges, what have we not shown you today that could get you to 100%?"

This closes the demo with the customer agreeing that they need your solution, rather than you telling them they do. This is subtle but important - there is a subconscious difference between being told that the solution is good, vs. having to make the statement yourself. The worst case scenario with this ending is that the customer tells you what you have to hit first in the follow-up demo 😃

Finally, take stock of any objections and follow-up actions you have noted down. Make sure each has an owner from your side and the customer side, and follow up with this by email shortly after the call.

Having your demo structure written down in front of you, or in speaker notes, is a great way to ease in to a new demo approach. It will become second nature surprisingly quickly.

Handling objections

Often viewed as a challenge, objections are actually great opportunities to learn more about your customer and their challenges. When I say objections here, I mean any question that challenges what you are presenting, for example "can your solution do this?" or "that looks complex to me". There could be a whole book on the subject, but the sections below cover the high-level steps required to handle objections.

1 - Acknowledge the objection

The first thing you should do is to look after the ego of the person who raises the objection. This is often accomplished with a simple acknowledgement, and a statement of empathy:

"Great question!"

2 - Confirm understanding

This step is often skipped, but can really help to clarify the objection. It also gives the audience member an opportunity to take their objection back or even answer it for themselves!

"It sounds like you're asking if..."

3a - Provide the answer

In the most simple of scenarios, the question is easy to answer. In this case it is tempting to skip steps 1 & 2 and give an instant answer, but this misses the opportunity for the customer to answer their own question or, even better, someone else from the audience to answer it for you!

When giving the answer, make sure you directly address the objection:

"The solution provides feature X which directly resolves objection Y. It seems to me that this answers your question, would you agree?"

Asking the customer to agree serves two purposes: confirming that you have actually resolved the objection, and making the customer state that you have resolved the objection.

3b - Defer the answer

You will not have all the answers in all cases. It is perfectly fine to say "I don't know"!. What the customer really wants in this case is for you to have acknowledged and understood the question, and have a route to answering it in the future:

"I don't know the answer to that question, I will take a note and get back to you after the call. Does anyone else know the answer?"

It's important to ask the audience if anyone else can answer the question, ideally someone from the customer side will! This also saves you a bit of work in follow-up.

3c - Admit defeat

This is the most awkward objection, and the one where your response is most important. The question to which you don't have the right answer. This could be missing functionality in your solution, inability to deliver in a certain time-frame or any other negative response.

There are two steps to admitting defeat. The first is to be up-front and confirm the requirement:

"Our product does not do that. Is this a critical requirement for you?"

If they don't really care about it, then you can acknowledge it and move on. If they do care about it, you need to take an action:

"I appreciate that you have a critical requirement for the solution to do X. I will take a note to speak to the product owner and see if it is on the road map"

Make sure that the action is noted down and be sure to follow up after the call.

Wrapping up

In the introduction I said that spending a little time to think more about your customer and your demo can result in a more engaging, more enjoyable and more successful meeting. In this post we have discussed how important it is to invest in preparing for a demo, doing research on the company, the competition and the audience.

We then looked at the three most important demo types: the Qualification, the Confirmation and the Proof. Knowing which demo you need to give is a great way to improve your demos, and will leave your customers feeling more engaged with you and your solution.

Knowing the common pitfalls for demos makes it easier to spot them, and we introduced some simple techniques to overcome these pitfalls. This gives you the power to recover a less than perfect demo early on in the call, and turn it around into the kind of demo that leaves you and the customer feeling great.

Remote presentations require a little more thought and preparation than in-person meetings. We looked at some simple screen-sharing hygiene to make sure you don't spend the first few minutes arranging windows, or get interrupted half-way through by an inappropriate Slack message!

We know how disappointing it is when a movie has a weak ending, the same is true for demos! It is easy to get carried away and run out of time, before you know it you're at two minutes past the end of the meeting and folks are starting to drop off the call. Ensuring that you prepare a few minutes for a strong close will leave a lasting positive impression with the audience.

One of the biggest fears most people have in a demo is the "tough question". The objection handling steps we outlined will help you to buy time, win favor and leave the audience satisfied with your answer. No matter what question they ask!

We've only touched the surface of technical demos in this post, but hopefully there are some useful nuggets here for you. The following section lists some books that I have found particularly beneficial to improving my pre-sales skills, if you want to dig deeper! As a bit of a spoiler: all of these revolve around putting the customer first. Active listening, acknowledgement, mirroring and understanding are all key techniques to build trust. Without trust, it is unlikely that you will be successful.

Giving Great (Remote) Software Demos

Introduction