I just came back from a three-day conference and trade show on legal technology, called, appropriately enough, LegalTech. I saw awful demo after awful demo, along with a few decent ones.

(For the record, in this post I’m excluding a number of demos that were one-on-one by people who knew me. That’s an entirely [...]]]> I’m demoed out.

I just came back from a three-day conference and trade show on legal technology, called, appropriately enough, LegalTech. I saw awful demo after awful demo, along with a few decent ones.

(For the record, in this post I’m excluding a number of demos that were one-on-one by people who knew me. That’s an entirely different matter, with different rules.)

The Single Worst Demo of LegalTech

I won’t name the vendor; I actually like many of their products. However, they hyped their newest product by urging people to gather — standing — in a private room and watch a ten-minute presentation projected on a long wall, with some interaction with live actors and musicians. After ten minutes, I had no better idea of what the product was, who it was for, or why it was better than either their previous version or their competitors’ products.

I’m not sure it qualifies as a demo. However, they had folks all over the show floor and hallways urging people to see the “demo,” so I’ll take their word for it. I talked to a few other folks in the room with me at one particular showing, and they largely expected a demo too.

If I had to speculate, I’d guess some marketing guru read The Presentation Secrets of Steve Jobs and missed the point: it’s not about presentations, it’s about presenters! There was no presenter here; it was an unfortunately empty son et lumière show.

I eventually did get to see the product itself, and it wasn’t bad but wasn’t revolutionary either. There was a great value case to be made around the new version, but they spent a lot of money to not make it. (On the other hand, they did keep name recognition high, and the folks who use their product will figure out the value of the new version quickly enough.)

Percentage of Booths Where I Couldn’t Tell What Problem They Were Solving

At least 25%. If you eliminate the three largest classes of software in this market — matter management, document management, and electronic discovery services, where every attendee knows the problems they purport to solve — this percentage was at least 50%.

Half the vendors who needed to tell attendees what they did failed to do so. That would have astonished me if it weren’t so much the case at most other shows too.

If you cannot describe the problem you solve in a single headline and/or graphic image, it’s probably a marketing failure… but it could also indicate that you don’t understand the problem, that you’ve built a solution in search of a problem.

Biggest Missed Opportunity

I say this about any trade show at which printer vendors exhibit. Offer to print out my boarding pass! No one wants to stand in yet another line at the airport, and at many hotels it’s hard to get something printed or attendees are too busy at night to hassle with it.

Print my boarding pass, and frame it on a page touting the value of your printer. You know darn well that attendees will toss most of the literature before they board the plane, and most of us are smart enough to avoid picking the stuff up in the first place if we’re not really interested. But you can’t throw away your boarding pass until the plane takes off, and you have to have it out multiple times to look at it.

This is a short-term opportunity, probably, since within a few years most airlines will make it possible to flash your cell phone at a reader to confirm your boarding assignment. But for now, it’s the best way to get me to your booth! No one goes to a show like LegalTech looking for printers; here’s a super-cheap way to (a) get people to your booth and (b) show off the product.

Number of Demos in Which I Could Clearly Hear the Demoer

Zero for those in the high-traffic areas of the show.

If you’re in a backwater, people can hear you because there isn’t much traffic, but the goal is both traffic and attention. If you’ve paid your dues and your cash — it takes both — to get a good location, either hire demoers who can project properly — acting training might help — or get some speakers and microphones to subtly enhance your voice.

Granted, my ears aren’t the best… but that’s a common ailment as we get older. And age has a rough equivalence with purchasing power and influence.

I watched others to see if they were hearing more clearly. By the strained looks on their faces, even those with good ears were struggling.

Even if you’re doing a one-on-one demo, speak loudly enough so that others walking by can hear you and perhaps get caught up in what you’re doing. Customers are where you make them. Serendipity matters.

Percentage of Demos That Began With a Problem Statement/Context

Maybe 10%.

