For anyone involved in supporting customers of any non-trivial commercial software product, it is very important to understand the distinction between a product demo and product training.

Ideally, demos are pre-sales and training is post-sales.

A demo is pre-sales: The vendor has control over what is seen and, more importantly, what is not seen. An employee is in the driver’s seat, presenting the product in the best possible light.

On the other hand, eventually the customers are going to be driving, steering the program willy-nilly at their own whim. Customers (now users) who are familiar only with the demo will inevitably, through ignorance or malice, discover every quirk or pitfall that might be present in the program, becoming ever more frustrated and hostile with each discovery. Extensive testing can minimize these issues, but eliminating them can be, in many circumstances, impossible or at least impractical. There must be a mechanism by which the new user learns how to drive and becomes familiar with the major quirks and pitfalls of the program in a controlled environment. This is training.

Just as the demo presents the product highlights in the best possible light, the training must present the lowlights in the best possible light. And there is really nothing to fear by revealing the flaws post-sales. Like getting old, it beats the alternative. It does no good to try to hide the flaws; it’s far easier to point them out in a training exercise than to allow the users to find them on their own, and thereby incur the cost of support to remedy the issue (“Pay me now or pay me later”). In a corporate environment, the existence of quirks, pitfalls, and bugs will not be a revelation. Any potential user who expects no pitfalls is too junior to affect much anyway.

As a salesman, you point out the doughnut. As a trainer, you point out the hole.