Product Bistro: Mitchell's Rules of Demos

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.