More than half the demos I saw were afflicted with severe feature-itis. Benefits beat features (even for techies), and problem-solving beats benefits. Identify the problem and its context immediately and astonish us with how perfectly you’ve solved it. By the way, that’s the real message in The Presentation Secrets of Steve Jobs. Jobs always presents a clear context for his product introductions, even if he doesn’t make it obvious that this is what he’s doing. It’s a useful book; I wish more demoers — and conference speakers — would read it.

Two Nice Demos That Would Have Been Enhanced by More Context

I absolutely loved the way that Lexis/Nexis, a legal search-and-more tool, is integrated into Microsoft Outlook and Word. I spent years cajoling vendors into doing that, with limited success in the early aughts or whatever you call the first decade of this century. There was plenty of evidence that users wanted to do their work within Outlook and Word, their normal haunts, and that such integration was a huge factor in adoption. Unfortunately, although Word integration was easy, Outlook integration was — and remains — extremely difficult. Lexis/Nexis has figured it out… or, more accurately, convinced Microsoft to help them do it in partnership.

They did a separate-suite demo for perhaps a dozen people at a time, with a bright and shiny marketing VP doing a 20 minute spiel-and-demo. (Someone else was running the mouse, which is a good idea in these kinds of demos.) She touted the tight integration, showed all the cool stuff you could do, and truly wowed most of the folks I was sitting with. Unfortunately, she never stated the problem she was solving. She was reasonably good about touting benefits rather than features, though it’s hard not to get a bit down-in-the-weeds when you’re talking about one thing for 20 minutes.

But she never stated the user/business problem.

Now if you were there, you know that the problem became obvious a couple of minutes into the demo. I watched the penny drop for most of the attendees about five minutes in, as they finally “got” what was going on and realized the difference it could make in their effectiveness. However, this demo would have gone from good to great if the VP had simply noted some context in the first minute or so. She could have shown all the back-and-forth in the previous version, she could have shown a competitor’s back-and-forth if she quite properly didn’t want to denigrate her current product, or she could even have posed a thought experiment — “Think about how much you go back and forth between screens to day, cutting and pasting, looking stuff up, and so on. You get your work done, but wouldn’t it be magical if you could do it all in one place? What about if that one place were your place, the place you do the bulk of your work — not in some other software, but right inside Outlook and Word?” She gave us the last sentence, but never set it up with the previous two — and thus had an unnecessary number of blank looks for the first few minutes.

There was also a vendor buried in perhaps the worst spot in the entire sprawling trade-show floor with what looks like a very nice product, called iCyte.

How often do you want to find something you noted before on some website? Did you bookmark it? Can you find it in your rat’s nest of bookmarks? Do your bookmarks really work for you? What if it was just a few words halfway down one of those pages, maybe not even directly related to the site’s putative content? (For example, if you want to find out more about iCyte in a month and can’t remember the name, would you think to look here, in a post about demos?)

Okay, I just gave you the context. Maybe it was because I saw the demo near the end of the three-day show and everybody was a bit burned out, but the demoer didn’t provide me that context. Indeed, I would have walked away if it weren’t for the fact that I was interested in demos themselves as much as the content of them, and I could see that the person I was trying to connect with two booths down was talking to someone else. So I took another 30 seconds to figure out what iCyte did, and I’m very glad I did. It’s a cool product.

The demoer eventually supplied some context and here’s-the-problem stuff, but it was a minute into the demo. You usually don’t get a whole minute on a trade show floor.

(Now if only they get iCyte to work with Chrome, I’ll be a happy camper.)

“Help! I Can’t See”

Maybe a decade ago, Microsoft created a talking Barney — you know, the purple Annoyasaur. I don’t remember why we did this, and it didn’t last very long or make a huge market splash. Nonetheless, we created this two-foot-tall purple plush beast that interacted in a relatively realistic way with three-year-olds using data from a variety of sensors. (Um, realistic for a companion, not a dinosaur; a real Annoyasaur would simply eat your kid and be done with it.) For example, if a kid put her hands over Barney’s eyes or shook its hand, it would respond like another kid, albeit a grape-juice-colored, whiny kid.

