Don’t Let Perfection Be The Enemy of Great

Just heard this paraphrase of the classic Voltaire quote (“Don’t let perfection be the enemy of the good”) in a demo.  The customer was very interested in the offering, which clearly offered terrific value, and asked about capabilities net yet implemented.  The presenter responded, “Don’t let perfection be the enemy of great” as a way of telling the customer that the offering in its current form would make substantial improvements to the customer’s process and bottom line – and to move forward now rather than waiting (potentially forever!) for additional capabilities that might make it better…

“Stalker” Demos

Just heard this phrase in a recent Great Demo! Workshop:  “Stalker Demos”.  Loosely translated, it amounts to “If you don’t agree to purchase after this demo, we’ll come back again – and again – and again – and we’ll keep delivering demos until you cave in…!”

This is amusing at one level, but it is based on situations where an initial demo didn’t go well – often because the initial demo was a Harbor Tour or Show-Up-and-Throw-Up Demo – causing the vendor to request doing another, “better” demo for the customer.  Given that there are only about 220 “selling” days per year, repeating a demo meeting represents a large opportunity cost. 

I suspect that many of us have or had parents who offered the advice, “Measure twice, cut once”.  Insufficient preparation, especially with regards to performing adequate qualification and discovery, can yield these “Stalker Demo” results!

Story-telling and Demos: The Hero

As I’ve remarked previously, story-telling can be an extremely effective method to communicate key ideas – and stories can be particularly “sticky” with respect to audience memory and retention.  An additional story-telling concept is the use of a hero – someone (or something) that the audience can identify with.  Traditional stories (e.g., sagas) typically have a hero that encounters and overcomes trials and adversity before achieving success. 

For demos, heroes can take a number of forms:

- Customer (an individual):  the customer can be portrayed as the hero (very effective!), with the payoff being the timely and on-budget completion of a project, accolades from colleagues or a promotion.  In my own experiences, it was gratifying to see customers I’d worked with over a period of years move from staff members to middle managers to senior and C-level management.

- Team (a customer team or group):  The logical corollary to an individual, a team can be presented as the hero in a story.

- Product:  your software can be the hero, similarly, enabling a customer to achieve their objectives in spite of (apparently) overwhelming challenges.

- SaaS:  Interestingly, the “cloud” can be positioned and perceived as a hero – “when our  own servers went down, we were still able to complete the project thanks to the ability to access the vendor’s software from the cloud…”.  I’ve heard a number of examples where the cloud is the hero, in addition to the one above:  access to key information via collaboration tools or capabilities, disaster recovery (“and we were able to get back up and running just in time for the opening…”). 

Any other hero types or ideas to suggest?

“Demo Day” Sessions

Many Great Demo! Workshop principals and participants ask what they can do to keep the implementation process moving forward, after a Workshop completes.  One simple (and surprisingly effective) tactic is to do a “Demo Day”.  This is an extension of the role-play sessions practiced in the Workshop, where each person or team presents an 8-10 minute demo to the overall group, followed by feedback and discussion.  This reinforces the key concepts and surfaces new tips and best practices – and is a highly valuable exercise whether or not the team has had the pleasure of participating in a demo skills Workshop.

I typically suggest allocating about 30 minutes per role-play to give sufficient time for the demo, feedback, technical glitches and break time.  In a half-day session you present and review 8 demos easily.

A Demo Day is something that teams and principals can do on their own or  [warning:  shameless self-promotion alert!]  have someone who is highly skilled in teaching and coaching demo practices facilitate – me, for example! 

Having Your Champion Drive – Interesting Variant

I often suggest having your customer (or more specifically your Champion) drive for portions of a demo.  This changes the entire dynamic in comparison with traditional demo meetings, making things different and very engaging.  I also recommend reducing any risks by working with your Champion and practicing beforehand so that both you and your Champion are comfortable.

A wonderful  alternative to this is to have your Champion narrate while you drive – this may be the next best thing to having the customer drive, but with (substantially!) reduced risk.  Try it!

Introducing the Demo - Like the Evening TV News

A number of Great Demo! Workshop participants have enjoyed good success in positioning “Do the Last Thing First” by drawing an analogy with the evening TV news.  They tell their audience that “We are going to start, like TV newscasters do, by going you the headlines for each “story” so that you have an outline of the overall demo.  Then we’ll go into each “story” section in more detail.”

