In the grand finale chapter of our 'The many flavors of demos' series, we're taking a closer look at technical demos.
These types of demos are specifically designed to address any technical questions or concerns that your prospects may have about your product or service. Whether you're showcasing a complex product or explaining cutting-edge technology, technical demos can be a powerful tool for gaining your prospect's trust and closing the sale. And that's why involving your sales engineers or technical specialists is a must.
The POC and sandbox come into the picture when your prospect wants (or you want them) to get more hands-on with your product.
Generally speaking, SaaS companies avoid giving prospects direct access to their platform. But with the economy changing and buyers becoming more risk-averse about buying unnecessary or unfit tools, many SaaS sales teams have started offering proof of concept (POC) or sandbox demos as part of their sales processes.
You may argue that a POC or sandbox isn’t a demo, but I’ll respectfully disagree.
When you do a demo, you present your product and its features. And nothing fits that description quite as well as giving your prospects access. Plus, it’s unlikely you’ll give them access without some kind of training or orientation to avoid criticism and objections from the prospects.
First impressions are everything in sales. If your prospects are confused when they first log in and can’t understand how to use your product, they’ll quickly label your product as “complex“ or “not user-friendly.“
The key to creating an effective POC or sandbox, as with most demo flavors, lives in preparation.
What will your prospect's account experience look like after logging in? How much of the product can you configure and set up before your prospect gets access? Can you build and customize workflows and reports according to the prospect so they feel like they are already on your product?
Once you’re ready to give access to the prospect, be prepared to run a demo just like you would do a new prospect.
Tell stories and adopt talk tracks from your “Day in The Life“ or “Orientation“ demos. While you don’t have to go too deep at this stage, you may need to run multiple meetings to adequately cover functionality and help the prospect understand what your product can do for them.
I recommend adopting a “crawl, walk, run“ mindset. Start by covering the basics and then encourage the prospect to participate. In many cases, you may not even be the one doing all the “clicking.“ Consider whether the prospect should control the experience with your guidance.
“Go deep” demo
You’ve already done a high-level demo of the platform, but the prospect needs more convincing of a product value in a certain area. Perhaps they need more detail on how certain features work. Or what makes your product different/better/faster than your competitors.
This is the stage where your value-based storytelling becomes less important — and you have to dig deeper into your product’s features.
That’s when you use the “Go deep“ demo to get into the nitty-gritty of a specific area or workflow of your offering.
Knowing your competition is also very important for the demo flavor to differentiate how and why your platform does specific things differently and, more importantly, why it’s the better way of doing it.
In most sales situations, you’ll find the reality of the value of your platform vs. another is defined by your prospect’s perception of your product. The prospect will likely ask pointed and specific questions, so you may need to shift focus from what you believe is important and guide your demo session from your prospect’s perspective.
Your prospect is trying to visualize the impact your product will have on their current day-to-day operations, how it’ll improve them, and how they will need to change existing habits formed by the current process.
With a “Go deep” demo, you prove your product is worth their time and effort.
Technical expert demo
This type of demo is typically given to your prospect’s IT or tech team responsible for implementing your product to make it a technical success.
When presenting the technical demo, addressing the “why we’re doing this” story is vital here to ensure your prospect has context on the project. I’ll also recommend involving your business champion and having them outline the purpose of the project, i.e, why they’re looking to change the existing process to a new solution to win buy-in.
Technical stakeholders, especially those who need help with a business transformation that doesn’t directly benefit them, can be skeptical and resistant to change. In my experience, IT or technical teams that have been involved in building the current processes need to be convinced of the need for change. It’s tough, but not impossible.
A good tip here is to have a discovery-focused mindset.
This stands even when what you’re planning to present isn’t the typical value-based approach you would take with sales demos. Get into the guts of your product, including its configuration, setup, settings, and user access controls.
When presenting a technical demo, I use a lot of slides — more than showing the actual product — as I feel it works better to hold the technical team’s attention compared to showing them a bunch of boring controls and settings in the backend of my product.
Also, when showing your product, focus on relevant aspects, such as the ease of deployment and customization of certain features. You want to make your product seem flexible so the technical team feels they are in control of the technical decisions.
Steer away from giving a one-size-fits-all recommendation. Showcasing your product should come in a variety of shapes and sizes and need to meet your buyers where they are at. Otherwise, it won’t do any favors to excite them about your solution.
Group demo — Private
You’re about to present a demo for a potential champion or an executive buyer when all of a sudden a bunch of people show up from different roles, invited by the prospect to “listen in” or ask questions.
What was supposed to be a regular intro demo turns into a private group demo, where you find yourself presenting to a larger group of stakeholders.
I’ll be honest — I find this demo flavor to be the most challenging of all the demos as it often takes you by surprise, giving you very little room to ask questions or run discovery on the fly.
Your best bet to avoid this situation is to send an agenda outlining the call and confirm who will be joining a day or two before the date of the meeting. If you find out some unexpected guests will be joining your presentation, meet with your champion ahead of the meeting to determine their roles.
If you feel it offering them a separate meeting focusing on their specific areas of interest would make more sense, let them know. Worst case, if you get a bunch of people that suddenly appear in your Zoom room (we’ve all been there), be prepared and work on a strong statement summarizing which product aspects you’d be covering at the beginning of the call.
Here’s what I generally use:
“I’m mindful we’ve got a lot of different roles and interests represented in this room. Based on my conversations with ABC, I’m going to focus on showing how XYZ. My biggest concern is there will be questions I am not able to answer today, so before the end of the call, I want to schedule additional time with any of you that need more detail. Does that sound fair?”
In sales, you'll also find yourself giving demos that aren't exactly demos…
Here's what I mean:
“I know what I want — just let me buy” demo
If you have prospects who have either bought your tool before or championed it at other organizations, they're likely to say they know your platform inside out (or they think they do) and therefore don’t need to go through the sales process.
Does this mean you should immediately send the contract over and call it a day?
In such situations, I tend to quickly talk commercials during the first few minutes of the call with the prospects and show them I recognize their urgency to buy. Then, I ask them how they plan to roll out our product (how many users, which features).
If you feel your prospect's answers are well-defined and clear, then congratulations, you’ve just become the luckiest salesperson in the world!
But jokes aside, I would personally approach discovery from a place of genuine curiosity.
If the prospect has used your product before and comes back for more, they must indeed be a genuine fan. But you still need to figure out answers to certain important questions, like:
- What did they like best about your product?
- Did they use all of its functionality?
- What did they dislike most about your product?
- Who else used your product at the prospect’s company and to what extent?
- To what extent have they made a business case internally and gained confirmation on the budget?
This will help you identify opportunities for improvement, such as adding functionality or more users. Any demo here should focus on new functionality or areas you feel the prospect has underused or misused — or explain elements that may be critical to their business case.
The demo flavor here could be a “dry run“ for a presentation with executive buyers or stakeholders with the ultimate decision-making power.
The best approach for this call is cautious optimism.
Show them you’re excited that they‘re coming back for more and want to buy your product — but still have your “red flag radar“ up. If anything sounds unusual about what they’re asking, don’t be afraid to ask for clarification or explore it further.
Group demo — Public
The public group came of age more of a generic training demo or a demo when you’re launching a new feature.
This type of demo is typically run as a public webinar for a group of customers or prospects. Since the session is more training and feature-focused, there won’t be room for discovery. While you shouldn’t waste your breath asking pointed questions to individuals, you still need to present the demo in a crisp, thorough manner.
I want to point out that I don’t view a group demo for the public as a sales task. Instead, it’s a product enablement or training project for me. It’s also why demo training should be cross-functional.
In an ideal world, everyone within your company should be able to give a basic demo of your platform. But the product, marketing, enablement, and customer success teams should be able to go through the extra level of detail when needed. If you're the product expert tasked to run one of the above demo flavors, consider whether your audience inherently understands and cares about all the intricacies of your platform.
The key to success for demos is having a clear goal — both for the presenter and the audience. Do you want the attendees to better understand certain functionality and workflow? Or are you giving them an introductory walk-through? Perhaps it’s a “Day in The Life” for power users.
Based on your end goal, you should choose the appropriate demo flavor and operate accordingly.