- Vendors use demos to show their prospects their software, however, demos are not realistic environments.
- In this article, we will cover how to take control of the demo from the vendor.
How to Manage The Demo
The software demonstration (or demo) is one of the few opportunities to get first- hand experience with the software. Most information on demos (and there is not a lot to be found) explains how to put on a good demo. However, I could find nothing on how to get good value from a demo if you are the software buyer. There are several issues that negatively affect how accurately demos can be said to represent reality.
However, from the perspective of buyers, the weaknesses of demos are that they tend to be artificial and are controlled by the vendor. The common issues with demos are listed below:
- The company’s presales consultant typically runs demos. The demo is not an accurate representation of how the software will actually be used because this person specializes in knowing all the ins and outs of the software and is typically quite specialized in that application. Users will never attain the ease-of-use demonstrated by the consultant because they use several applications throughout the day and won’t gain the same depth of knowledge about the product as the consultant. Therefore, the consultant’s level of knowledge allows them to make the product look much easier to use than it really is, and to gloss over its imperfections.
- Demos use dummy data, which provides a great deal of flexibility to the presales consultant who drives the demo. Applications run faster and more smoothly with smaller data sets.
- Demos tend to be tightly controlled in that they follow a script. The script makes the application look much more fluid and fully featured than it actually will be when implemented.
- Too often the users are excluded from the demo, meaning that the demo tends to be a high-level affair. However, it is the users who ask the most pertinent questions related to how the software would be used in an everyday setting.
- The same bullet point above applies for technology resources. They are needed to ask questions related to how the software actually works under the covers, how it loads and updates data, makes decisions, etc.
- Demos tend to be short. Most range from between forty-five minutes to an hour. This is not enough time to explore an application, particularly if it is complex. Large audiences tend to shorten demos because the demo is often seen as just one part of the presentation that day, and the more senior members tend to want to spend an hour on several occasions going over software. This short exposure time to the actual software is a mistake because the shorter the demo, generally the more the vendor can hide.
- While I have never heard this mentioned in other published material on software selection, I find it very useful to have screenshots sent of interesting functionality. Once a buyer has screenshots they can mark up the screenshots, and then compare and contrast to screenshots of other applications. Comparing and contrasting functionality in this way is something I do when I chose software to showcase in books. This can allow a software selection document to be created that really explains the specific differences between the different vendors. However, demos are extremely important. While it should be remembered that the vendor would like to control the demo, ultimately, the buyer is in control of how the demo progresses—if the buyer wants to take that control. It is the buyer’s time that is being taken and the purpose of the demo is to inform the buyer if this is the right application for them. The best way to take control of a demo is to declare how you would like the demo to run, and to do so well in advance of the vendor actually making the presentation.
- Without this communication prior to the presentation, the software presales consultant can legitimately say that she is not prepared to perform the demo in that manner. This is because demos must be prepared both in terms of the data that is used and how the presales consultant manages the demo. Most presales consultants are not comfortable with individuals from the buyer navigating through the application himself or herself, so they must be told beforehand if these individuals would like to do so.
However, this can be accomplished even if the demo is not performed in person because all screen-sharing applications allow transfer control of the computer to anyone who is part of the screen sharing session. Another way of taking control of the demo is to stop the flow of the presales consultant’s presentation. The presales consultant may have a set of things he wants to show, and plan on leaving questions until later, but this is a way of taking control of the demo. As a buyer, you should remember that the entire purpose of the demo is for you to understand whether this software should be selected. Therefore, the presales consultant’s desires must rank as a distant second to the buyer’s needs. Ways to make demos more useful to the buyer can be determined by working backward from the limitations of the demos.
SAP and the Controlled Demo Approach Versus a Demo Login
The presales consultant can explain the software, but someone else should drive the demo, at least for part of it. By doing so, you are controlling the presales consultant’s skill level. Yes, certainly a presales consultant can move very quickly between the screens, but how intuitive is the application for a first-time user? If I take the example of SAP versus Arena Solutions, SAP allows companies that have included SAP in their software selection process to view their software only through the presentation of a software consultant. Arena Solutions allows anyone to self-navigate through their online demo environment for thirty days. This speaks to the confidence level that Arena Solutions has in its software and its usability. SAP would never allow this because the difficulty in using SAP could become apparent.
Not all companies have an online demo environment like Arena, but still, when a demo is presented the request can be made to have someone from the buyer actually navigate the software under instruction from the presales consultant, or the buyer resource and the presales consultant can take turns running the application. The more usable the application, the more open the vendor will be to getting the maximal exposure to the application for the buyer.
Breaking from the Script
There is nothing wrong with allowing a presales consultant to start from a script. There are some things that need to be shown; however, the entire demo should not be from a script. It makes little sense for most of the demo to be “canned” or from a script as the standard things the vendor wants to show should be available for multiple viewings in video format on the vendor’s website. At this point, the demo should center on things that the client has asked specifically to see (in advance) and the vendor should have built the demo specifically to answer these questions. Demos can also be made more interactive simply by driving the demo with questions. Presales consultants are under a lot of pressure from the sales team to provide short and smooth demos that leave the buyer with a good impression. However, if it is explained that the buyer does not desire this, typically the demo can be driven differently.
Users need to be included in the audience during the demo, and their opinions should be solicited after the demo. Would they personally want to use the software? They should also be told to ask questions whenever they see fit and not at the end of the demo only. Users will pick up on things that executives will not. There is absolutely no logic to exclude the eventual users from a demo. When I worked at i2 Technologies, I recall that on one account the presales and sales team convinced the potential customers to keep users out of the demos. The sales and presales team explained to me that they knew the particular software they were showing was weak and that they would not be able to answer users’ questions, so they needed to, in their words, “sell directly to the top.”
Managing the Length
Demos should be lengthened. A demo lasting an hour or less, or even multiple demos lasting an hour or less, is not sufficient to really understand how the application works in a variety of circumstances. The shorter the demo, the less representative the demonstration, and the easier it is to cover up weaknesses in the application. After the salespeople and the implementation consultants are gone, what will remain is the software. The software needs to work as the company desires and needs to be able to stand on its own and work efficiently the way the users need it.
Financial Bias Disclosure
Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.
Software Selection Book
Enterprise Software Selection: How to Pinpoint the Perfect Software Solution Using Multiple Sources of Information
What the Book Covers
Essential reading for success in your next software selection and implementation.
Software selection is the most important task in a software implementation project, as it is your best (if not only) opportunity to make sure that the right software—the software that matches the business requirements—is being implemented. Choosing the software that is the best fit clears the way for a successful implementation, yet software selection is often fraught with issues and many companies do not end up with the best software for their needs. However, the process can be greatly simplified by addressing the information sources that influence software selection. This book can be used for any enterprise software selection, including ERP software selection.
This book is a how-to guide for improving the software selection process and is formulated around the idea that—much like purchasing decisions for consumer products—the end user and those with the domain expertise must be included. In addition to providing hints for refining the software selection process, this book delves into the often-overlooked topic of how consulting and IT analyst firms influence the purchasing decision, and gives the reader an insider’s understanding of the enterprise software market.
By reading this book you will:
- Learn how to apply a scientific approach to the software selection process.
- Interpret vendor-supplied information to your best advantage. This is generally left out of books on software selection. However, consulting companies and IT analysts like Gartner have very specific biases. Gartner is paid directly by software vendors — a fact they make every attempt not to disclose while consulting companies only recommend software for vendors that give them the consulting business. Consulting companies all have an enormous financial bias that prevents them from offering honest advice — and this is part of their business model.
- Understand what motivates a software vendor.
- Learn how the institutional structure and biases of consulting firms affect the advice they give you, and understand how to properly interpret information from consulting companies.
- Make vendor demos work to your benefit.
- Know the right questions to ask on topics such as integration with existing software, cloud versus on-premise vendors, and client references.
- Differentiate what is important to know about software for improved “implement-ability” versus what the vendor thinks is important for improved “sell-ability.”
- Better manage your software selection projects to ensure smoother implementations.
- Chapter 1: Introduction to Software Selection
- Chapter 2: Understanding the Enterprise Software Market
- Chapter 3: Software Sell-ability versus Implement-ability
- Chapter 4: How to Use Consulting Advice on Software Selection
- Chapter 5: How to Use the Reports of Analyst Firms Like Gartner
- Chapter 6: How to Use Information Provided by Vendors
- Chapter 7: How to Manage the Software Selection Process