Customers apparently understand and appreciate this analogy – it resonates!

Testing Web Collaboration Tools – While Doing Discovery

Many sales teams find that their customers are (still) unfamiliar with web collaboration tools (e.g., WebEx, GoToMeeting) or have not tested the tool before a scheduled vendor demo – resulting in fumbling, lost time and (sometimes) having to reschedule demos.  In addition to the several other ideas already offered in this forum, here’s another (very clever) one:

One Great Demo! Workshop participant recently noted that he sets up a web session for his discovery calls.  In addition to having the session open and available for any discovery needs (e.g., Menu Approach, Workflow Analysis, etc.) this is a subtle way to test the technology before any demo is scheduled.  Very clever!

Remote Demos – Who’s There?

Consider typing the names of the audience members on the screen (use a white board, PPT, or Word document).  This confirms who is actually present, engages the audience and gives you an accurate list as well – audience members will often correct any spelling errors for you!

Product Overview Presentations - Like Having a Brochure Read to You

Many demos are preceded by 1) a corporate overview presentation and/or 2) a product overview presentation.  Leaving the horrors of typical corporate overviews aside for the moment, it just struck me that watching many product overview presentations feel a lot like having someone read a product brochure you…  A recent product presentation I watched took over 30 minutes (before the demo) and reviewed the company history and mission statement (again, even after it was introduced in a corporate overview presentation!), then walked through the history of the problem/shortcomings of the existing technology, technology Bottlenecks, the product technology itself (how it works) including details of architecture and environment, typical numeric results, security, integration options (SDK and API’s) and finally deployment. 

The customer was quiet throughout the entire 30 minutes – no interaction.  It struck me that this was like having the product brochure being read to us!

Stunningly Awful SaaS Demos – Lost in the Clouds

What are the challenges of presenting SaaS offerings vs. “traditional” or “on-premise” software products?  SaaS demos present specific opportunities for disaster – several of which are outlined in this installment of Stunningly Awful Demos…

It’s the Same, Only Better – Let Me Show You…

Many vendors work to differentiate SaaS from traditional offerings, in spite of often positioning SaaS offerings as providing the same functionality as their traditional behind-the-firewall counterparts. Many demos attempt to show these 1:1 comparisons in gory, boring, painful detail – with negative results (including but not limited to):

-          Way too long, way too boring, ran into bugs, made the simple look complicated, opened the opportunity for damaging questions, key players left early, and on and on.

It’s Slow Today Because…

How often have you heard this phrase?  Customers assume that whatever environment you use for your demos is better than their infrastructure (have you ever heard a customer say, “Our network is blisteringly fast?”).  What they see in a demo is the best they typically expect the offering will perform in their own hands.

To add to this, customers are already concerned about performance when operating SaaS products over the web. Demos need to take this rather strongly into account to minimize clicks and other performance-related challenges.

No Plan “B”

And, of course, don’t capture screen shots of your key screens so that if you have no internet connection you are unable to show anything…!  God forbid you’d have these stored in PowerPoint or Keynote as a backup plan…

iPhone, iPad, iCloud, iAndroid, iBlackberry, iSmart

Customers expect to see a broad range of devices supported by SaaS product vendors, including “traditional” PC’s and Macs, iPads and other tablets, and a range of smart phones. New practices need to adjust and reframe demos to address this.

Demos done solely on a laptop may lack sufficient depth of proof for many customers – and emulators are OK, but they miss opportunities to use iPhones and iPads (etc.) as props and to put the product in customers’ hands (changing, wonderfully, the whole demo dynamic).

Getting “Social”

“Social” is an additional challenge for some SaaS demos…  Customers may want SaaS offerings to integrate with and/or feed a range of “social” tools (e.g., Twitter, LinkedIn, Facebook, etc.).  This adds more complexity in demo preparation and delivery.  There is even an entire cadre of “social aggregator” tools designed to help address these efforts, including EventBox, twentyfeet, Flock, friendfeed, youmeo, ping and a pile of others.  

[Some of the names of these tools are really fascinating, for example: Twitter Tools, Twhirl, TweetBeep, TwitBin, Twidget, TwitterBerry, and Twittalator Pro. Gad!]