The marketing team gave a beta version to someone (I’ve forgotten whom, but she was relatively well known) who flew into Redmond/Seattle to talk with the development team about it. She carried it aboard her return flight and stuck it in the overhead compartment. Later, as the plane jostled and bumped down the taxiway, the on/off switch must have gotten nudged, because people around her were aghast when there came a child-like voice from the overhead compartment crying, “Help! I can’t see.”

The Help-I-Can’t-See award is shared this year by at least 20 vendors who were in darker areas of the show floor and didn’t have lights on and in their booths! C’mon, at a minimum your back wall graphics and signage need to be well-lit. You need to bring lights!

More to the point, this was New York, where you can make anything happen. Once you discover Monday morning that your booth is in a dark spot, go out and buy some lighting! At a minimum, get a couple of floor lamps to put around your booth, but for a hundred dollars you could have gotten two or three halogen gooseneck lights to clip atop your booth. I remember doing trade shows in New York in the 1980s where we had to pay a show electrician a ridiculous rate to hook up our lights, but that’s a small price to pay compared to the money you’re already spending on the show — and throwing away because people can’t see you. And you could probably get away with doing it yourself after the show started, not that I recommend such a thing, of course.

LegalTech is a combination conference and exhibition. I’m speaking at the former, doing the demo walk at the latter, and meeting with clients and colleagues whenever I can. Given the recent series on software demos, I’ll take some notes and [...]]]> I’m at LegalTech today through Wednesday, and so I likely won’t be posting much this week.

LegalTech is a combination conference and exhibition. I’m speaking at the former, doing the demo walk at the latter, and meeting with clients and colleagues whenever I can. Given the recent series on software demos, I’ll take some notes and report back on these very difficult show-floor demos along with a few vendor-suite demos in a more conducive environment.

If you’re showing collaboration, you need two demoers! Don’t try to fake it; that’s confusing and counterproductive. If possible, set up the scenarios so that you don’t have to switch between screens, such as [...]]]> In part 2 of this series, I described a scenario with Google Docs focusing on collaboration. Recall that there were two demoers!

Collaboration

If you’re showing collaboration, you need two demoers! Don’t try to fake it; that’s confusing and counterproductive. If possible, set up the scenarios so that you don’t have to switch between screens, such as the scenario I gave — where the other demoer is doing most of the work and it’s showing up on my screen, the screen that’s projected.

If you do need to go back and forth between computers, make a production of it! If you only do it once during the demo, unplug the external monitor cable from one machine and plug it into the other. If you have a monitor switcher, be very visible in switching it. In addition, make sure the two machines are set up on different color schemes (or one’s a PC and the other’s a Mac, say).

In other words, leave no doubt in the audience’s mind which machine they’re looking at.

If for some reason you don’t have the second demoer, at least have two machines side by side. You can’t type on both at once, but you can go back and forth between them and gain many of the benefits of two presenters. Again, make clear which machine is which.

One possibility here — and this is theoretical; I’ve never tried it — is to ask one of the viewers to use the other machine if you’re doing something simple. For example, “Now why don’t you change the sales figures in the cell I’ve highlighted in red, and you’ll see the numbers change on my screen in a second or two.”

Communication and Networking

If you’re showing a client/server app or any networked system that requires two computers, use two computers!

Laptops are inexpensive, and some are quite lightweight. Don’t confuse the customers and other viewers, or leave any room for doubt that your software does what you claim it does.

Even better, at one point in a late stage of the demo, ostentatiously remove the network cable. (Yes, use a cable, not wireless, both for robustness and so that you can hold it up to point out what’s happening.) Demonstrate how your software recovers gracefully from a network interruption.

