“Now, I know you’re a bank, but trust me, if you were a hospital you’d really love this feature.”

A posting about demos might seem to be something more suited to an internal Microsoft audience. However, if you’re a customer, you’re going to be on the receiving end of lots of demos from Microsoft and our partners over the coming months. In order to make the most of these, I think it’d be useful to think about some of the different approaches to demos. Hopefully thinking about these issues will make you a more discerning audience and you can ensure that you get the right type of demo for your needs.

The quote above represents perhaps the single biggest problem with most software demos – lack of relevance. Mismatching the contents of the demo with either the client’s problem set, and/or the client’s understanding of his problem set.

There are a couple of different broad categories of demo:

  1. Feature-driven. Walk though a list of features. Don’t mention a business context, simply say “if I click on this, that happens.”
  2. Scenario-based. Present a clear business scenario, hopefully one relevant to your audience, and proceed to show how your solution solves the problem.
  3. Conceptual framework-driven. Show simple, generic examples of how the solution works. Encourage the users to abstract away the details, and apply the solution framework – the design pattern - to other problems within their business. 

Obviously the type of demo required depends on your audience. For example, when showing new versions of a product the audience is already very familiar with, sometimes the best approach is just to list functionality. Recently I did a demo  of Excel 2007. The audience were a group of financial analysts, who, truth told, were probably far more proficient Excel users than I’ll ever be. They were actually visibly excited as I walked them through some of the new functionality in the client application. I didn’t offer any real context, didn’t discuss any business value. The audience were more than capable of doing that themselves. I simply worked through my list of features. However, when I moved on to talk about the new Excel Server, this was something new for them. So I built my demo around some generic use-cases. We then held a mini-workshop where they discussed how they might use the new product in the context of their environment.

It’s instructive to ask why demos exist in the first place. I think it’s essentialy to communicate. The goal should be to communicate to the client how the solution can solve their problem. It really is that simple.

Some of the ways I’ve tried to avoid this trap include:

  • Never demo unless you have a clear image of what the client expects.  “Before I start the demo, can you just run through the business problem, and also tell me what you’re expecting today.” Consultatively manage their expectations if necessary. 
  • Leave out extraneous functionality. It doesn’t matter how cool it is, or how useful it is in a different context. For product experts this is really difficult sometimes.
  • If possible, verify that you’re on the right track as you demo.

In music composition, Nadia Boulanger talked about "la grande ligne", "the grand line". This is the idea that there should be a common conceptual line running through a piece. I think this is a useful idea to apply to a demo. What's the theme of your demo, what's the one sentence description? Establishing this can give you the means to focus and target your demo.