Vendors that offer these capabilities are often only too happy to show them in their standard demos – is this a good thing?  Perhaps – but only if the customer views them as Specific Capabilities they need to address their problems. 

Vendor Vocab

If you want to confuse your customers, try verbalizing a variety of vendor vocabulary terms.  Here is a set to draw from, as a start – be sure to add your own company-specific terms and acronyms to further increase the perceived complexity.

-  Cloud, cloud-based, in-the-cloud, cloud-burst

-  On-premise, traditional, installed, behind-the-firewall

-   On-demand, hosted, ASP, multiple-tenant
-   SaaS, PaaS, IaaS, AaaS

Ignore F11

Most SaaS software is accessed (and demonstrated) via web browsers.  In day-to-day use of browsers, many demonstrators use a range of toolbars (Google, Bing, Favorites, Command Bar, etc.) to provide them with quick access to a range of capabilities.  These toolbars, however, consume screen real estate and may confuse audiences.  Stunningly Awful SaaS Demos ignore this…

Tapping F11 (in many browsers) hides these toolbars, devoting the maximum possible screen real estate to your application and reducing apparent complexity. Simple and effective!

The Latest (And Greatest)?

One advantage of SaaS offerings is the ability to deliver releases nearly continuously, as opposed to traditional processes of large, comparatively infrequent releases (often followed by “X.01” releases that address problems found with the last large release!). 

The corresponding disadvantage for presales and sales teams is staying on top of this release flow.  SaaS demos often show the latest, greatest releases and functionality – which increase the risk of encountering bugs, surprise when the “old” workflow has been changed, and confusion when capabilities have changed. 

Stunningly Awful SaaS Demos ignore testing the latest release environments or doing a dry-run of the demo ahead of time.  Feeling lucky?

Wait – Don’t Buy This Yet!

A dangerous corollary of the above is the knowledge or expectation that capabilities not yet released will be available shortly.  How often have you seen a purchase delayed by a misspoken comment or promise along the lines of, “Oh, that capability will be in the March release…” – to which the customer responds, “Terrific, then I’ll hold off buying until March…!”

Mismanaged Migration

What about upgrading existing on-premise customers to SaaS versions? 

Many sales teams assume that customers will want to make those migrations right away (and pay for the “added value” of SaaS).  Stunningly Awful SaaS Demos occur when it turns out that the customer is perfectly happy with their current on-premise implementation and do not perceive a sufficient driving force to move to the SaaS offering – there is no compelling reason to change.

This is exacerbated when demos delivered after insufficient discovery show that key functionality, in heavy use today by the customer, is not available or is insufficiently implemented in the SaaS version.  Ick.

Interestingly (and especially sadly), some of the key capabilities lacking in the new SaaS versions are often amongst the most important for customers – reporting tools and other output capabilities, for example.  These are (sadly again) often the last capabilities to be implemented in SaaS release rollout.  Double ick.

 
“Configure, Not Customize”

Have you ever heard this mantra chanted by sales teams?  “Our offering is configurable and doesn’t require custom development to implement customer-specific needs”.  That’s great.

However, vendors often spend the first 10 minutes of Stunningly Awful SaaS Demos showing the broad range of configuration options – well before getting to the end deliverables desired by the customer.  Bear in mind that many (most?) customers configure the offering only once, when it is first implemented!

Hijacked By IT

The demo was going great… and then an IT person asked, “What browsers do you support?”  The answer to that question prompted the IT person to follow-up with, “And Java?  What level of Java is needed?  Flash?  CCS?  HTTPS?  SOAP?  REST?  Multiple tenant...?” 

Instead of “parking” the question for later, the presenter answered each question in detail, getting dragged deeper into a hole and moving farther from the main issues that the key customer players were interested in – and then they left the meeting room…!

Input – But No Outgo?

Many new SaaS offerings focus on the operations a customer can apply to their data or the associated workflows.  A typical weakness for newly released SaaS offerings is the lack of sufficient capabilities for reporting or exporting the results. 

To paraphrase a terrible old TV commercial, “You can check the data in, but it can’t get out…”

Login Logorrhea

Many customers have concerns about the security of their proprietary information in vendor SaaS applications.  Rather than address this as a part of Q&A (where it typically belongs), Stunningly Awful SaaS Demos consume the first few (key) minutes of a demo detailing the login process, security arrangements, and customer data protection provisions. 