Incidentally, if you don’t do this and I’m watching the demo, I will do it for you. I will literally pull your network cable, or at least start to do so while watching your face for a reaction. Amazing what I can glean by doing this!

Server Load

Don’t ever run Exchange, SQL Server, and such on your client demo machine. These programs, as outstanding as they are, take a lot of cycles, and your software can appear slow. You should never have to make excuses during a demo… and I won’t believe performance excuses anyway. Put your server stuff on another computer, even if that requires bringing three laptops! They’re still not that heavy, compared to the 17-pound wonders I used to have to carry in the mid-90s for demos.

And yes, I carried two of them when I was demoing client/software server, such as Internet Explorer plus IIS back in the early days when Microsoft was trying to make a dent in Netscape’s market. I still have nightmares about one late-night transfer in the Minneapolis airport, with nearly a mile between the gates, no moving sidewalks, and sweating in my (only) suit.

In demoing software, you need to first figure out who’s in the room. [...]]]> As I noted recently, in any deal, there are a small number of people who can meaningfully say Yes, a large number whose Yes doesn’t matter but whose collective No might, and usually a small number of people with significant power to say No.

In demoing software, you need to first figure out who’s in the room. Then you need to figure out into which of these buckets they fall. This is a tricky evaluation in walk-by demos at conferences and such. Good salespeople seem to pick up on the viewer’s position quickly; the rest of us need to ask.

If you’ve got yea-sayers (or potential yea-sayers), those whose Yes does matter, show how you make their life better. That’s the focus of most of this series — don’t talk features, don’t talk about yourself or your company (too early in the process), just show these folks one, two, or at most three things, in the context of their work, how your software will improve their work-life. These folks include the Champion, usually the Customer, and often one or two key Users.

Many onsite demos have a room full of hangers-on. These folks may be Users, they may be IT folks charged with implementing a solution, they may just be there for the donuts. You can ignore the folks there for the donuts, though you don’t want to get caught up in their irrelevant questions.

The (non-key) Users are probably scared. Will your software take their jobs away? Does it threaten them? Often, the answer is yes, at least in part — which makes it rather hard to demo to them. The grumblers don’t have decision power… but they may well have a lot of influence over whether your solution, once up and running, is perceived as successful. So be nice, even if you don’t focus on them during the demo.

Many of the low-level IT folks will be grumblers, too. They can say neither yes nor no, and the reality is that they probably have little impact even within IT. Don’t play to this audience unless they’re the only folks in the room.

However, there will be folks who can say No, often but not always higher-level managers from IT. I think the best way to handle these folks is in a private demo, if it can be arranged, where you focus on assuaging their concerns about maintainability, total cost of ownership, stability, and so on.

Other important naysayers may come from Procurement or even HR. You probably have no chance to win these folks over to the Yes column; that’s the internal Champion’s job. However, they will be concerned about your company’s stability; will you be around in four years? There’s not much you can do in the demo itself to address their concerns. However, this is where you finally get to use those slides about the founder’s background, your venture capital funding, and so on. Even if they don’t state these concerns, they do have them. But don’t screw up the demo by commingling this material with your demo story.

(Even in the Champion role, I used to take the lead in probing the company’s long-term future, in part because I had significant start-up experience and knew the pitfalls of such issues as expansion vs. cash flow. However, I never did so in front of Users or business Customers.)

==============

There is a site called Great Demos that yesterday posted an insightful piece about what people do and don’t remember about demos. Check it out.

For now, I want to focus on three [...]]]> In any deal, there are a small number of people who can meaningfully say Yes, a large number whose Yes doesn’t matter, and usually a small number of people with significant power to say No. In a later post in this series, I’ll talk about the Yes/No conundrum.

For now, I want to focus on three Yea-sayers:

