The Value (and Curse) of The Demo

There comes a point in any project, software or otherwise, when the work must be demonstrated to the client and/or end user(s). This can be a challenging time, often weeks or even months of work hang in the balance; not to mention reputation, credibility, and payment. The last thing you need is for something to go wrong — enter the curse of the demo.

I’d like to explore this ‘curse’ and its impact on a product demonstration, and additionally the value of a demo. Of course, as a developer, I will be tackling this with a software mindset, however I believe some of the concepts apply much more generally.

A Real Phenomenon

Sometimes it seems that no matter how much you prepare, test, and double check, something is destined to go wrong. It can be something small, or something more significant that catches you unawares, but this is the first time it has raised its ugly head, right when you didn’t need or expect it to.

Back in the studio, you try to replicate the issue, but under no conditions can you bring about the same problem that caught you out earlier. Something mysterious is going on, so it would appear that the curse of the demo has struck.

There are of course a whole range of reasons something could have gone wrong during a demonstration, and often there’s a simple reason we overlook or forget about. It could have been network conditions, or hardware. Sometimes blaming the curse is a much easier way of dealing with it. Maybe it was just a bit of good old fashioned bad luck.

If you think you’ve ever had to worry about a demo, then take a look at this article about the original iPhone launch, it may make you feel a little better. It’s fair to say they were quiteworried about the sudden appearance of the curse.

For me, there are two important things to consider regarding a demo:

• It shouldn’t be about trying to please
• It’s an important part of the product development process and a chance to learn a lot

Let’s explore these.

Don’t Build For It

I have seen many demonstrations where the product has been built specifically for the presentation. Sometimes this is justified, it can be useful and even desirable to do so, either as a proof of concept, or to test a slice of a system. You might even be at a stage of the project where only a certain flow or section of a system is required. However, building specifically for a demo can be very dangerous if the reasons aren’t like these, but rather to give the impression a product is further along that it really is, that is, to please the client.

Ultimately it’s a risk that can be taken, and I’ve seen it done. But you will get caught out.

Relating back to the original iPhone launch, this article explains how “the cellular radio, that had been crashing on and off, had been hard-coded to show five-bars of full strength throughout the presentation”. I wonder what the public perception of Apple would have been at the time if they knew what was really going on, that they were being lied to? I don’t respect Apple for lying their way through this, nor find it clever or impressive. Instead I feel like things were rushed, corners cut, the product not as good as it should have been.

If you’re a client, then you should push those presenting to you, make them wander from their script. This way you can ensure you have a full picture of where the project is and what it’s capabilities really are. You’ll also get a better understanding of your relationship, and perhaps even a better product. Be bold, and be involved.

Learn From It

If you approach a project with honesty and are prepared to be transparent with your client then you’re already in a better place, and you can actually make a demo, and the curse that comes with it, work for you.

Approach the demo as a testing exercise, engage with the client and/or users and allow them to explore the boundaries of what you are presenting. This can be hugely insightful, giving you an insight into how you users will interact with the product and raise issues you may not have thought about. Bugs that appear can be noted, and the curse of the demo becomes a developers folktale rather than a thing of nightmares.

At Lunar Works we operate with total transparency, we want our clients to be very clear on what we are working on, and how a project is progressing. We invite clients onto our project management platform, and give detailed end of sprint reports.

Concluding Thoughts

The curse of the demo is the name we give to the phenomenon by which unexpected issues appear when demonstrating a product. These issues can destroy a presentation, but only if it is approached in the wrong way. The curse of the demo can, and should, be utilised to build a better product, and a better business relationship.

Of course there’s no greater feeling than a successful demo, where everything goes smoothly and the product flexes its muscles to its full ability. This doesn’t happen by accident, but takes painstaking and meticulous planning and preparation. Even then there’s often an ounce of luck involved somewhere along the line. Personally, I love the pressure this applies, and attention to detail it requires, as those are the conditions under which I thrive.

Your Thoughts

What is your experience with product demonstrations? Has the curse of the demo struck during a presentation you were giving?

A Demo By Any Other Name

We are currently working on a series of different types of demo at Lunar Works, some example projects that show the capabilities of the upcoming Progressive Web App technology. We’re very excited about this technology, and the impact it will have on the web, users, and the use of technology in society. Keep looking out for posts and articles on this topic, as well as the launch of our PWA demos over the next few weeks.