Stunningly Awful Demo Evolution

Have you ever seen demos get shorter?
by Peter Cohan, Second Derivative

When a company first creates a demo for a new product, it is often short and well-focused. With each successive release that adds new capabilities and workflows, demos get longer. Year-by-year they grow, inexorably …! Over several years, demos accrete multiple layers of demo detritus and can become painfully long, complex and confusing.

The result? Audiences are bored, frustrated and often leave mid-way through, causing sales teams to exclaim, “Wait! Don’t leave! We haven’t gotten to the really good stuff yet!”

Why does this happen and what can we do?

Frustrated founders

Waaaaay back when the company was founded and the product was sparkling new, demos were fairly crisp and focused. There were two reasons for this, typically:

1. The founders understood their prospects’ needs clearly and mapped the demo accordingly.
2. The product was rather thin on features; there wasn’t too much to show!

The resulting demos were correspondingly clear and the (very small) selling team interacting with prospects knew their prospects’ needs and situations. Early adopters embraced the product, and the company grew.

As new people came aboard, they learned “the demo” and were introduced to typical sales situations. However, each new hire suffered a “dilution effect.” Their understanding of the rationale of the software and customer needs grew further and further from the founders’ vision.

As the market moved from early adopters to majority buyers, it grew harder to achieve fast sales. Founders were frustrated: How come I could close business in a few weeks but it now takes nine months or longer? Aren’t these guys supposed to be professional sales people?

It starts with development

As developers create new functionality, they show it to their product management counterparts. The code is often pre-release, but the new capabilities are often very cool. Product managers want to show the new features to the field and do so — carefully following the same pathway that the developer originally presented (since it works, typically, and other pieces of the code may have bugs or not yet be complete). As the company releases and rolls out the product, field sales and presales staff often continue to follow the same demo path (we are victims of momentum…!).

Hmmm … very interesting. Note that the field is now presenting these new capabilities from the developer’s perspective and certainly not the customer’s. Developers want to show all the really cool options they’ve created and the range of possibilities. The resulting demos are about as far from focused as one can imagine!

Layers upon layers upon layers

Each new release adds functionality. More modules, more wizards, more customization, more navigation, more options, more reports … And each new chunk of functionality brings its own corresponding demo pieces that staff adds to the old, existing demo.

After all, don’t we want to show the new, just-released stuff to our prospects? Don’t we want to show them the latest and greatest? And the slightly older stuff is also good, and the release before that has some really cool capabilities and …

What started as a 10-minute demo at version 1.0 grows to 30 minutes, to an hour, to two hours or more. Have you ever heard someone say, “We couldn’t possibly show you our product in less than a half a day …”

The demo grows, relentlessly, release by release, like (choose your favorite metaphor/analogy):

• An oyster, adding layers to its shell each year (hiding the pearl within).
• Sands sifting down to the bottom of the ocean, creating expansive sedimentary rock.
• Onions, growing larger each day, and when cut and exposed in many pieces, you cry!
• [Suggest your own...]

New-hire numbness

If you have recently joined a mid-size or larger software company in sales, presales or marketing, you know this issue: You have an immense amount of information to learn in a short time.

You are sent to on-boarding training, often two to four weeks of detailed exposure to the company’s products, markets, competition, customers and internal processes. At the end of the training, you’re expected to be competent and may have to prove it as part of the process.

Training inevitably includes learning “the demo” for each product. You follow a standard script that walks through the major functions and capabilities, mirroring what your predecessors have done (over and over and over …). Initially, your emphasis is survival — not understanding — so your playback of the demo is rather rote. It may take months or years to become sufficiently familiar with the market, the customers and your offerings, before you feel comfortable to make real changes to the demo script.

The result? Demos that miss the mark, regardless of the amount of research and lead qualification. How many times have you seen situations where the demo appears to ignore the prospect’s needs and situation, even after lengthy discovery or evaluation?

A wordy example

Imagine that you are part of a sales team offering Microsoft Word. What might the “standard demo script” look like? How long would it take to demonstrate the range of capabilities currently available in the product — got a few days?

The traditional approach

The traditional approach to creating standard demos is to create a long, tortured, convoluted story, using a handful of fictional characters to try to tie things together. Demos become training sessions, describing how to navigate the interface, how to customize for specific user types, how to set up records, enter data, run wizards and generate reports.

Intricate interdependencies seek to link disparate parts of the demo together — “Remember the record that we had ‘Jane’ create an hour ago? Now we’ll show how to take that information and edit it as Jane’s manager Jack and then pass it on to John and Jill in marketing and accounting …”

These demos often show multiple ways to accomplish individual tasks (why would a user want to see anything but the fastest possible way?). These demos focus on how to use the software, not what good things the software can do for the customer. These demos are recipes for failure!

An orthogonal approach — Great demo!

Don’t throw those standard demo scripts away, but also don’t inflict them on your prospects! Instead, gently cut the scripts into their component parts. Kill the fictional characters (use your prospect’s real names, instead). Remove the interdependencies. Reform the resulting demo chunks into consumable components that stand on their own.

Find the key take-away(s) for each component (illustrations) and prepare to present these at the beginning of each segment. Show completing each task in the fewest number of steps.

The result? Configurable demos that you can map to each customer’s specific needs. Prospects see demos that appear customized for their individual situations. Demos are crisp, prospects’ needs are clearly addressed, and the sales process moves forward productively!