1. The Customer is the person who will actually make the final decision.
2. The Users will use the software. (The customer rarely will, though she may see reports or other output from it.)
3. The Champion is the internal person pushing for a software solution — and you hope to get him pushing for yours. In some situations the customer may also be the champion, though in software the customer is often in IT. The champion is always in the business. (Let’s skip the going-in-circles nomenclature game in selling software for IT’s use.)

You need to provide different insights and scenarios during the demo for each of these three groups.

Let’s assume for now that they are not in the room together. Sometimes they will be, other times not. You’re not going to show anything to one person that you wouldn’t want another to see… though what you show IT may not be of interest to the business user or customer. So it’s a matter of dividing time and attention rather than trying to shade your story.

All three groups have one thing in common: They each want to understand what it is about your solution that will make their life easier and/or better.

1. The customer wants to see how you’ll improve the department’s P&L (internal profit and loss statement). There are other related needs, such as improving retention of good employees, but it boils down to the overall business group’s or IT group’s annual outlook. Some customers will be more direct about it than others, but that’s in the back of every customer’s mind. Show them how, without being heavy-handed about it. Actually, for IT you can be pretty blunt… but this is the one time to be circumspect when users and champions are in the room. Accept that at most companies IT and the business teams are at odds, whether overtly or subtly. You can promote IT goals that are also business goals.
2. The users want to know how you’ll help them go home at night. Show how you save them work, save steps, save cut-and-paste, and so on. How do they do less scut-work and make their managers happy?
3. The champion also wants to see you you’ll improve the business P&L.

In all three cases, the watchwords are:

• Show, don’t tell. (Or show in addition to tell.) Describe not what you’re doing but what results, what the benefits are.
• Keep it simple and short.
• Ensure that you are clear on the scenario before getting in too deep — and make sure that it’s a scenario the viewer cares about. If you’re not sure what that scenario is, ask!

I’m a viewer; show me how you make my life better. That’s all that matters to me. I don’t care about Tom’s life, or Carol’s, unless they work for me, in which case I may care a little bit. That’s hyperbole, of course — at least I hope it is — but it’s still at the crux of a successful demo. Convince me in 20-30 seconds that you can help me, and I’ll care. Otherwise, I’ll tune out.

When I was a champion at Microsoft legal, I recognized that vendors didn’t know how to demo, and I went out of my way to make up for that by digging around. Some champions will do that; many will not. Take control of the game, and don’t make them dig. Show them how and why they need you.

You have 30-60 seconds.

Begin.

This one’s pretty obvious… and yet it’s forgotten at least as often as it’s remembered. Demonstrate the benefits to the customer (and/or user) of the software solution you’re selling; features by themselves may be cool, but they rarely help sell the product.

Is this rule always true? I can think of [...]]]> Continuing in the Better Demos series….

This one’s pretty obvious… and yet it’s forgotten at least as often as it’s remembered. Demonstrate the benefits to the customer (and/or user) of the software solution you’re selling; features by themselves may be cool, but they rarely help sell the product.

Is this rule always true? I can think of three specific exceptions:

1. Apple and other “cool toys” sell features because the benefits themselves are limited, or perhaps the benefit is the coolness of the “toy” itself. The original iPod didn’t do more than its competitors at the time; in fact, it did less, since you couldn’t change the battery because Steve Jobs didn’t want a screw to disturb the lines of the sleek case. Apple has been able to duplicate this success many times, but few others can. Remember Sharper Image stores?
2. Technoids love features. (I used to be a proud member of that fraternity, two decades ago.) I think even here it’s the benefits that are selling; it’s just that these folks are wizards at seeing a feature and immediately figuring out themselves what the benefit is, and thus they help sell themselves on the software.
3. Mass-market software goes through a stage referred to as “feature wars.” The software in a category has reached a level where the entrants do the basic stuff necessary for useful operation. The next stage is competition on a checklist of features, because users have little else on which to base a decision. Vertical-market software solutions rarely reach this stage.

