Here’s one I made earlier

By Colin Harris – Conchcom Ltd

Demonstrations have a curious effect on time – when people are watching software on a screen, time appears to slow down…. So in order to make our software look as fast as possible we have to bend and sometimes break the laws of physics, and this article explains how we’ll do that…

Once again, massive thanks to Terry Simpson for proof reading it.

Demo time is sooooo slooooowwwww...
Demo time is sooooo slooooowwwww…

Scientists can’t explain the phenomenon, well maybe they can but I haven’t asked any, and I’m doubting they could get the funding to investigate it anyway.  But it does appear that whenever a person demonstrates software in front of a group of people the system seems to take longer to respond than when there’s just one person looking at it.

“So what? Who cares?” I hear you cry.

“You should,” is my reply, “and here’s why.”

The problem is that a prospective customer is going to perceive that the fastest they’re ever going to see the software run is during the demonstration.  So if it appears slow during the demo they’re getting the impression that it’s going to be even slower when it’s live.

And it doesn’t matter if you tell them that it’s just a bit slow because we’re on-line to somewhere thousands of miles away, or our demo system isn’t very powerful; chances are they won’t believe you.

Now it may be that speed isn’t that important, and if it isn’t, that’s great.  However, waiting 2 minutes for the results to appear is going to feel like an hour has passed if all the audience is doing is watching a screen where nothing much is happening.

So what can we do about it?

We could try a line that an old colleague of mine used to use.  He’d say “We deliberately slow this down so that you can see what’s happening.”  And I think a prospect even believed that, once.  But we can be cleverer than that.

First of all, don’t demonstrate with one hand tied behind your back.  Find the quickest easiest way to demonstrate a particular feature.  Peter Cohan in his excellent book ‘Great Demo’ gives some powerful tips on how to do this – check them out here

Secondly, if you can, make sure the hardware is up to the job.  Get the fastest bit of kit you can, and keep it tuned up and de-cluttered.

Thirdly, is there anything you can do to make the software faster?  I’ve worked on systems where the first time a program loads it takes a while, but then it performs really quickly.  If this is the case, then pre-load the software before the demo.  Just make sure the system doesn’t time you out – is that something you can adjust?

Perhaps there’s nothing you can do about performance – it’s just going to take a few (or many) seconds to operate.

So here’s what you do.

You press the button and then you stand up and address the audience.  And then you tell them what the system’s doing.  Maybe you sketch a diagram on the white board or flip chart – maybe you have a separate projector and you show a diagram.  Or perhaps you could recap the steps you had to go through.

What you’re doing is distracting the people from the screen, whilst in another time-space continuum the software continues its merry dance.  Just make sure all this takes longer than the processing.  If all else fails you can try what another former colleague of mine used to do – he’d leap up excitedly, point out of the winner and exclaim “Is that a skylark?”

The extremely rare Skylark....
The extremely rare Skylark….

But wait, isn’t there another way?  How about we don’t show it at all?

“Anarchy” I hear you scream, “but they asked you to explain how xyz works.  And in order to do that we have to press the button. And that takes loads of time.”

But they didn’t ask you to show them, they asked you to explain it.  So why not do that?  You could walk them through the steps, maybe show them with diagrams how it works, perhaps show a few key things on the screen and then you do what’s commonly known in the UK as “doing a Blue Peter”.

Here's how to make a fort
Here’s how to make a fort

Blue Peter is a TV show for children that has been running since 1958 – I think it’s the longest running children’s programme in the world.  And quite often they show kids how to make things out of household objects (using ‘sticky-back’ plastic, washing up bottles, empty toilet roll tubes and coat hangers) – things like an advent candle, a present for your mom on mother’s day; and one year famously when the must have Christmas present for kids was Thunderbirds’ Tracy Island, and there weren’t any in the shops, your very own Tracy Island.

Except they didn’t show you how to make it. No.  What they did was show you the components, maybe they’d put a couple of things together.  And then, using the immortal line “Here’s one I made earlier”, show you the completed item.

Just like the real thing...
Just like the real thing…

