You Lost Me at Hello -- Software Demos pt 2

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.

2 comments to You Lost Me at Hello — Software Demos pt 2

  • Subash Warrier

    The problem with Software demos is that engineers who build software think in terms of features and product managers think in terms of concepts derived from assumed and asserted ways in which companies or individuals work. Organizations tend to think in terms of benefit however for them to make a buy decision they need to be weaned away from thinking on benefits to either the product managers view or the engineers view. Sales personnel are trained to speak like engineers or product managers depending on thier aptitudes. This is the root cause of mis-communication in software demo situations.

  • [...] 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.) [...]

Get Adobe Flash playerPlugin by wpburn.com wordpress themes