Software Demonstration Training Tips

Ah, the good old days. Software was limited in what it could do, user interfaces were simple and single-purpose, and users did not ask for unlimited flexibility. How easy it was then to design, engineer, and demonstrate software.

Early business applications were designed for highly repetitive, highly normalized tasks. They were, in fact, logical extensions of the “posting machines” that preceded them. But times have changed. Through the wonders of first PC’s and then the web, we have all come to expect software applications that are extremely flexible, capable of being used for non-repetitive and non-predictable processes. Engineers have been very obliging, coming up with any number of ways of navigating through processes, tasks, and information. Think of all the information dashboards, multi-tabbed applications, and process navigation options found in the simplest of applications. In early business applications, there was usually a single “thread” to be followed through any given task or process. The software was in charge.

Today, the user is in charge, with numerous options, paths, and information sources related to any process or task. But as the user has gained flexibility, the demonstrator must gain discipline. All of those options and paths may represent flexibility to the user, but they represent confusion to the prospect and possible bottomless pits to the demonstrator.

Let me explain...

Executives and managers evaluate software based on how well it will help them in achieving the goals of the organization. But users carry a different yardstick. They evaluate software based on how easy it will be for them to do their job with your offering. And they reach their conclusions based on how well you demonstrate the software. If you make the software seem simple and easy to use, you win. If you focus on how flexible the software can be, and how many options it offers, you can very easily lose.

This leads us to a demo crime called “the data dump”. Engineers have made it remarkably easy to do a data dump in front of the prospect. From almost any screen in any software, we can go anywhere, do anything, change any setting or option, and follow any path – even one far away from the task at hand. So we may start off by showing someone how easy it is to enter a line item on a customer order, only to wind up discussing and showing the many ways that credit limits can be determined and set! Or we may intend to show a sales manager how easy it is to see the status of a sales pipeline, only to find ourselves lost deep in the middle of explaining how sales compensation models work! And we won’t be the only ones lost at that point.

There are three things that lead to the data dump crime, and those three things provide all the instruction we need to avoid the crime. Here they are:

1. “Just because you can doesn’t mean you should.” Yes, engineers make is possible for us to have great flexibility in moving through our software. And yes, users will find that flexibility great once the system is implemented and they are well trained. But right now they are still a prospect and they simply need to know the best and simplest way to do their job with your software. Stick to that. Show them the easiest way you know to do what they need to do. Don’t let all those shiny buttons and interesting menu options entice you. If the prospect needs more, they will ask for it. 

2. “That’s my story, and I’m sticking to it.” The trick to avoiding a data dump is to tell a strong story. Before you ever touch the software, tell a story about what you will be doing. Create a simple scenario that matches a task or a process, and then simply execute on that story. This opening tell approach will serve to help you stay on course, and will help minimize the interruptions from your audience and the distractions that are present in the software. If you do get a question or interruption, you have the perfect method for handling it. For example, if a prospect asks something like, “are there multiple ways of determining the price of that item on the purchase order”, you can say, “yes, but let’s finish entering this order first, then we will come back and look at pricing options.” In other words, you started with a story, and you are sticking to it. 

3. “You can visit more than once.” I remember a situation many years ago where we had greatly expanded the capabilities of our software in the area of order management. The first time I watched a salesperson demonstrate the new module to a prospect I was appalled. They started a new order and in one agonizingly long session proceeded to show and explain every single option and capability possible regarding a sales order. It took 45 minutes to complete that one order! Afterwards, I explained to the salesperson that there was no rule that said you could only enter one order. We developed and practiced a pitch that went something like this: “There are a lot of capabilities and options in sales order entry. So in the next fifteen minutes we are going to enter three orders. On the first, we’ll concentrate on a standard order, no special situations. Then we will enter an order with special items – non-stock and drop ship items. Finally, we’ll look at two special types of orders – returns and quotes. That will give us a good overall picture of sales order entry, then we can discuss other capabilities.” Having told the story, we then did just what we said we would do – and nothing more.

As a professional, you pride yourself on knowing everything that your software can do. That’s great, but it is not what the prospect needs. That potential user sitting in the audience simply wants to know that the software can make it easier for them to do their job. Anything beyond that is simply a source of confusion. So help that potential user make a decision in your favor and avoid the data dump.