So do that.  Already have the results to hand, run the program before the demo and have the output screen ready and then tell them “here’s one I did earlier”.  If it’s good enough for Blue Peter….

Or alternatively, keep your eye out for rare species of birds.

An Analogy Paints a Thousand Words

By Colin Harris – Conchcom Ltd

In this article I’m going to explain how using a good analogy can bring your presentation alive, and also show how the wrong analogy can leave everyone deflated. Once again, thanks to Terry Simpson for the sterling proof-reading job.

A few years ago I was working for a major US Software House as a pre-sales consultant.  I was asked to meet with a new prospect and my job was to demonstrate the flexibility of our product.  The prospect was in Northern Sweden – inside the Arctic Circle, so I found myself on a plane heading northwards.

To take my mind off the thorny question of how exactly I was going to demonstrate ‘flexibility’ and also to distract the thoughts that I was in a bog-standard commercial airliner that was soon going to have to land on a runway covered in ice I idly flicked through the in-flight magazine.  Towards the back there were some things you could buy – two objects caught my eye – and fired up my imagination…. ten minutes later they were both in my laptop bag.

I was one of the first presenters.  I explained that I was going to show them how flexible our software was.  And because I was in Sweden I would do it using an inflatable model.  There were some nervous giggles.

I then produced my first purchase – an inflatable model plane that I’d blown up and hidden behind the lectern.

A flexible inflatable plane
A flexible inflatable plane

The sight of it got a big laugh.

“Now this plane is really flexible- see, I can bend it to alter its shape – and our software is like that – it’s very configurable so it’s easy to alter it to work in a different way or to change its appearance.”

“But there’s another sort of flexibility, isn’t there?  What if I want to add another engine, or take off one of the wings and put it on the other side?  I’d end up ruining it.  This plane doesn’t have that sort of flexibility.  And a lot of software out there is like that – it might be bendy, but if you want to add something or move something around you risk damaging it beyond repair”.

“So what we need is another sort of flexibility.”  I then produced my second purchase – a plane made of Lego.

Another sort of flexibility
Another sort of flexibility

“OK, so this isn’t very bendy – but look how easy it is to take an engine off, or move a wing around – and our software is just like that – it’s made from components like Lego bricks and we provide you with a toolset so you can add extra bits of functionality, or move those bits around.”

Then all I had to do was show a couple of examples of both bits of flexibility and then I summed up by showing the models again.  The prospective client loved it, and the other presenters latched on to the analogy when they showed their bits.

We got the deal and there was much celebration.

So whenever I now need to explain something complicated I will simplify it by using an analogy – and wherever possible I try to make it a bit funny.  It may be a story I’ve made up (or that happened to someone), it could be an object as an analogy for a process or a feature, it could be a proverb.  You could use a sporting analogy but just make sure it’s relevant to your audience – a British audience may not understand a baseball story, but similarly a great cricket anecdote stands the risks of bewildering the  Americans…

You can use a more negative analogy to explain their current situation, like stumbling around in the dark or being in a maze, and it’s a great feeling if the client really identifies with it.

The problem is if you can’t think of an analogy you run the risk of confusing the audience or leaving them bewildered.  There’s a great sketch from the British comedians Armstrong and Miller about not using an analogy – catch it here

Plus, the wrong analogy can be disastrous.  I once worked with a man who in the middle of a presentation that had been going quite well suddenly decided to explain a particular function of the software by likening it to a toilet.  OK, we all got the gist of what he was on about but I’m fairly confident that the reason that particular sale went down the pan was because every time the potential client thought about our solution this was the image that came to mind…

Not the right reminder...
Not the right reminder…

Then there was the time we asked our implementation specialist to use analogies when explaining how we made sure the implementation would go smoothly.

We were all on form, analogies were being flung out like confetti – it was going great.

Then it came to his section – he opened with the immortal words “Now we all know implementations can be a nightmare….”

We all felt the energy – along with any prospect of our company getting the order – leave the room.

So to sum up – an analogy, like a picture, paints a thousand words – just make sure it’s painting the right words.