How to demo
Once again, I am riding into that territory where a few words and a ill-timed bug can cost a customer relationship: I'm doing a lot of software demos these days. Perhaps if I explain how to do it right here, I'll remember it better when doing it myself. Your comments, suggestions and disputations are welcome, of course.
Law of the demo: Show only what is important, not everything your product does, might do, or ever will do. The most frequent mistake I've seen, when I've been on the receiving end of demos, is the effort to show every feature and function of an application. Here's a story I'll never forget. Back in 1992, I was particularly interested in workgroup software, and invited in a developer who showed off his brainstorming groupware. He talked and built brainstorms for an hour straight, looking back over his shoulder to explain what his mouse was flying through on-screen. It was impressive, because everything and the kitchen sink were in his application, and he'd come up with a perfect example: How he brainstorms. Unfortunately, when he left his software behind for us to try out, it was incomprehensibly difficult to use because he has not given us the simplest instructions about what we could do it with. Instead, he'd built his brain in software and demonstrated that he could use his brain for an hour.
I think a lot of the single-features-that-are-a-company companies today are the product of the brevity of their demo, which can seem really purposeful until you start thinking about how to build a business on that one feature. Leaving a lot for the customer discover through their use of the product, and keeping future plans to yourself rather than making them the centerpiece of today's demo, provides you a migration path that will turn your initial ideas into a sustainable business.
1st Corollary: Keep it simple, keep it purposeful. The software we're launching introduces some new information that simply hasn't been available before, we're analyzing conversational networks for influence. To show that influence, we have to demonstrate the difference between influence and what people are used to—authority and Page Rank being the metrics most folks know—and we have to show that influence changes over time and across diffferent topics. That's all we can expect to get across in a meeting with customers, though we have a lot of features in the product to let the customer look at the phenomenon of influence from different angles. When we start showing all those other features, people will forget the basic insight they just learned and start seeing all the features we have for more sophisticated analysis as ways that insight could become confused.
2nd Corollary: Have a story. Showing the role of influence in a network is a highly subjective thing, even if the data is objective. The customers who are looking at the network have their own views of the meaning of the data that, if your story doesn't support their idea of its meaning, invalidates the data in their mind. So, whatever your product, don't impose your interpretation of the customer's world onto the customer, because they'll fight it. This is what we—software developers—do when we show up with a case study that, even though it contemplates the customer's business, isn't applicable to the specific customer's business. Leave case studies for later, when the software has proven itself in use.
When demoing, find an engaging story that doesn't conflict with the customer's experience and tell it to illustrate your basic value proposition. They are smart enough to apply that to their own business, because they think about their own business every day.
Second Law of the Demo: Don't apologize for bugs, crashes and errors.It's a demo, ferchrissake. Relax. If you've watched Bill Gates for a long time, you know that, even though a crash gets him steaming mad, he seldom shows it during the demo. Instead, he shrugs it off or makes a joke of it. Apologizing underscores the problem, whereas if you take it in stride, the customer and you both take the reasonable position that no demo-stage software is perfect. The idea is to get them using it in order to make it better. So, don't make them think that they're going to have to deal with apologies all the time; people hate that, and most businesses run on the concept that you don't apologize, you fix the problem and get on with things.
Ratcliffe's Corollary To the Second Law: Keep your confidence, in both senses of the word. If you find yourself talking at length about what you need to fix in your software, you're not keeping your confidence in yourself or with yourself. Take notes about what needs to be fixed, but get on with what you want to show. When you discover you are in the middle of a five-minute stammer about something, decide to stop then and there, get on with the demo and, when back at your office, get the answer down to five to ten seconds.
Technical Evolution Law of Demos: Now that many demos are conducted by network, not in person, keep the limitations of the systems firmly in mind."Down here" and "over there" are signs that you may be missing a third to half of your demo when using NetMeeting for GoToMeeting or whatever conferencing system you choose. When you say these things, you move your cursor somewhere on your screen that others on the call may never see. If you demo from a 21-inch screen, remember that there is someone out there with a 12-inch screen missing half or more of what you say. It's not like the old days, where a big screen made a demo more exciting. Design your demo for small screen geometries.
Universal Law of Customer Relationships: Listen more than you talk.
I think that covers the mistakes it's easiest to make. But I'd love to hear from you in TalkBack.