Tools & Consulting for the webMethods® platform

Tools & Consulting for the webMethods® platform

One secret of good demos

Here is a short article on what I consider an often overlooked reason for how well software demos go and why you need to prepare hard.

Nobody would argue that preparing a demo for a software product is not important. But one aspect for doing so is often overlooked.

If you struggle with the content side of a demo, you cannot focus on the audience.

That is the sometimes not so obvious reason, why you need to prepare vigorously. Many people only think about how fluent things look like. And of course that is important. But it serves a different purpose, so let’s look a bit deeper.

When giving a demo you want to convey a few things. It is mainly about fit to the customer’s problem, and you being competent, trustworthy, and pleasant to deal with. If you have made your homework and your offering does indeed fit the customer’s problem, the first part is solved already. (Plus the demo must be flawless to bring that across.) The challenge, though, is that often you are not the only vendor who can do that. So it comes to the “personal” side.

I argue that being able to “read” the audience during the presentation is critical. If you don’t need most of your mental energy to execute the demo, you can concentrate on people’s reactions, their body language, and what signals they may send. Being able to react instantly, sends a powerful message about customer centricity.

In particular I remember one meeting with an existing customer. Their CIO mentioned something about performance problems and the use-case seemed similar to something we had solved before. So I simply threw in that we might have something to help. To my surprise this CIO asked my literally, whether I had time to come over the next day. Had I been completely absorbed with the demo, things would likely have developed differently.

Of course your colleagues should also look at the audience and see what they can pick up. But that is no replacement for you doing this. Firstly, they may not be as technical as you and not see what you see (and vice versa of course). Secondly, your proficiency with the product will always be translated into how complicated it is. If all you can do during your demo is “tame” the product, it looks as if said product is difficult to handle. How could it not be, if even the product specialist (=you) has a hard time with it?

There are certainly more points to consider, but this is the one I wanted to send out today. Looking forward to your comments!

If you want me to write about other aspects of this topic, please leave a comment or send an email to info@jahntech.com. The same applies if you want to talk how we at JahnTech can help you with your project.

Share:

Facebook
Twitter
Pinterest
LinkedIn

Leave a Reply

Your email address will not be published. Required fields are marked *

On Key

Related Posts

Microservices and code reuse for integration platforms

Today I want to write about a software development approach I was able to put into practice a few years ago. I was myself very much surprised how well things worked out, and especially how fast I was able to see tangible benefits for the business side.

Custom logging with Log4j on Integration Server

Every serious IT system needs proper logging. This article describes how I use Log4j v2 with webMethods Integration Server. There is no need to change anything on the system, just install the package and it works.

External Java libraries in webMethods Integration Server

To get most out of your Integration Server you will sooner or later need to leverage the functionality of existing Java libraries. Common examples are Log4j or Apache POI (for working with Excel or Word files). Here is a short guide for this.

Running webMethods Integration Server in containers

Organizations are moving from traditional deployments to containers and Kubernetes to increase business agility. This article discusses a lot of topics that are relevant to actually reach the goal of faster delivery of value to the business through software. Because if you do it wrong, you just end up with yet another technology stack. And, as always, technology is not your biggest challenge.