This is a great approach if the team is presenting to IT (alone), but bores the heck out of business users – and consumes the few minutes that high-level executives are willing to invest in a demo meeting.  Unless it has been identified as a key issue by customer management, save it for later in the meeting…!

Interesting (Good) Examples of Online Demos

The folks at Spotfire (Tibco) have created an interesting set of online demos at http://spotfire.tibco.com/demo/default.aspx worth exploring.  Typical online demos often try a one-size-fits-all strategy, which fails in many situations (since we aren’t one-size-fits-all customers).  Spotfire has created a flock of example demos (~60) for a range of industries and application areas, endeavoring to enable customers to focus on reasonably specific topics and challenges. 

Further, the demos are not canned recordings, but are live (bounded) versions of the offerings, enabling customers to dynamically explore the demos and associated capabilities.  There is, of course, some risk in this – that customers will not figure out how to navigate through the demos, but the use of some text descriptions (along with brave clicking on the customer’s part) largely addresses this issue.

Overall, an excellent job in providing appetizer-level examples of Spotfire’s capabilities – and potentially a great template of an approach for others.

Stories and Demos – Demo “Capital”

I often suggest that presales teams get together on a regular basis to share tips, best practices, and new ideas (these gatherings are sometimes called “Demo Days”).  The collection of knowledge, skills, and infrastructure is referred to as Demo Capital – an extremely valuable resource for a vendor.

One additional element of Demo Capital to contemplate is stories.  Stories used in demos that have proven to be particularly successful should be shared – and reused – within teams.  Consider including a “storytelling” segment in your next Demo Days event.

Remote Demos – Screen Resolution Statistic and Tip

A quick survey of the people who browse our website (www.SecondDerivative.com) shows the following screen resolutions:

1280x800 – 28.80%

1440x900 – 21.76%
1024x768 – 19.74%
1366x768 –   9.47%
1600x900 –   6.88%
1115x697 –   6.06%
1920x1080 – 2.13%
1600x1200 – 5.17%

This suggests that the lowest common denominator for screen resolution for Remote Demos is (still) 1024x768… 

And, of course, one can always employ the “can you see my mouse in the upper left-hand corner; can you see my mouse in the lower right-hand corner” method to confirm that you audience is seeing your full screen.

SaaS Demos – Getting “Social”

Being “social” is an additional challenge for many SaaS demos…  Customers often want SaaS offerings to integrate with and/or feed a range of “social” tools (e.g., Twitter, Facebook, etc.).  This adds more complexity in demo preparation and delivery.  There is even an entire cadre of “social aggregator” tools designed to help address these efforts, including EventBox, twentyfeet, Flock, friendfeed, youmeo, ping and a pile of others. 

[Some of the names of these tools are really fascinating, for example:  Twitter Tools, Twhirl, TweetBeep, TwitBin, Twidget, TwitterBerry, and Twittalotor Pro.  Gad!]

Any thoughts on best practices in this regard?

SaaS vs. Traditional Software Demos

What are the challenges of presenting SaaS offerings vs. “traditional” software products?  I’ve been looking into this and note the following three major challenges (at least):

-          Vendors are trying to differentiate SaaS from “traditional” offerings, in spite of messaging that says that the SaaS offerings provide the same functionality as the traditional behind-the-firewall products.  Many of my (vendor) customers note that changing the way they demo has strongly helped SaaS positioning and uptake.

-          Customers are concerned about performance when operating SaaS products over the web.  Demos need to take this rather strongly into account to minimize clicks and other performance-related challenges.

-          Customers more and more expect to see a broad range of devices supported by SaaS product vendors, including “traditional” PC’s and Macs, iPads and smart phones.  New practices are needed to adjust and reframe demos to address this.

Other thoughts?

Storytelling and Demos: Imagine…

Connecting with your audience is a key part of storytelling and, interestingly, the mode of delivery can have a large impact on the audience’s reaction.

For example, a story about the trials and tribulations of a 3^rd party can generate some empathy: 

    “He was so surprised when he didn’t get the order…!”

A stronger mode of delivery is to present in first person: 

    “I was so surprised when I didn’t get the order…!”

Potentially even more compelling is to present the story in the mode of “imagine this happening to you”: 

    “Imagine how surprised you would be when you didn’t get the order…!”

