Stunningly Awful Demo Evolution - Have You Ever Seen Demos Get Shorter?
When a demo is first created for a new product, it is often short and well-focused. With each successive release, demos get longer as new capabilities and workflows are added. Year-by-year they grow, inexorably…! After several years, demos have accreted multiple layers of demo detritus and can be 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 has this happened and what can we do?
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:
- The founders understood their prospects’ needs clearly and mapped the demo accordingly, and
- The product was rather thin on features – there wasn’t too much that could be shown!
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 9 months or longer? Aren’t these guys supposed to be professional sales people?”
Developers Did It
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 product is released and rolled-out, 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 they enabled. The resulting demos are about as far from focused as one can imagine!
Layers Upon Layers Upon Layers
With each new release, new functionality is added. 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 get added to the old, existing demo.
After all, don’t we want to show the new stuff that’s just been released 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 2 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, inexorably, 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…]
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 before (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 discovery and qualification done. How many times have you seen situations where the demo presented to a prospect appears to ignore the prospect’s needs and situation, even after lengthy discovery or qualification?
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. Re-form the resulting demo chunks into consumable components that can stand on their own.
Find the key take-away(s) for each component (Illustrations) and prepare to present these at the beginning of each component – “Do the Last Thing First”. Sharing the pay-off right up-front engages the audience and confirms that your capabilities represent a solution to that portion of their business problems. This is a terrific way to begin each segment.
Next, with their interest piqued, show completing each task in the fewest number of steps. Take the direct route – just “Do It”. This proves that the capability works properly and builds a vision in the audience’s mind that they can do it themselves. They ask questions and remain engaged while you “Peel Back the Layers” as far as the audience has interest. Close the component with a summary and then – pause – before moving to the next section. See this webinar for more on this approach.
The result? Demos that are configurable, that can be mapped to each customer’s specific needs. Prospects see demos that appear to be customized for their individual situations. Demos are crisp, prospects’ needs are clearly addressed, and the sales process moves forward productively!
Copyright © 2009 The Second Derivative – All Rights Reserved.
Looking for the latest in product and data science? Get our articles, webinars and podcasts.