Lots of people give software demos to prospective customers, business partners, investment partners, and the media. Usually very uninspiring demos. In meeting rooms and on show floors everywhere, your competitors’ prospects are sitting through boring presentations as they try to figure out how on earth the discussion even relates to them.
None of these prospects is asking to be bored silly. They’re taking the trouble to sit down to understand a software product and to hear about its value. But they’re walking out of demos unenthusiastic at best, or worse, mystified as to how the software can help them.
Because Product Managers are in a unique position to understand the technical workings of the software product while also understanding customer needs, companies frequently turn to them first when a demo is called for. Even when there is a bevy of sales engineers who are supposed to be demo wizards.
There are many things you can do to improve your demo abilities. Use the tips below to improve your demo skills, and share these materials when you train colleagues and sales channel counterparts to demo your software.
[private]
Hone Your Presentation Skills
There are many techniques and recommendations for giving good presentations in person or via Webcast or telephone. While this subject is too vast to cover here, understand that in addition to the specific tips below that relate to software demos, these recommendations will also help you hold an audience’s attention.
If you would like to receive tips on giving a great presentation written by a professional contact of mine (about eight pages, with several links to helpful information on the Web), please send an email to jacquesm@epix.net.
The Purpose of a Demo
First and foremost, it’s important to define the purpose of a demo. The purpose of a demo is not to present all aspects of the software. Instead, it is to show your audience how the software benefits them. A second purpose is to build enthusiasm for the product, creating momentum that your company can use to move the prospect to the next step in the sales or business agreement process.
Keep this purpose in mind as you build the demo using the remaining tips.
Talk With Them
Think of the demo not as a classroom or podium presentation but as a conversation held around a table. Your goal is to get your prospects talking about what they want and need. Ask questions and solicit feedback all through the demo to create a two-way conversation. Much of this centers around business topics rather than software screens.
For example, begin the discussion of an ERP software product by asking about their inventory and resource planning situation and challenges.
Ask questions like:
“How do you do X (stock enough inventory, fulfill orders, etc.) at your company?”
“How do you deal with X (backorders, missing inventory, etc.)?”
Feel Their Pain
As part of the conversation, work to uncover the pains — the business needs, challenges, and wishes — of your prospect. For example, the pains relating to ERP will be such things as lost or pilfered inventory, production delays due to lack of resources, and higher inventory costs due to rush deliveries and purchases of small quantities.
As you present the product, explain how specific features solve the pains you have identified. Nothing holds someone’s interest like an explanation of how you can solve their problem.
People Can’t Picture Things
Pictures are worth a thousand words, because of the strong impact they have. Don’t rely on verbal explanations to explain a concept. Use pictures, either as prepared slides or drawings you make on the fly.
Sometimes even the most compelling explanations fail to get the point across to a listener the way a picture does.
For example, don’t explain that a screen could be used to manage inventory for the prospect’s products. Make a picture of the screen listing an actual product that the prospect uses.
Tell Stories
Good teachers tell stories, and the best teachers tell stories that illustrate their points. Everyone relates well to stories. I still remember stories told by my teachers as far back as grade school.
Build a library of real-world stories about customer problems and how the software solved them. These stories will hold the attention of your listeners and help them remember what your product can do for them.
Tell stories that illustrate the particular pains mentioned by the prospect, and how customers used the software to resolve them.
Prepare Sample Data
Don’t use blank or silly test data on the demo screens you show. Instead, build a library of screens that show typical examples of what your existing customers see on their screens.
For example, a demo of an insurance policy processing system can show typical policies with a realistic payment and claim history that illustrate common situations. Sample claims adjustor comments should be believable and follow a logical thread across contacts with a customer. Provide examples of each major type of insurance policy (life, auto, homeowner’s, etc.) so that you can show realistic examples to many different insurance prospects in insurance.
This goes along with the “People can’t picture things” tip above. Provide solid examples rather than asking your listeners to picture them in their mind’s eye. Two-thirds of your audience will be lost as soon as you ask them to imagine a screen is different from what they see before them.
Use a demo database that is clean of test records entered by developers such as “Customer Xxxxxxxxxxxxx25” or “Joe Millionnaire”
.
Focus On Benefits
Following up on the pains that you have uncovered at the outset of the demo, explain the software in terms of the benefits it provides, rather than its features. These benefits are solutions for the prospect’s pain.
For example, don’t focus on the feature called the “Long Term Planner”, a flashy but complex screen. Instead, begin by explaining to your prospect that they can cut their manufacturing costs by totaling up all needs for a given component for multiple production runs, then buying it in larger quantities with a delivery schedule that gets them the parts only when they’ll actually need them.
This is how you can give a demo where each attendee walks away understanding the value of the software to them.
Ignore Menu and Screen Structure
Part of presenting benefits rather than features is to drop the whole idea of showing all the menus and screens. It’s easy to rely on the drop-down menus, screens and subscreens to provide the structure of your presentation.
That approach is a prime attention-killer. It leaves it to the audience to try to piece together — like a puzzle — the workflow and benefits from the menu selections and screens.
Instead, focus on individual benefits and the processes associated with obtaining those benefits, and only show screens and menu selections that are relevant to the benefit under discussion.
Follow a User Workflow
After you drop the menu and screen structure, talk with users at showcase accounts to develop some standard processes or workflows. Then show how you use the software to carry out these processes.
Organize the processes around benefits which tie back to the pains that surfaced in the initial discussion, the one that started the demo out as a conversation rather than a speech.
Point to the Next Step
After you first grab the prospect’s attention by getting them talking and understand their pain, then win their enthusiasm by demonstrating how your software can help their pain, you have an interested and informed prospect.
At the end of the demo, avoid the tendency to just sop, pack up and walk away. Even though you’re tired, this is the time to get to the other purpose of the demo, which is to get the prospect to agree on the next step in the sales, business alliance, or investment process.
By practicing and building on the above tips, you can make your demos powerful and compelling, and build up a reservoir of demo knowledge that can be rolled out to sales engineers and channel partners to increase product sales and beat out the competition.
— Jacques Murphy, Product Management Challenges
ProductManagementChallenges.com
[/private]