Storytelling and Demos

Stories can be one of the most effective mechanisms to help your customers understand the use and value of your offerings.

Stories engage, illustrate and underscore in ways that facts and features cannot.  We have a particular propensity to remember stories – most people can reasonably accurately retell stories that connect with them – days, weeks or even months after initially hearing the story.

It is fascinating to watch an audience’s reaction when you offer to tell a story.  When you ask, “Are you interested in the true story of how this happened?” people lean forward in their seats and their attention level rises markedly.  We are somehow programmed to be interested in hearing stories and audience body-language reflects this.

“Wrap a Story Around Your Demo…”

Is there a “Grand Unified Story Theory…?”  Many managers ask their teams to “wrap a story” around their demos – and teams struggle to find and use stories that meet this requirement. 

One unsuccessful tactic is to use a “day-in-the-life” to bind together a range of tasks, functions and 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 to hear about executing one’s day-to-day job? 

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

What Is A Good Story?

“I’ll know pornography when I see it…”  This is a great example of how subjective “good” vs. “bad” can be.  With stories and demos, however, you are working to communicate key messages.  A “bad” story is anything that doesn’t get the job done.

Here is a simple test:  Good stories get retold; others don’t.  If stories you relate in demos aren’t retold by your audiences then they weren’t successful.  Similarly, if your audience is not actively engaged while you are relating your story, it is not getting the job done.

We know good stories when we hear them – they often cause us, as audience members, to respond with a “Wow…!” or “Hmmmm…!” reaction.  A good story may trigger us to tell one of our own stories in response.

It is tough to dissect the key elements of a good story, but these five attributes can serve as a starting point:

Simple Message:        The concept or message needs to be clear and easy to understand
Real Experience:        It has to be believable and perceived as being true
Element of Surprise:  An unexpected twist, event or outcome generates interest and tension, which then demands release
Evokes Emotion:       The best stories are those that generate an emotional from the audience
Relevant:                   Good stories relate directly to the subject or key point

Simple Message

In Great Demo! Workshops, I often use stories to illustrate the concept of the Specific Capabilities needed by a customer to solve a business problem.  There are typically tons of features and functions available in most software offerings, but it is just the few Specific Capabilities the customer actually uses to complete typical tasks.  Specific Capabilities is (hopefully) a very simple idea.

A second example is embodied in the recent merger of United and Continental Airlines.  Jeff Smisek, President and CEO, is presented in a brief video describing the status and advantages of the merger, immediately before the obligatory “Safety Video”.  If you have flown on either airline in the past several months you’ve likely seen the video (perhaps many, many times!). 

Towards the end of the video, he says, “We want to provide clean, safe, reliable travel, great customer service, and a broad range of flights and destinations.”  His message is not simple; it is broad and unfocused, and is hardly memorable.

Conversely, when you think of Southwest Airlines, what do you think of? 

[Hint:  “The low-cost airline”].  Simple.

Real Experience

Why do customers go to users’ group meetings?  (In addition to the free drinks from vendor sales people, of course…!)  They go to hear how other customers have addressed challenges or solved problems using the software.  The stories they share are perceived as real, based on actual experience, and are therefore highly valuable.

Along the same lines, stories presented by vendors need to be perceived as real to have solid impact in a demo meeting.  Often, the best stories are (therefore) those about how other customers solved problems that are the same or similar to what the current customer is facing. 

Conversely, the weakest stories may be about the vendor sales team’s personal experiences.

Element of Surprise

Memorable movies have numerous plot twists and turns – stories that offer a non-obvious surprise tend to engage and are more effectively remembered.  Stories that are too predictable may be less interesting.

Elements of surprise can come from a range of possibilities:

-          Turning a well-known phrase upside down:  “Snatching defeat from the jaws of victory.”
-          Presenting an unanticipated result:  “Resulted in the loss of $245K annually.”
-          Offering an excepted process or approach:  “Turn traditional demos upside-down.”

Evokes Emotion

To connect strongly to a story, the audience needs to feel an emotional impact – it should resonate with them as a shared experience or situation.

A child comes home from school and reports to his parents, “Everyone did really poorly on today’s math test…”  Most parents immediately respond, “Well, how did you do?”  The parents don’t care about the balance of the class – there is no emotional connection – but how their child performed is critical.

