Members Only Logo  
XML

or Subscribe by Email by entering your address below:


Powered by FeedBlitz
Learn about Subscriptions Follow me on Twitter!

The topics discussed here grow out of the bread-and-butter issues that confront my consulting and software clients on a daily basis. We'll talk about prosaic stuff like Membership Management, Meetings and Events Management and Fundraising, broader ideas like security and software project management, and the social, cultural, and organizational issues that impact IT decision-making.

Thursday, June 08, 2006

The Dog and Pony Show

You can tell I've been wrapped up lately in a lot of sales and marketing activities: Last month I had a post on RFPs, and one on software development contracts. Today I want to talk for a minute about software demos. You've collected information on a variety of products and vendors - now you are inviting them to sit down with you and put their software through its paces.

Before you do this, stop and think about exactly what you want to get out of the demo. Your response may be, "Well, I just want to see it. We've read all your the product descriptions and proposals. On paper it meets our requirements. But we need to see it to get a good sense of it." That's true - and its a fine starting point. But you will get more out of the sessions, and more information that will assist you in making a decision, if you can define your objectives more sharply.

In a recent article, Managing Vendor Demonstrations, Eric Spiegel goes into detail about the type of advance preparation that can make your demos more productive. I'm always surprised how prospective customers will present us with an agonizingly detailed RFP for the written proposal, but have not put together any structure for the demo. In the absence of specific guidelines from you, the vendor (that's me) is just going to show you a lot of "cool stuff" and hope that you are wowed by all the great features. What you need to do is understand exactly what it is you want to see, and why. Then communicate it to the vendor before the meeting. It helps to build a little agenda with the vendor. That way we know we are all on the same page when we sit down in your conference room.

Think about the time frame of the demo when building a list of focal points for the vendor. Don't tell the vendor he has sixty minutes with you, and you want to see CRM, Accounting, and ten other modules. Do you really want to evaluate each module based on five minutes of presentation? You need a longer meeting, or several sessions, or a sharper focus on what is to be covered. You don't want to force the vendor to do what Doug Johnson calls "over-demo'ing:"
One demo'd nearly the whole time, full speed, non stop. I was pretty sure this product would slice tomatoes and squeegee your car if she'd gone on another 15 minutes. While this was great fun to watch, I could see folks try to follow her rapidly tapping fingers dancing intricate sets of steps that looked nearly unmasterable by the average Joe
When you are thinking about your objectives for the demo, don't just focus on functional requirements. Think about what your user's pain points and frustrations have been. Last year several prospective customers told us "You wasted a lot of time showing us how to enter data in your demo. We believe you can enter data into your system. I mean, duh."

It made sense. So we changed our style to cover data entry more as a survey of the data entry forms, without a lot of actual typing. But the first time we did this, the customer told us we blew it. "We wanted to see you really set up a bunch of new members and then register them for events. Data entry is really tediuous on our legacy system, and we wanted to see how it goes on yours". Now we know ask about the cutomers desire to see actual data entry before the session. What is it you really need to see?

Don't overwhelm your evaluators. Rees Morrison warns in Five Ways to Get the Most From a Vendor Demo:
Don’t schedule three demonstrations on the same day. It is too fatiguing and causes the systems to blur.
Sometimes we are asked to demo on a week where the customer has scheduled a demo every single day. We find ourselves jockeying to get in a good position in the middle. We've learned that too early and they will have forgotten us by the end-- too late and they will be so bored with demos they will pay us no attention. So make sure your people meet after each demo and get impressions down on paper. Don't let your contenders order of appearance become a factor in your perceptions.

Think about the room setup, especially before that first demo! Don't plan the session in a room that cannot be darkened enough for projection. Make sure you have a functioning network connection and power outlets handy. Match the room and the number of attendees so people are comfortable. And make sure the users you've invited are really free to come - we've often gone to a demo where key users get up after fifteen minutes saying, "I'll be one of the principle users of the software, but I have another meeting to go to, so I'll just ask Jeff to fill me in." You're doing yourself an injustice if your key evaluators cannot attend.

Every bit of advice for effective demos I've found on the net has ended by advising that that the vendor bring food. I'm going to eat right now!
Tags: , , ,

Comments on "The Dog and Pony Show"

 

post a comment