Guest post by Jason Salares, Team Lead, Business Intelligence and Advanced Analytics Demos
Watch Jason's demos of IBM Concert, Project Neo and more in the Business Analytics keynote at IBM Information On Demand 2013. View at http://bit.ly/1cHHXTE
Of all the jobs I've had in my life - from sandwich artist to golf course grounds crew to hawking credit card applications at the airport at 5:30 in the morning -- none has been more downright terrifying than demonstrating software in front of an audience. It can be the epitome of Murphy's Law in action.
You're thinking “I've got the program right here on my laptop, all I've got to do is fire it up and show the crowd how it works. What could go wrong?”
So, rather than become a public victim of random gremlins in the demo room, I spent some time figuring out just what's needed to make a software demonstration not just bulletproof, but meaningful, memorable and compelling as well. It's not a long list of requirements -- only six, but without any one of them you run the risk of delivering a flat, boring demo. So to help you avoid that, here's “The Six-Ingredient Recipe for a Winning Bake-Off.”
The “bake-offs” are the idea of BI Scorecard analyst Cindi Howsen, and she hosts them at various events run by The Data Warehousing Institute (TDWI). A recent event focused on evaluating different BI vendors, specifically around dashboarding and visual data discovery, to see which offerings were baked to perfection compared to those that might be a little half-baked. Cindi also likes to do a little live baking so audience members can learn how to run their own bake-offs when evaluating different vendors.
It was the perfect test-kitchen for trying out my six-ingredient recipe. And what I’ve learned in competition can be applied in selling. Even if your competitor is not in the room at the same moment, sooner or later, your product will be compared to someone else’s!
So what exactly makes the recipe for success?
Ingredient #1: Preparation
Obviously, you have to prepare your pitch, but rather than leave the technology to chance by demonstrating live software, I highly recommend taking the time to create a screencam of the features you'll be demonstrating. That way, you are in complete control of the action on the screen and can script your pitch.
I'm not talking about a Windows Media Player, with visible player controls on the screen. The difference between that and a screencam demo is that a screen recorder creates clips that play back the exact cursor movements, clicks, x-outs, windows opening and closing etc. that you record when executing a function. On stage you can put your hand on the mouse and pretend that you're moving the cursor, when in fact what you're doing is "lip synching" a function that's already been recorded. This is how you make the demo look live. There are no mouse jumps, no effects/transitions, or anything thing that wouldn't normally happen when you're executing the function in your office in real time. Then, when you embed the screencam clip into a Powerpoint slide for presenting, two things happen: First, you can transition from slides to demo seamlessly. Second, you can hide the video controls, but still click and play/pause the screencam as you talk. It's as simple as click to play, click again to stop.
The last part of the trick is to "sell" it a little bit. You don't tell them that it's a video, but you don't tell them it's live either... and as long as you keep your hands behind the laptop as the mouse is moving on the screen (you can gesture wildly while it's paused), people think it's live... the overall net of this approach? Less risk, but with all the credibility of a live demo.
In competitive situations like the recent bake-off, I also spend a large part of my time analyzing the questions and trying to get a handle on why I’ve been asked to demonstrate certain functions. By reading between the lines, I can find ways to accentuate the positive, eliminate the negative and always play to our strengths. For example, I set up a "spectrum" of dashboards before the bake-off, so that I could jump between interfaces to best answer the questions. In other words I was prepared for any eventuality.
Ingredient #2: Strategy
Tailoring or interpreting the questions so that they play to your strengths takes forethought, as I mentioned. It also requires a strategic approach. For example, to ensure that I could show the audience at the TDWI event both IBM Cognos Insight and Cognos Workspace, I showed more than necessary in response to an earlier question so I could show other interfaces later -- that is, saying, “I already showed you this in Cognos Insight earlier, so I'll now show it to you now in Cognos Workspace.” Taking a strategic approach allows your to show off features that otherwise might get glossed over.
Ingredient #3: Knowledge of the Competitor
Anticipating what others might show is important. Having some knowledge of their product, even if it's only from reading reviews, can make a huge difference. Because it was a competition, I wanted to make sure the audience knew that I was treating it as such, so I explicitly said, “Here's why IBM is a better option - faster, easier, smarter - and everything I'm going to show today is going to highlight this theme.”
Ingredient #4: The Right Data
The best types of example data are those that are universally relevant to your audience: Cell phones, cars, the weather etc. Sample data sets based on fictional companies are not interesting. People don't care; there's no compelling story to be told, and it's entirely based on hypothetical situations. Data in demos needs to be instantly understood and relevant, so the audience doesn't have to be told why they should care about the data. This allows them to spend more time listening to your pitch.
Ingredient #5: Context, Context, Context
This is perhaps the most crucial ingredient of all, because even if you find that compelling dataset, it won't sing until you craft a story around it, something that allows the audience to make the situation their own.
For example, I used weather data during the competition, focusing on the data about lighting strikes. I told the audience a story about how I was once standing in the on-deck circle at a softball game with a metal bat in my hands when I heard thunder. This made me wonder how often people got struck by lightning, but rather than throw the bat down and run screaming for my car, I waited until I struck out, then got my laptop out of the car. I sat down in the dugout and proceeded to calculate the probability of such an occurrence, based on number of events and population. I'll admit it was a rather odd and macabre set up, but it definitely got everybody's attention.
Here's another example: the competition asked that we demonstrate what-if analyses but didn't specify the application. I figured half the audience didn't even know what a "what-if" analysis was, so in my sample analysis, I put the audience in the shoes of a retail buyer. I asked them to imagine they needed to determine the right product mix between new and existing by performing a "what if" analysis to see the projected effect on gross revenue if you dropped a profitable, but less popular, product and added a less profitable, more popular product.
Ingredient #6: Delivery
You would think that this is such an obviously important ingredient that it would not even need mentioning; but every time I'm involved in a bake-off or some other competitive demo, I see somebody make this fatal mistake: they paralyze their audience with a play-by-play description of every move of the mouse, every cause and effect possible: "Now I'm going to click on this, now I'm going to click here, and then this box pops up." It's brutal, torturous and, worst of all, causes massive audience tune out.
Of course, you need to describe what you're doing, but add some color, and put it in context. Rather than "I'm now going to drag and drop this file onto the workspace," use active language: "Loading data couldn't be simpler, as it's as easy as dragging and dropping files onto the workspace - it's so easy that even a child could do this. And in the background, all of this data is being modeled and loaded into memory - we're simplifying the data loading/modeling experience by getting even the most novice user to the point where they can start exploring and interacting with their data sooner."
When your first start out, you might want to write a script and practice it until you get the hang of this kind of delivery. But once you do, you'll be glad you took the trouble to polish your delivery.
Now that you know the ingredients, it's time to get out there and do some baking. It is well worth the extra up-front time preparing, even if you're an experienced demonstrator, because you may come up with a new idea that will put your demo over the top. Get creative, feel out your audience, react in real time, and be sure to always provide plenty of relevant context.
And if you're looking for inspiration, you can see great demos and even hands-on labs at the Business Analytics Forum at the Information On Demand Conference coming up November 3-7 at the Mandalay Bay in Las Vegas. There should be a whole lotta bakin' goin' on!