How To Run A Demo

Here's a blueprint to running an effective demo call

We all know we need to run a great demo in order to get a deal to close.

But nobody goes to “founder school” to learn how to demo well.

Just because you created the tech, and you know everything about it, doesn’t mean you know how to demo well.

Let’s dive into how to run an effective demo call.

QUICK ANNOUNCEMENT: Group coaching is filling up. 1 seat left for May group (starting May 9). Let me know if you’re interested.

June group is getting formed as well. Still a few seats left there.

Table of Contents

Quick Notes:

  • The demo is about them, NOT YOU. Remember this. You are showing THEM how to solve THEIR problems. You need to bring your tech into their world. If you’re showing them what you think is cool or useful, then the demo is about you. You’ll need to rewrite your script.

  • DON’T show everything. Your job in sales is to understand and solve their pains. You do not need to show every detail and every feature if it’s not relevant to them. You’ll likely cause more confusion this way.

  • Start at the end, then work your way towards how to achieve the end state.

  • Make them imagine using your software in their business.

  • A demo is not a walkthrough or a training call. This is where I see most founders fail in their demo. They’re teaching the prospect how to use the software instead of showing how the software solves their problem. A demo is structured. Think of the demo as a movie trailer designed to get bums in seats. You’re not showing the whole movie - or even worse - how the movie was made.

How to Structure your Demo

Think of your demo as chapters. Each chapter focuses on a specific pain, and you show a series of workflows that solve that pain.

Often start with the end - show them the city, then the different parts of the city. This might be a fully populated analytics dashboard. In my case at Savio, it’s the fully populated feature request list filtered by most revenue. This creates a talking point around what they’re really trying to solve with a better feature request workflow - prioritizing requests based on data not gut.

Then we work our way towards the end. So we show how to collect the data. How to triage the feedback. How to attach it to features. How to close the loop once a feature is shipped. And then we return to the feature request list.

Each chapter, in our case 3-4 depending if closing the loop is important, focuses on a specific pain and workflow. This makes it easier to really highlight the value of what these workflows are bringing to the prospect.

Make sure you break in between each chapter to ask thought provoking questions. The outcome you want from a demo is making them imagine using your software in their business, so create questions that makes them do this.

Setting Context for your Demo

A great place to really highlight your sales pitch and set you apart is right before you demo.

Give a high-level about your point of view. What insight can you share about the market? What problems do you solve? What are the voids for your prospects? What makes you different?

This helps you position your product strongly right before you show features. They’ll remember this positioning throughout.

Example Demo Chapters

Here are a couple example demo chapters.

Savio is a feature management software that helps product teams collect feedback from disparate sources, organize it in feature requests, then prioritize based on commercial viability.

LevelJump (acquired by Salesforce in 2021) was a sales enablement software that helped sales leaders onboard new sales reps faster.

How to Run The Call

Prepare for your demo by reviewing your previous calls, and making notes of the top pains and impact you’ve diagnosed. This should already be filled out in your FOUNDER methodology notes in your CRM.

For bonding and rapport, bring up anything new you’ve noticed from the prospect, or engage new stakeholders as they come in. Have 1-3 points ready for everyone that will be in the meeting, so you can immediately create bonding and rapport no matter who joins the call first. You can check out LinkedIn for this info.

Once you’re past the bonding and rapport, kickoff the structure of the call.

  • Time check (make sure they’ll be there the whole time)

  • People check (make sure everyone who’s planning to join are there)

  • Purpose of the call

  • Their ideal outcome at the end of the call

  • Ask permission to discuss next steps

Once you’re done with your kickoff, summarize the Facts, Objectives and Pains obtained during your diagnosis. You can create a slide for this if you prefer.

Share a story, or context setting, for what they’re about to see. You can use 1-3 slides for this if you prefer. I would make sure you present your demo in chapters, and let them know what chapters they’re about to cover.

When you switch to your demo, do a quick overview of the layout so they know what they’re looking at, and don’t have to wonder. Without this, they’ll be looking everywhere when you’re trying to explain how you’ll solve their pain. They’ll miss your point.

Try setting up a tab-based demo in which every tab of your browser acts as a “slide.” Avoid clicking places where it will refresh or load a new page. This makes for a clunky demo, which will make it look like the client experience is poor.

Compartmentalize each section by making one point at a time, no more than 3-5 minutes each. Start each section by explaining what problem you’re solving, then say “Let me show you how…”

Demo 1 should show how to solve the biggest pain point you’ve identified. Try to show usage, so they can see how we’ll solve their pain.

Q: At the end of each point, ask an engaging question that makes them think or puts them inside the situation. Good examples are:

How would you use this?

What impact would this have on your business?

How does this compare to how you’re doing X today?

This will keep them engaged. If you take too long to get through your demo, and don’t have them participate with an engaging question, then they will lose interest, start doing email, and only emerge for the recap.

Demo 2 should show the second biggest pain point you’ve identified.

Demo 3 should show the third biggest pain point you’ve identified, or should show them a “delighter” they haven’t even thought of. Sometimes this is referred to as demo candy :) Make sure the demo candy is relevant to their situation, or it won’t resonate.

Once you’re done showing the demo (20-30 minute conversation, maximum!!! You need time for other stuff), recap the points you’ve made earlier in the call, then move on to the close.

Here’s an example:

At the start of the call, we set out to solve problem 1 by demo 1, problem 2 by demo 2, problem 3 by demo 3. I believe we accomplished that. [[SILENCE!!! Let them respond yes or no]]

So, are you ready to get started?

The answers you’ll get here will open up further discovery around the decision process, decision criteria, financial process, legal process, cast of characters, and timelines.

Make sure you leave enough time in your demo to have this thorough conversation, or you’ll be chasing next steps.

Next step, in most cases, should be proposal review. They might need more education, which is OK, but try to make it a “if we do this, can we review a proposal?” exchange.

Book the proposal review call.

Here’s a visual that displays the progression of a demo call:

I’d love to hear from you! Hit reply and let me know what other topics you’d like to learn about.

For more practical early-stage sales tips, connect with me on LinkedIn.

Buy the FOUNDER Operating System ebook here (special discount code 30OFFMAIL to get 30% off)

If you’re looking for more hands-on help implementing your first sales process, reach out for coaching packages.

P.S. I just launched new coaching packages including group coaching.

P.P.S. **COMING SOON** The only upskilling community specifically for founder-led sales. Let me know if you want more details.