Public Great Demo! Workshop – April 12

[Warning: Shameless Self-Promotion Alert!]

Our next Public Great Demo! Workshop is scheduled for April 12, 2011 in San Jose, California, co-sponsored by SKMurphy (www.SKMurphy.com). This is a terrific opportunity for individuals or small groups to learn how to put Great Demo! ideas into day-to-day practice. An overview, agenda, location and pricing information is available here: www.skmurphy.com/blog/2010/11/30/great-demo-workshop-on-april-12-2011/

Is There a “Grand Unified Story Theory”?

Many managers ask their teams to “wrap a story” around their demos – and many teams struggle to find and use stories that meet this requirement. One tactic is to use a “day-in-the-life” as the story to bind together a range of tasks, functions and, potentially, multiple job titles.

The end result is not really a story, but is simply an organizational framework – and as such it fails to engage interest. How could it? How exciting is it, after all, to hear about executing one’s day-to-day job?

It may be, in fact, unlikely that a real story can be wrapped around most demos (there may be no “Grand Unified Story Theory”…!). Stories are often most effective to serve as punctuation, as reinforcement, and as alternative mechanisms for making ideas stick.

[More on Storytelling for Demos shortly…]

One Picture Is Worth 1000 Clicks

I often describe Illustrations (the “Wow!” or end-deliverable in Great Demo! methodology) as in terms of the classic statement, “One picture is worth a thousand words”.  At a recent Great Demo! Workshop, one participant cleverly commented that “One Illustration is worth a thousand clicks”!

Scripted Demos – Another Method of “Gentle Subversion”

Many customers require that vendors follow their scripts step-by-step, even if the logic and flow aren’t particularly logical for the vendor’s software. This often results in long, frustrating demo sessions for vendors (and customers as well).

In addition to the other tactics suggested previously, here’s another method to consider: Follow the customer’s script and demonstrate each proof point in accord with the script, initially – however, if/when your customer begins to get comfortable with you and your offering (and if you have earned sufficient credibility), you can consider asking to change some sections to enable to better flow (for the customer’s sake, of course) and better visualization of the capabilities they’ve requested (for the customer’s benefit, of course).

In the worst case, your customer simply says, “No”. In the best situation, they say, “Sure” – and you are able to re-order and rearrange your demo in accord with your interests. If you do make changes, be sure in each summary section to identify which capabilities were covered in that section (“We just showed you items 401, 402, 403, 404, and 452 – are you comfortable that we handled these sufficiently?”).

Show Up and Throw Up

Traditional “educational” or “informational” demos are often known by less favorable names (for good reason), including:

- Show Up and Throw Up
- Spray and Pray
- The Harbor Tour
- Living in the Land of Hope

Here’s a new one I just heard: The "Tech Splatter" demo.

Any others?

Public Great Demo! Workshop – April 12

[Warning: Shameless Self-Promotion Alert!]

Our next Public Great Demo! Workshop is scheduled for April 12, 2011 in San Jose, California, co-sponsored by SKMurphy (http://www.skmurphy.com/). This is a terrific opportunity for individuals or small groups to learn how to put Great Demo! ideas into day-to-day practice. An overview, agenda, location and pricing information is available here: www.skmurphy.com/blog/2010/11/30/great-demo-workshop-on-april-12-2011/

Build vs. Buy – Handling the “We could build it ourselves...” Objection

Here are two approaches I've used very successfully (and seen used very successfully) in battling "build vs. buy" situations:

1. People love to write new code, but hate to QA, support and maintain code already written. You can drive this point home by outlining the customer support calls (and hours) required to help customers (internal or external) use the application; and by the pain and suffering of keeping applications current with the ever-changing versions of Windows, Java, IE, Oracle, etc.etc.etc. and doing the ongoing testing to confirm (yuck). The hours of doing this "not fun" work can help tip the balance to a vision of "using the framework provided by the vendor to create the really interesting stuff internally, and outsource the ugly maintenance and support stuff to the vendor...".

2. Paint a REALLY big picture of "typical" requirements... You can point out, for example, that there are “ten years of development” in your application(s), done (most likely) by dozens of developers and QA folks. The list of features and functions in your offering(s) is likely REALLY long, particularly for comparatively mature products. List the features and functions in their full (gory) length (could be pages of features) and comment that "this list is only those functions required by customers - you should see the ongoing wish-list as well!". The idea here is to make the development project appear to be WAY too large to contemplate for a customer’s small team of developers...