Other than these three highly limited exceptions, sell the benefits to the customer or user.

In future posts I’ll talk about customer vs. user vs. champion and yea-sayers vs. naysayers in terms of how you approach demoing to these groups.

Meanwhile, consider the basic rule:

Demo two or three ways that your solution will make life easier/better for the viewer, in a context that the viewer instantly recognizes and understands.

An Example of Selling Benefits, Not Features

Go back to the Google Docs example. I really think Google’s been approaching this software the wrong way. (And yes, I’ve had this conversation directly with someone on the Google Docs team.) Let’s look at the Google spreadsheet. By and large, they’ve been selling it by saying it has feature parity with Excel, but it’s cheaper.

The problem is that “feature parity” isn’t a benefit, and the majority of users I’ve talked to don’t believe it. Cheaper is a benefit, but only to a purchasing agent or individual user — and Microsoft has been able to make plausible arguments in the corporate space that Excel on an enterprise license isn’t really more expensive all-up than Google spreadsheet — and a lot less risky.

The big benefit comes via real-time collaboration. Construct a scenario applicable to the user in which real-time collaboration solves a problem that the user has. (See the quickie example here.)

Or let’s say I’m selling a time-tracking solution, for lawyers or consultants. (I’m about to sit through umpteen time-tracking demos next week at LegalTech.) Here are some scenarios I might envision (based on who’s in front of the demoer):

• Attorney (front-end user): You get off the phone with a client. The software, tied into your phone system, has recognized the phone number and pre-filled a time entry with the client info and the time you spent on the phone, rounded up to the next tenth-of-an-hour increment. All you have to do is click OK. Oh, wait, you’re still working on the matter even after the call ends? The timer on the software continues to run, and when you’re ready you can click either “Bill for the call” or “Bill for the call plus the additional time until this moment.”
• Firm billing coordinator (back-end user): Show how the data is automatically tied to the overall billing and general-ledger systems, including applying outside counsel guidelines and flagging any activity that might be non-billable under those guidelines. Getting bills together at the end of the month is a big headache; you’re showing your solution as pain reliever.
• Firm management (customer/champion): Forget the software. Show reports from other customers demonstrating that they have been able to bill 6% more time using your solution because it has reduced the amount of work that the attorneys forgot to bill. (Jokes aside, it happens a lot.)
• Firm IT guy/CIO: Show how the software checks every night for updates a la Windows Update and gives IT control of when and whether to install those updates. Show it running on Windows 7 on one machine and Windows 2000 on another — and also on a BlackBerry! In other words, ease their pain, which is compatibility, installation, and maintenance.

More importantly, what do the first 1000 milliseconds — 1 second — of these songs have in common?

The first couple of notes/chords are instantly recognizable, even to those without any musical training. Okay, there’s an [...]]]> What do Start Me Up, A Hard Day’s Night, and Stairway to Heaven have in common beside being big hit records?

More importantly, what do the first 1000 milliseconds — 1 second — of these songs have in common?

The first couple of notes/chords are instantly recognizable, even to those without any musical training. Okay, there’s an age thing in there — these are more recognizable if you’re 60 than if you’re 20, although both my kids listen to the Beatles and recognize that first chord of A Hard Day’s Night immediately.

A Hard Day’s Night begins with a simple, single electric guitar chord*. That’s it. One strum, a pause in which the notes reverberate, and then the vocals begin. It’s a common enough chord, yet it affords instant recognition. Stairway to Heaven begins with some slow, simple guitar picking, yet that pattern, too, makes an instant connection. Start Me Up has a series of three short chords and a brief pause — but by the time you hear that third chord, there’s no question as to what the song will be.

None of these are complicated beginnings. But they’re unique, easily remembered, and somehow fit the song perfectly.

What’s that have to do with software demos?

Keep the image of these three openings in mind as you begin your demo. You need to strive for the same effect, albeit in a far more quotidian context.

