I've done a ton of software and product demos over the years, starting with
the first demo of a graphics program I wrote on an Apple II+ to my fellow classmates in
a college programming class.
Ever since, I'm usually the guy to give demos to
customers. Sometimes I wonder why I'm the "demo guy" but inside I really know why. Most
product demos are very poorly done because they start with the wrong objective
in mind.
Most bad demos are what I call "functional decomposition" demos. You know
what I'm talking about -- after some perfunctory sales questions, the demo
conversation goes something like this...
"This is the blah screen. The blah screen is used to create blah's. You
can have an unlimited number of blahs, and can name blahs any way you wish.
Pushing the Create button opens up the window where you enter the name of
the blah, and all the attributes of the blah you want to create... the blah
type, a description of the blah (it can be as long a description as you wish),
etc., etc. I won't go through all the settings on this screen right now, but you
get the idea here about how to create blahs.
Next we have the list blah screen where we list all the blahs in the
system."
... and so on, and so on. It's a description of the product, a
feature walk through, and what everything does. It's like a verbal User Guide
told to people who probably never wanted to read the User Guide in the first
place. Not interesting, very boring and it doesn't connect with people.
I can't tell you how many sales people, SEs and technicians I've seen
give demos this way. Being on the receiving end of one of these demo is bad
enough, but whenever someone in one my companies gives a customer this type of
demo, I think I get a little bit of throw up in my mouth. (Sorry to be so
graphic.) In my book, you just lost a perfect opportunity with the
customer, and you've left them with figuring out why and how they'd use this
product to solve their problem.
Mitchell's Rules of Demos
I only have two rules. There's only two because without achieving these,
everything else doesn't matter.
1. The Goal
There's only one goal of a product demo, and it's not to show the customer
the features of your product. Here's the goal.
You want your audience to envision themselves, or their
organization/company, behind the wheel using and benefiting from your product that solves their
problem.
Now, study it, practice this, and above all, only consider your demo
successful if you get signals from the audience they are now in this place.
You'll recognize comments from your audience when you are achieving this goal.
Statements like...
"This would let us ..."
"With this product we could..."
"Now if Bob down in Finance had this, it means I could..."
"Could this replace...?"
And if you aren't hearing statements like these, ask your audience; "What
parts of what we're talking about today could you see using for the problem you
told me about?"
In the end, the customer has to envision how what you are showing them solves
their problem. You are leaving a great deal to chance, e.g. you're not likely
to be successful, if you force the customer to make the mental leap from what
your product does to their own business problem.
Your job is to be the Sherpa guide, easing the job of making that mental leap, so participants can easily cross the the divide needed to make the connection between their problems and how what you have to offer solves those problems.
How do you do all this?
Here's some suggestions:
- Build your demo discussion around the problems the customer has told you
about.
- Talk about how they would use the product, not how the product works.
- Talk about how your customers use the product to address similar problems,
and other uses that tie in with this customer.
- Use scenarios and fit the product into the scenario that look like the
customer's situation.
- Check in and ask questions to see if this is at all connecting, and if so,
what's connecting and why.
The best way to sum it up is that a product demo isn't really a demo, it's
about a conversational story. The story you are telling is about how this
customer and customers like them use your product to address their need or solve
their problem.
2. Set Context
Have you ever gone into a meeting with a vendor, realizing you've pretty much
forgotten most of what was said in the last meeting with them? Maybe you even
forgot exactly what they do or what their product does. Maybe you are one of the
participants who hasn't been in previous meetings and you are new to the
discussion.
This happens all the time. Just because you live with the product everyday or
have been thinking tons about how to sell to the customer since your last
meeting, doesn't mean they have. You always have to set and re-establish
context.
Context is that map in the mall shopping center with the arrow that says
<-- YOU ARE HERE. Because there has been a gap in time and/or because there
may be new participants in the demo meeting, you have to briefly re-establish
context. If there are new participants, you'll need to spend a little bit more time
up front doing this.
Here's what you need to summarize:
- Who you are. "Hi, we're will ABC. We solve the blah problem for A, B and C
type customers like you."
- Confirm you still understand the problem. "Through our discussions, you've
helped us understand the problems you are looking to solve are.... Do you feel
we have a good understanding of the problems? Has anything changed since our
last meeting?"
- Confirm what they came to see. "Our goal today is... Are there any other
expectations of today?"
- Tell them what they are going to see. "Today we are going to show you how
blah can solve the blah problem."
And then at the end of the meeting, circle back around to determine if you've
addressed how you can solve their problem or need. And also re-emphasize all the
benefits you've touched on. It's akin to what you learned in speech class in
high school and college; Tell them what you're going to tell them, Tell them,
and Tell them what you told them.
I also can't emphasize enough revisiting the customer problems you've
uncovered during previous discussions. Things may have changed since your last
discussion. Maybe their understanding is deeper or different. Maybe their
situation has changed and what was a priority has now been replaced by something
else. Maybe some other vendor came in and change the game since your last visit, laying some land mines or booby traps for you to stumble into. Lots of things could have happened and you don't want to be operating from the wrong or outdated perspective. Last week's highest priority project could be in the dumper this week. Things change so don't assume they haven't.
Remember, setting context is two way, for both you and the customer, and it's just as important you know the
customer's current context.
Wrap Up
I hope you find these two rules as beneficial as I have. They have some far
reaching implications to the logistics of product demonstrations, especially the
type of demo data needed to give a conversational story demo rather than a
feature based demo. If you start with these two rules in mind I think it will
drive a number of downstream logistics and help your demos accomplish a great
deal more than what might be happening today.
Try it out, and give me your feedback. I'd love to hear if this is helping
you and hear about your views and ideas on product demos.