How Not to Conduct an On-Site LIS Demo

Mr. HIStalk posts a short note on how not to conduct an on-site LIS demo:

Shahid the Healthcare IT Guy referenced these truly outstanding articles on how to do a startup demo (Part 1, Part 2). Vendors should study this as though another set of stone tablets just got handed down. I like this: "Horrible ways to start your presentation: a) Talk about your bio and your business accomplishments. (We don’t care, we can talk about that later if your product is any good.) b) Talk about the market size. (We don’t care, we can talk about that later if your product is any good.) c) Give an overview of the competitive landscape. (We don’t care, we can talk about that later if your product is any good.)"

I totally agree. Anyone who has been in the market for a new LIS is always astonished by the company personnel who show up after the completion of the sales cycle, which is to say the technical and installation folks as opposed to the sales personnel. The first surprise is that they have an in-depth understanding of the system and the second surprise is that they will often tell you: forget everything that the sales guys have told you. This is a good reason to append to your contract the response of the vendor to your RFP (see: Inside the Mind of a Software Sales Representative; THE ACQUISITION OF A NEW LIS: A Tag Team presentation; Seeking Better LIS and EMR Vendor Project Management Services). In this way, you can hold the company responsible for all of the promises that were made during the on-site demos.

Two other comments riffing off the linked comments about on-site demos:

• If the lead-off presentation is by the CEO or VP Sales of the company, you need to respectfully ask that this particular presentation be limited to five minutes. If one of the slides is a map of the U.S. (or world) with blinking stars for current clients, take a potty break.
• The only useful way to manage an on-site demo for an LIS is with a scripted format, which is to say that you, the potential client, generates a script defining the exact steps and processes that are to be demonstrated by company personnel. The script should be specifically designed to highlight all of the system weaknesses. If three or more of the steps elicit "Can we get back to you on that" from the vendor personnel, you should take a second potty break and mumble: "I need to find a new urologist."

Comments

[Art_Vandelay]

Great write-up. I agree totally. One other point on appending the RFP to the contract - I recommend going back and re-reviewing the RFP responses after the demo and getting everything noted in-writing. It keeps more vendors than not, honest about their functionality and the realistic timing of the functionality. In their defense, it also helps to clarify what is 'between the lines' in our functional descriptions.

[Ole Eichhorn]

I liked and agree with Jason Calacanis' suggestions for how to give a demo too. But in my opinion there's more to forming a relationship with a new customer than selling a product. A key part is selling yourself and your company.

Giving a brief bio and and overview of your company is *not* a bad way to start, it sets up the discussion about how you can work with your customer, and the value you can deliver. The product is part of that value, but the relationship includes more than *just* the product.

This is particularly true for LIS and digital pathology systems where you are integrating a new product into an existing workflow. To be successful a lot of learning, consulting, configuring, and training has to take place over and above the feature set of the product. Having a good relationship with your customer is important to make that happen.