To introduce the idea that “We Are Programmed to Forget” I offer an example situation:  “Have you ever arrived at the end of a drive that you take frequently – to the store, to school, to the office – and you suddenly realize that you have no recollection of the drive itself?  You essentially were on ‘autopilot’…” 

For many people, this evokes emotional responses of wonder, self-aware surprise, and a certain degree of discomfort.  At the same time, the realization that this appears to happen to most everyone is reassuring.

An emotional connection makes the story that much more meaningful and personal.

Relevant

Stories need to be perceived as relevant or their impact drops precipitously – stories need to resonate with audience.

A customer in the commercial banking industry won’t consider a demo that uses data from a manufacturing scenario as credible – he perceives it as too distant from his situation.  Similarly, stories need to be aligned with how customers view themselves and their situations.

When discussing Remote Demos, I often offer a story in which a rather embarrassing email preview message appeared during a webinar.  The message described plans for a date that evening – in rather graphic terms! 

While the specifics may be different, many people have seen or suffered from similar situations – and the story resonates and has strong relevance.

Leveraging Well-Known Stories

Relating ideas in your demo to well-known, existing stories can be simple and very effective.  For example, can you identify the movie from these examples:

-          “These are not the droids you seek…” [The movie?  Star Wars. This line is often offered immediately after a bug appears in a demo…!]
-          “He chose…poorly…”  [Movie?  Indiana Jones and the Last Crusade.  Usage?  Ah – so many possibilities!]
-          “I…can’t…help…it…”  Bxzzzzzzt!  [A Bug’s Life. Usage?  Explaining how and why the “B” key in PowerPoint works.]

Each of these (hopefully) references and draws upon our previously stored memories of stories already in place.  This can be a great strategy, particularly when trying to draw analogies or find examples.

Example Story – Ease of Use

My old boss, the head of sales of a software company, was (surprisingly) such a novice with computers that he always typed messages with CAPS LOCK on because using the SHIFT key slowed him down and caused many (embarrassing) errors. 

We used him for a demo of a new tool we were working to purchase, asking him to “drive”, as there was concern by some team members about ease-of-use.  We walked him through the few steps it took to generate his forecast for the quarter.  He then said, “Wow, if I can do this then I’m sure everyone else can as well…!”

What better way to prove ease-of-use?

[For the “analytical” types reading this article, I’m sure you just did a quick check of this story to see if it includes the attributes described above:  Simple Message, Real Experience, Element of Surprise, Evokes Emotion, Relevant.  How’d we do?]

Example – Painfully Boring

The following was related to me by someone who was present… 

About 40 minutes into a particularly boring demo a customer (senior manager level) got up from the conference table, walked over to the wall and started to slowly bang his head on the wall – and continued to do so for several minutes until, at last, the person delivering the demo looked up and asked if anything was wrong…!

When to Use Stories

Audiences need to be “refreshed” frequently.  Use stories to re-engage people when they begin to fade (e.g., after lunch or when someone gets up from the conference table and starts to move towards the wall…!). 

Apply specific stories to reinforce or illustrate key advantages of your offerings.  A quote I often hear is, “Facts tell, stories sell!” 

Use stories as a transition tool to introduce a new segment or wrap-up a segment.  Stories add another “thread” to an important point or idea to help embed it in customers’ minds.

Storytelling and Demos

Good stories serve to punctuate key points and help make your demos memorable and remarkable.  Causatively collect them.  Experiment – try out various stories for a range of situations.  Test and refine – and then share what works with your peers.  After all, they’ll want to hear a good story as well!

Bonus:  Share your most interesting, most painful, or most enlightening stories with us (send to PCohan@SecondDerivative.com) and we’ll reward the top three (in our humble opinion) each with a highly coveted and enormously useful Great Demo! laser telescoping pointer. 

Copyright © 2011 The Second Derivative – All Rights Reserved.

Taking Advantage of the “Dip” – To Hide the Ugly Stuff…!

Several Great Demo! Workshop participants report applying the principle of the “Attention-Retention” curves (aka the “Primacy-Recency” effect and/or the “Serial Positioning Effect”) to hide portions of their software that aren’t as strong or don’t demo well.  They realize that the ability for audiences to remember the middle portions of a segment is severely diminished in comparison to the first and last few items.  Interesting!

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...