Deborah R WilsonI’m married to a marvelous guy who happens to be a database architect. He brings home great techie jokes on a regular basis. Here’s one of my favorite. A guy dies and meets a spirit as he passes into the afterlife. The spirit gives the guy three choices on how he can spend the rest of eternity. The first choice is a tropical island filled with lithe, bikini-clad women. The second is on a sleek, well-powered fishing boat on a large, tranquil lake. The third choice is to relax in a warm bungalow nestled in the mountains, surrounded by earlier-deceased friends and family. The guy chooses the tropical island. (Sorry, this is a guy telling the joke.) Moments later, he is whisked away . . .to a hot, fiery landscape – hell of course! The guy asks the spirit – who we now know is the devil – “What happened?” The devil replies, “Oh, you understand, that was the demo version.”
Of course, applying this joke to software is a great over-exaggeration. However, like most jokes, it is a nugget of truth that makes it funny. Why? Because most demos are very well scripted to avoid showing prospects (and analysts) the weaknesses of a solution. So – setting up a new supplier master record? Don’t show that one . . it takes twenty clicks! You get the idea.
What does a demo get you? If you aren’t really sure what a solution does, a demo is a great way to get, at a glance, the highlights of functionality. Often, a picture is worth a thousand words. A demo can also give you a rough idea of how aesthetically pleasing a solution is to use. But if you really want to learn about a product – don’t ask for the vendor’s stock demo – demand a custom SCRIPTED demo. In other words, take the applicable tasks you do most often, and require the vendor to show you, in the live application (no screen shots!), step by step, how it is accomplished.
Set your expectations accordingly, too, that a demo isn’t going to show you everything you need to know. When I evaluate products, I typically test for at least 100 features and often many more –up to five hundred features – to finalize a rating. I have learned though my career that getting a demo of everything is impractical because each feature can take 5-10 minutes or more to show. That is why references are so important, for prospective buyers and analysts. References are absolutely indispensible, in fact. They are the only source of feedback from someone who uses a solution day in and day out, to provide a read on whether a feature is complete, usable, and to verify that the application doesn’t require 20 clicks to complete a simple task.
So should you demo? Sure, only entertain live demos with proper scripting and appropriate expectations.
Category: Uncategorized Tags:
2 responses so far ↓
1 Ben Pearce June 25, 2010 at 12:28 pm
Greetings Debbie,
Nice joke “demo” vs. reality, I think we can all relate to a situation where we felt there was incongruency between what we were shown and the end experience of software. My background includes many years of presales support delivering demos for prospects and 16 years as a purchasing professional using (and designing) procurement systems. A demo can certainly give a high level sense of the capabilities of systems, but you point out that a live scripted demo can give you a better sense of how the software will function for your company. I have delivered both types of demos and feel that they certainly have their place in a sales cycle. A high level demo that may include some screen shots, “click through” screens, and live demonstration should be fine for an initial discussion. Scripted demos should be reserved for your “short listed” providers as they can be very labor and time intensive. I think that the biggest mistake companies make in their evaluation of software is not sharing the problem areas that they are looking to alleviate with the technology. Many times I have been asked to deliver a demo to a prospect just because it was on the list of things to accomplish. They should also be realistic in the amount of time required to deliver a demo. It seems that with busy schedules, most prospects are looking to software providers to show everything, include my scripted requirements, answer all of my questions, and by the way we only have an hour.
2 Mark McCarthy July 2, 2010 at 6:12 pm
Hi Deborah,
Great point. As someone who has spent 14 years on the other side of the table – selling procurement applications – I can only agree wholeheartedly that a demo very rarely reveals the true capabilities of a solution or its vendor. It is easy to do a great demo, even one which follows a buyer’s script. After all, we know our software intimately and so you’d expect us to know how to make it sing and dance, right? In my view, the only way to really test the “fit” of a solution is to share the business goals and investment appraisal with the vendor(s) and invite them to “consult” with you rather than “pitch” to you. Buyers seem to be afraid that this simply opens to the door to slick salesmanship, but it is very difficult to hold a vendor accountable for successful project delivery without taking this step. By bringing the vendor inside the discussion rather than just asking them to pitch at your internal team, you will learn a lot about the capabilities of the solution, the comfort zone (and discomfort zones) of the vendor and their ability to get you where you need to be.
I would argue that the same goes for functional checklists in an RFP. Most vendors can answer a bland “yes” to any feature request nowadays, such is the maturity of our market. But dig a little deeper – what assumptions are behind the “yes”, who else is actually using this feature (and with what results), and what does adding this feature do to the project plan, etc. – and you will quickly see the difference between those that can talk the talk and those who have walked the walk. When analysing the results of any such checklist, always ask yourself “they said YES, so what is the BUT that they didn’t say?”. As a vendor, it is simply too tempting to answer a straight question with a straight answer, without full disclosure of the complexities, especially if its an unsolicited RFP or a buying process that discourages pre-response analysis by the vendor.
I also agree with your point about references, Debbie, but one suggestion I would add… every software vendor has “pet” references, who are well versed in saying the right things because they have a strong relationship with the vendor or because they are contracted to a reference program. So I would advise to ask for 3 references, then tear them up and ask for another 3. This usually flushes out the strongest “pets” and forces the vendor to look lower down his favourites list.
Sorry for the long comment! I actually started writing a paper on this subject a few months back – if anyone wants a copy when it is completed then feel free to email me.
Mark