Do you want to deliver a jolt to your customers, evoke a sudden “Aha, this is what we’ve been looking for”? You can Start Me Up and never stop. Want to build a sense of anticipation? It’ll be A Hard Day’s Night. Hook them without their realizing they’re caught up in it? Climb the Stairway to Heaven.

Whichever you choose, you need to make your opening count. You’ve got 60 seconds, maybe less. (Pop songs may get 10-15 seconds of a music director’s time sampling the track; at least the demo opening isn’t that short.)

Don’t waste that time. Or the audience will tune out and mentally change the station.

__________________

*The opening of A Hard Day’s Night is not really a single guitar chord, though it sounds that way. It’s a combination of an electric 12-string chord, the same chord on an acoustic guitar, a high bass note, a shimmer of snare and cymbal, and a background piano overdub — George, John, Paul, Ringo, and George Martin, respectively. See here and here.

If you’re doing a booth at a trade show, you have even less time — perhaps 5-10 seconds for walk-by folks, 20-30 seconds for those who have stopped in front of your booth and turn [...]]]> The first 60 seconds of a one-on-0ne software demo are critical. You earn or lose the customer in that first minute.

If you’re doing a booth at a trade show, you have even less time — perhaps 5-10 seconds for walk-by folks, 20-30 seconds for those who have stopped in front of your booth and turn to you with interest, and maybe 45 seconds for someone who’s asking a question.

That’s not a lot of time, yet so many vendors waste it.

That’s not a lot of time, yet it’s enough, except perhaps for the walk-by’s, whom I’ll ignore for now.

When I was purchasing software for Microsoft, almost every invited demo I can recall blew that first minute. They lost me at Hello. It didn’t matter whether I was visiting their suite at a trade show or they were visiting a Microsoft conference room. Even web demos — which were still in their infancy back then — made the least of that precious first minute.

The Wrong Stuff in the Demo Opening

Let’s start with what vendors get consistently wrong.

1. They tell me about themselves. “I used to be the CEO of MyCorp, but I was so excited by what this product can do that I took a stake in this company.”
2. They tell me about their team. “Our head programmer created the Google Whatsis and received the Turing Prize.”
3. They tell me about their company. “We are funded by Venture Gods of Palo Alto and have been around for four successful years, with hundreds of customers.”
4. They tell me about their product in general terms. “It slices, it dices, and it will solve all your problems.”
5. They use PowerPoint to show describe something instead of showing the software itself.

It’s not that the customer and/or purchasing manager don’t care about this stuff. They do. But they care if and only if the product appears to meet the customer’s needs.

If I think that your product is a fit, then I will indeed want some assurance that your company is stable, with competent management, smart developers and support people, and funding to keep the lights on for a while. I will at that time also begin to think about specific features… but not yet.

Because I have no context. What good is your product to me? Until I know that, the rest is just random ingredients in demo stew.

(To be clear, there may be a pre-first-minute sequence in an invited demo where there are casual introductions of the people. I’m not talking about this part, but about the part that immediately follows, the start of a semi-formal conversation.)

Sell Benefits, Not Features — But Not Yet

No matter how often people hear “sell benefits, not features,” they seem to forget it when they get behind the controls of a software demo. I’ll come back to this point in a later post.

For starters, though, even the benefits are not the best place to start — though it’s certainly better than the five no-nos I listed above.

First, Solve My Problem

I can’t tell you how many demos I have sat through where my primary thought has been either “what problem is it solving” or “how does it add value.” That’s the hook.

In the first 30 to 60 seconds, show me and tell me a) what problem you’re solving and b) how your solution adds value.

It doesn’t matter whether you’re showing a solution to a problem the customer hasn’t yet solved or are trying to displace an incumbent. Solve the problem and add value.

