Thursday, July 26, 2012

Stunningly Awful Web “Overview” Demos – The Gruesome Anatomy of a 1-Hour Web Overview

[Warning – graphic and potentially painful content…]

1-Hour Web “Overview” Demo Timeline

There’s a rough but strangely consistent timeline for a web-delivered “1 hour overview demo” that seems to go like this [starting time for each element on the left side]:

00:00:  Fumbling with WebEx/GoToMeeting/Live Meeting – “Did you get the link?  Can you see my screen?” (This consumption of time has been delightfully called the “WebEx/GoToMeeting/Live Meeting Tax”).

00:04:  Semi-mutual introductions, but generally one-sided:  introductions (and brief personal history of each of the vendor participants), but limited information requested or offered regarding customer participants – and no request to do discovery on the part of the vendor

00:08:  Corporate overview presentation (gag…)

00:18:  Product overview presentation (yawn), including

1.      Obligatory architecture slide(s), with equally obligatory rectangles and cylinders representing software and database components (how novel…)

2.      Obligatory product-centric slide (showing company’s product in the center of a circle of other things (e.g., users, other applications, process steps, you name it – so novel, once again!)

3.      Key “differentiators”, presented without context to the customer’s needs or specific situation (and largely forgotten by the customer, since they haven’t yet seen a solution that makes remembering anything relevant)

4.      Case studies, if any, generally appear at the end and are typically skipped over “because we are short on time…” (too bad – real case studies would be the most interesting part of the overview)

00:28:  “Actual” demo, including

a.      Opening statement that “we need to compress the planned 45 minute demo into 30 minutes “so we’ll have to go real fast…”

b.      Request that “this be interactive, so please stop me if you have any questions…”, followed by a fire-hose-like delivery with no time for meaningful questions

c.       Re-introduction of the offering (again, even though it was covered in the product overview presentation)

d.      Brief introduction of the for plan for a “story” and 3 fictional characters whose “day in the life” will be followed in the demo

e.      Overview of navigation elements…

f.        Introduction and definitions of key vendor jargon, acronyms and product names

g.      Explanation of how to set up and configure the application, which then consumes most of the remaining time (even though this task is typically done once, when first implemented, and then rarely ever after)

h.      A walk-through of the workflow (a run-through, in fact, since time is really getting short)

i.        A rapid, largely verbal description of the canned and custom reporting capabilities (often including the claim that “we have over 600 canned reports…” of which a typical user might consume only 1 or 2…!)

j.        Comment that “we didn’t have enough time to show you everything…”

00:58   Sales person summary, with platitude marketing “value proposition” statements (that have little or limited bearing on the customer’s specific situation)

00:60:  Wrap-up with no action items

Frightening, gruesome and remarkably common!

If the objective was to “show the customer a demo” then that objective was achieved – but it is very doubtful that other tangible progress was made in the sale.  Very sad; and largely a waste of time for all involved.

But Wait – It’s Even Worse…

The pain often starts earlier – and ends later.  Many presales people find they have scheduled (or have been scheduled by someone else) to deliver two or more demos back-to-back.  For teams in highly “transactional” sales situations this can run all day…!

Far too often, one demo runs beyond the time allocated – causing the presales person to be late joining the next web session (“Sorry I’m late…”) and allowing no time to prepare.

Similarly, there’s no time at the end of the demo to document questions, issues or impressions for the presales person before having to dive into the next demo session.  It only takes a few of these in a row to reduce whatever notes might have been captured to a few, often erroneous items!

A Few Recommendations

(Note – these are not necessarily mutually exclusive!  One or more of these ideas can be combined)

0.       Set the WebEx/GoToMeeting/Live Meeting session to begin 10 minutes before the “real” meeting is scheduled to start (not applicable if multiple customer participants are connecting from several remote locations, but truly terrific if the customer participants are in a single conference room).

1.      If you must do a corporate overview, reduce it to one slide.

2.      Turn the call into a Discovery session, if possible (and appropriate).

3.      Reduce the product overview presentation to just the case study slides.  Case studies can be a wonderful way to move the customer into doing Discovery – “here’s an example of how other, similar customers have used our capabilities to solve specific business challenges – how does what they faced compare with your situation?”

4.      Use the Menu Approach (a terrific self-rescue technique), if the audience is a group and/or if your software addresses a range of problem areas.  [See my article entitled, The Menu Approach – a Truly Terrific Demo Self-Rescue Technique for more details.]

5.      Organize the demo itself in chunks – similar to how newspapers and web news services present news articles.  [See my article entitled, Why Structure a Demo Like a News Article for more details.]

And, for those who often are currently scheduled to do multiple demos back-to-back, consider blocking the 15 minutes before and 15 minutes after each demo as “Prep” and “Clean-Up” time on your calendar – give yourself a fighting chance!

Copyright © 2012 The Second Derivative – All Rights Reserved.

Tuesday, July 24, 2012

The Menu Approach – A Truly Terrific Demo Self-Rescue Technique

Have you ever been in a situation where:

a.      You find yourself in front of an audience about which you know nothing of their needs or interests – and they’ve been promised a demo…

b.      You are asked to join a web session, right now, and the sales person says, “They asked to see a demo…”  (again, you have zero information about the customer)…

c.       Someone walks up to you at a trade-show booth and says, “What do you guys do?” or “Show me a demo…”

 Are you interested in a delightful self-rescue technique for situations like these?  It’s called The Menu Approach – and it is a logical, simple and surprisingly effective method for dealing with situations where your audience is partly or largely undiscovered.

Hungry?

Imagine walking into a nice restaurant – and you are quite hungry.  You sit down and a few moments later the waiter comes up to you and asks, “What would you like to eat tonight?”

You have no idea what they offer, so you respond, “What do you have?”  The waiter says, “Well, we have lots of items – appetizers, main dishes, side dishes, desserts – what would you like?”

Very frustrating…!  Clearly, you are both making no progress – and it is very much the same situation as requests for demos where neither party has a clear idea of the other’s desires or capabilities.

A solution?  For our restaurant scenario, the waiter says, “Here, let me get you a menu…”

The menu provides a rapid method for the customer to assess what is possible, what sounds good, and what items or combination of dishes to order.  A menu presents a high-level listing of the range of offerings – and we can apply the same principle to the wonderful world of demos.

The Menu Approach

Back to situation “a.” at the top of page 1, above…  You are in front of a group of 12 people, about which you know very little – and you’ve been asked to present a demo.  Instead of taking the customer on a painful and boring “Harbor Tour”, you start by presenting a list of topics that you believe may be of interest.  For a Great Demo! Workshop, a typical list might look like:

-          Remote Demos – Generating Interactivity
-          Making Demos Remarkable
-          RFP’s and Scripted Demos
-          Storytelling and Demos
-          Managing and Out-flanking Competition
-          Managing Questions and Time
-          POC’s, POV’s, and Sandboxes Tools and Strategies

You say, “Here is a list of some topics we could cover.  Let me describe each one briefly and then I’ll ask for a show of hands – and each of you can vote for as many topics as you wish1.” 

At the end of the exercise, your list now might look like:

-          Remote Demos – Generating Interactivity - 10
-          Making Demos Remarkable  - 11
-          RFP’s and Scripted Demos - 5
-          Storytelling and Demos - 3
-          Managing and Out-flanking Competition - 9
-          Managing Questions and Time - 2
-          POC’s, POV’s, and Sandboxes Tools and Strategies  - 5

You then re-order, to yield a list that is rank-prioritized in accord with customer interest:

-          Making Demos Remarkable  - 11
-          Remote Demos – Generating Interactivity - 10
-          Managing and Out-flanking Competition - 9
-          RFP’s and Scripted Demos - 5
-          POC’s, POV’s, and Sandboxes Tools and Strategies  - 5
-          Storytelling and Demos - 3
-          Managing Questions and Time - 2

Wow!  You now have accomplished several, truly terrific things:

1.      You’ve uncovered the customer’s most important issues (they’re at the top of the list)

2.      You have a road-map for the balance of the demo

3.      You can organize your time to ensure you address the high-importance topics – and it’s OK if you don’t have time to cover everything on the list.

Additionally, you may have also expanded the customer’s vision of what solutions and solution areas your organization provides, as it is possible that the customer was previously unaware that you have offerings across this range of topics.

A Few Subtleties…

When counting votes, remember that businesses are not necessarily democracies – and all votes are not necessarily equal.  For example, if there is one C-level person in the room, and she is the only one who wants “Managing Questions and Time”, that topic moves (magically and mystically) to the top of the list.

Similarly, you can choose to bias the presentation (and subsequent scoring) of topics up or down in accord with your current understanding of the customer’s situation – “Many of the other customers we’ve worked with in very similar situations to what you’ve shared with us so far found that the topic on managing POC’s was most important – they were able to save months of otherwise wasted effort as a result of what they learned…  How many of you are interested in this?”

Finally, when you complete a topic, you can use strike-through text to show that it has been completed, giving you (and the customer) a written record of what was completed and what is still open:

-          Making Demos Remarkable  - 11
-          Remote Demos – Generating Interactivity - 10
-          Managing and Out-flanking Competition - 9
-          RFP’s and Scripted Demos - 5
-          POC’s, POV’s, and Sandboxes Tools and Strategies  - 5
-          Storytelling and Demos - 3
-          Managing Questions and Time - 2

 “Show Me A Demo…”

If you have ever worked a demo station at a trade-show, you are familiar with the prospect who walks up to you and says, “What do you guys do?” or simply, “Show me a demo…” (Clearly, they know not what they ask!).

A solution?  Use The Menu Approach.  You can have your list of topics available on your demo computer or tablet – or consider having a list produced as a poster, laminated, and attached to the wall of your demo station.  You can then simply point to your Menu and begin the same process as above:  

“Here is a list of some of the things we do – let me describe each briefly and then you can let me know which one(s) are most interesting to you.”

Delightful!

Many Great Demo! Workshop participants have reported that The Menu Approach is one of the most effective tools they have used.  The Menu Approach – a truly terrific demo self-rescue tool for situations where your audience is partly or largely undiscovered.



1Often referred to as a “Chicago-style” vote…
 

Copyright © 2012 The Second Derivative – All Rights Reserved.

Tuesday, June 26, 2012

“What’s at Risk?”

In a recent Great Demo! Workshop one of the participant teams came up with the expression “What’s at Risk?” for the Delta label on their Situation Slides – very nice!

Wednesday, June 6, 2012

Why Did They Say, “Oh That’s Cool…!”?

In the delivery of traditional demos, presenters typically note when audience members react positively to particular software screens – and often incorporate those screens in future demos with the expectation that other audiences will be similarly interested.

Seasoned practitioners (and especially seasoned Great Demo! practitioners) not only recognize the importance of those particular screens, but also seek to understand the “why” behind customers’ reactions.

In the course of a demo, when a customer audience member offers an unexpected positive response to a particular software screen (“Oh, that’s really cool…!”), seasoned presales people pursue a dialog that might go something like this:

Customer (reacting to the particular screen of interest):  “Oh, that’s really cool…!”

Demonstrator:  “Great – glad you like it.   Would you share why it caught your eye?”

Customer:  “Sure – this screen solves one of our major issues…”

Demonstrator:  “And what issue is that?”

Customer:  “Well, with our current process, it takes forever to get this done.”

Demonstrator:  “Interesting – how often do you have to run this process, and how many people are involved?”

Customer:  “We’re doing it weekly and it consumes about 10 folks time for an entire day each.”

Demonstrator:  “Wow – so being able to complete process in a few mouse clicks translates to freeing up something like 2 FTE.  You’re right – that’s really cool.”

…And the dialog could continue…

Our objective here is to be able to complete a Situation Slide, essentially, giving us the ability to use the “Oh, cool…!” customer response in a much more focused and leveraged manner for other customers (as well as in our summary at the end of the current demo).

Wednesday, May 30, 2012

Coming Up-to-Speed in Presales – What Works Best?

How long does it take to bring a new hire up to competency/proficiency in a presales role for B-to-B software?  And how do you define competency/proficiency?  What steps/programs have you found to be most effective?

I’ve noted a rather broad spectrum of on-boarding and development practices, ranging from:

-          Sink or swim (no formal on-boarding, training or guided development)
-          Manager-based training, delivered mostly on an ad hoc basis
-          Manager-based, delivered with a structured plan
-          Mentor- or colleague-based (often with a manager as well)
-          Mentor-supported (often in conjunction with other programs)
-          “Boot-camp” training, typically delivered within 3-6 months of the hire date (these are often high-intensity group training sessions running one to several weeks in length)
-          Product Demo Certification
-          Demonstration Skills Certification
-          Periodic incremental/ongoing development delivered ad hoc
-          Periodic incremental/ongoing development delivered on a fixed schedule (often semi-annually)
-          Skills development specifically included as quarterly or annual Objectives or MBO’s

Many organizations employ a combination of these, of course.  What have you found to be most effective for you?

Wednesday, May 2, 2012

Great Demo! Public Workshop

[Warning – shameless self-promotion alert!]

Our last public Great Demo! Workshop took place May 23 in San Jose, California – our next is scheduled for October 10, 2012.  Registration and additional information can be found here: http://www.skmurphy.com/blog/2012/05/23/great-demo-workshop-on-october-10-201/

This is an excellent opportunity for individuals, small groups or for teams that have new hires.

We’ve found that these events are most productive when there are two or more participants from each organization (singletons are also fine). This helps to mimic real-life interactions as much as possible, both when preparing demos and delivering them in the role-play sessions.

Tuesday, May 1, 2012

Why Structure a Demo Like a News Article?

Remember newspapers – the analog version of web-delivered news?

News organizations have been presenting information for several hundreds of years, in print and more lately via the web, and they have learned some highly effective practices that we can employ in demonstrating software.

Structure your demonstrations like a news article.  Here’s why… 

Think about the news articles you read and consider two things:

1.      How you select which articles to read
2.      How the articles are written

Chunks and Consumable Components

Imagine you’ve just picked up today’s newspaper or opened a web news site.  Which section do you turn to or choose first?  In many cases, people immediately select a specific section – finance, entertainment, local, sports, etc.  Readers explore that section and its articles in as much depth as desired, and then move to the next section of interest.

Newspapers (and news websites) organize information in a hierarchy of consumable components – chunks – that can be accessed rapidly, explored as deeply as desired, and then exited at any point to move to the next chunk or component.  The top level of the news hierarchy is the section – sports, finance, international, entertainment, technology, health, comics…  And within each section you know you’ll find articles on that topical area – and on that area only.

Next, how do you choose which article you want to read?  Typically, you scan for headlines or photos that catch your interest.  For many articles, you may only read the headline and move on rapidly – you’re not interested.  Other articles engage your attention sufficiently to review the first paragraph or two, after which you stop and move on.  Some articles you read most of or all the way through because they address a topic of real interest to you.

Each individual article is cleverly organized to enable readers to make rapid decisions about their depth of interest.  The headline presents the topic – providing a binary opportunity for readers to pursue it or move on.  In a well-written news article the first one or two paragraphs summarize the story concisely.  Many readers are completely satisfied with this level of information and read no further, returning to scan for other headlines.

The subsequent paragraphs in an article drill deeper and explore the story in more detail.  Readers who are truly interested in the topic are the typical consumers of this level of information. 

Inverted Pyramid

This article structure and presentation of information is sometimes referred to as the “inverted pyramid” style of writing.  It presents the most important information right at the beginning, starting with the headline and followed by the overall summary of the article in the first few paragraphs.  Material in subsequent paragraphs is more and more detailed and of less importance.  Reading on towards the end of an article we often find the finest levels of granularity and smallest details.

In the bad old days of paper and ink, newspaper editors were able to cut articles to fit the space available (or to sell more advertising) – by cutting from the bottom of the article upwards.  That way they knew they’d be removing the least important information.

News organizations have evolved this “inverted pyramid” method of presenting information over literally hundreds of years.  Why not take advantage of this learning?

I’ll Go Really Fast…

Have you ever run out of time in a demo – and you were unable to get to the “best stuff” because (a) the meeting was cut short or (b) the corporate overview/product overview consumed too much time?

Traditionally, when we are faced with 25 minutes remaining in the demo meeting in which to show a 45 minute demo we try to compress the material: “We are going to move really fast” (while also telling our audience that “we want this to be as interactive as possible, so please feel free to ask questions…”).  Are we surprised when we (a) don’t get through the material and (b) our customer doesn’t ask any questions?

Consider organizing your demonstrations like a news article.  Present a “headline or photo” succinctly and rapidly.  In Great Demo! methodology we call this an Illustration.

If your audience is interested in going further, present the key capabilities using a minimum of mouse clicks – like reading the first one or two paragraphs in a news article.  The audience just wants a summary at this point – not all of the details!  This corresponds to the Great Demo! “Do It” pathway.

Finally, for audiences that are really interested, you can dig deeper and explore the breadth and depth of the relevant capabilities – similar to those who wish to read more of the article.  In Great Demo! we call this “Peeling Back the Layers”.

Interestingly, also note that there are very few readers of the news who read everything in a newspaper or news website – similarly, you are not obligated to present everything that your software can do...!

News organizations present information in a hierarchy of consumable components, using the “inverted pyramid” organizational structure – why not apply the same ideas to your demos?


[If you'd like a copy of this article to send onwards to others, simply send me an email at PCohan@SecondDerivative.com and I'll send you a PDF copy]

Monday, April 2, 2012

Demo Data – A Tough Nut

How can one set of demo data serve a broad range of customer situations and verticals?  (It may not be possible…)

Presales and sales team often struggle with how specific data needs to be for their customer demos.  Demo data often ranges from highly generic, to moderately focused (on specific markets or verticals), to data that that is highly specific for certain areas.  At the far end of the spectrum are POC’s and/or POV’s where the customer requires the use of their data in the experience.

Some demo teams invest a fair amount of up-front effort to generate meaningful data and corresponding forms, table-views, dashboards and front-ends.  Others invest in a “neutral” set of data and screen labels, which may offer less convincing results, depending on the software and the market.

The most successful approach I’ve seen to-date, when possible, is to have a fairly neutral set of data, but ALSO include the ability to configure or customize the screen labels and field names to map to specific markets/segments.  This may require some level of programming to achieve, but the payoff can be high.

Note that there are companies that provide pseudo-random data for QC purposes that can be used by demo teams to create reasonable example data sets. 

Any suggestions or experiences that might help with this?