Not sure what the customer’s problem really is? Ask! You should ask at the time you set up the demo. If you haven’t, then you’ll need to use the first 60 seconds asking for information and the next 60 seconds showing how you deliver the goods. That’s not a bad use of the first 60 seconds, by the way, either asking or confirming the core problem. It engages the customer in the problem and the solution, and as long as you end with “We can help; let me show you,” you’re still fulfilling the two mandates above: solve problem, add value.

Example: Google Docs

(Context: Customer in sales/marketing. You and Joan have your computers already open to the same Google Spreadsheet. Yours is projected on the monitor.)

I say, “I understand you want your team to collaborate better on your weekly reports. Here’s my weekly report. Joan has the same spreadsheet open on her computer. Now I’m going to put in the sales figures from my team [you type] while Joan is adding the sales figures from her team right in the next row. Look, here they are, appearing on my computer as she works. I finish my numbers, and here are the new totals immediately. You can see they include her data.”

Joan says, “I see his numbers, and I’m going to flag one of them because I have a question.”

You say, “And here it is on my screen, in real time. No more phone tag, no more EMail tag, but we have real-time collaboration. We’re saving some time, of course, but the real benefit is that your information keeps up with the speed of your business. Is this something that can help you win more sales [or "spend more time selling," if too much time on paperwork is the underlying issue]?”

I don’t know if that’s exactly the right scenario, but I want to show the concept. It’s taken less than a minute, you’ve shown something magical that speaks to the customer’s problem, and you’ve put it in a context that represents that problem.

Here’s the breakdown of the script above (which is off the top of my head, since I don’t use Google Docs):

1. I restated the problem, and I’ll look for tacit confirmation or uneasiness before continuing.
2. I set up a context with a very recognizable if simplified weekly sales report.
3. I did something with the software that has a bit of a “wow” factor that obviously addressed the problem — we collaborated in real-time without email.
4. I restated the value of what I was showing, even though you might think it’s obvious.
5. Finally, I asked a question to engage the customer — not just any question, but one that almost ensures they’ll answer in the affirmative. If they don’t, then I need to do a drastic course correction… but better to find that out up front than after they’ve tuned out.

It got me thinking of how bad most software demos are… and why they don’t have to be like that.

I’ve been part of all the aspects of software demos over the years. I’ve demoed to customers and large audiences software that my company sold, sometimes software that [...]]]> I sat through yet another awful software demo recently.

It got me thinking of how bad most software demos are… and why they don’t have to be like that.

I’ve been part of all the aspects of software demos over the years. I’ve demoed to customers and large audiences software that my company sold, sometimes software that I’d written or designed. I’ve attended both one-on-one and large demos where I was the intended customer. I’ve run departments where I was the purchaser or final approver of software meant for others — some who worked for me but mostly for those who didn’t — and have had vendors present to me and the users, or sometimes to me hoping I’d call them back to talk to the users. I’ve even been a casual observer at various demos, sometimes because I was studying the demo techniques and others because if I sat through it I’d get some sort of tchotchke I thought useful at the time.

Most of those demos, frankly, were awful, a total waste of time for vendor and customer. Even the ones I gave 15 years ago weren’t very good, though I did figure out many of the issues over time and got a lot better at pulling them off, winning both smiles and sales.

In two weeks I’ll be attending LegalTech, the big legal-technology trade show. I’ll probably subject myself to at least a couple of dozen demos. I anticipate most of them will feel like having my teeth worked on… which was my activity this morning, in fact — and it was sitting in the dentist’s chair that made me think of this series of posts.

So between now and LegalTech, I’ll put up a series of posts about what’s wrong with the majority of software demos… and how to fix them.

You don’t have to be slick or smooth to deliver an effective demo to customers. If you’re doing the mass audience thing, smooth is a factor — think Steve Jobs — but it’s not a make-or-break issue by any means for demoing to a customer or a small group such as might cluster at your booth at a trade show.

I hope this stuff, drawn from my experience, will be helpful. I figure that the demo-target’s life I save may be my own.