Bored Businesspeople

I imagine we’ve all sat through at least one of these at some stage of our careers: a software demonstration that is nothing more or less than a relentless and apparently never-ending stream of product features thrown out at the audience in the misguided hope that at least some of them might prove relevant or attractive.

It’s a horrible and unproductive tactic: assuming that our prospective customer hasn’t already zoned out, it places responsibility on them to imagine whether this or that widget might have any relevance to something that is important to them.

This seems to be a particular problem for technically-orientated demonstrators: they are often so proud of how clever their product is that they can’t resist introducing yet another feature of function. There’s no story, no coherence, and no respect for the audience.

Yes, demonstrations – at the right time, and in the right context – can be a vital element of a successful sales cycle. I just believe that there’s a much better way of achieving this than doing a conventional product demonstration…

Let’s start by recognising that demonstrations have different important roles to play at different stages of the sales cycle – but that conventional “vanilla” product demonstrations shouldn’t have a role at all.

Failing to plan = planning to fail

The first principle should be that we shouldn’t demonstrate anything without some initial understanding of the customer’s circumstances and what they are trying to achieve. Armed with a basic appreciation of their situation, goals and challenges, we can do a much more effective job of selectively telling the most relevant and appropriate part of our story.

The next should be that – just as with a good sales presentation – our demonstration needs to act as a catalyst for a productive conversation. We need to ask our audience questions throughout and encourage them to do the same. And however well we’ve prepared and planned, we need to be prepared to adapt to what comes up in the conversation.

Third, every demonstration should be preceded by a scene-setting exercise in which we validate what we intend to cover and what the prospects most wants to see, and every demonstration needs to be followed by a review of what we’ve shown and its relevance to the audience, as well as agreement about next steps.

If we don’t have enough time to accomplish this essential pre- and post-discussion in the time allocated, we need to demonstrate fewer things or ask for more time. In demonstrating, as with most aspects of selling, it is best to do a few things well rather than a larger number of things badly.

Two types of demonstration

We need to recognise that demonstrations are capable of serving more than one useful purpose. Two types seem particularly important:

Conceptual demonstrations

The first is what we might think of as a short conceptual demonstration that complements our initial discovery process. The goal here is to show the client a handful of the most important high-level concepts that distinguish our approach from the other solutions that they might be considering

Our goal here must be to show how and why we are different, rather than better – but different in a way that is memorable because it is specifically relevant to their situation, goals and challenges. We want to create an “ah-hah” moment for the prospective customer that sets us apart from the rest

These conceptual demonstrations are particularly powerful in the early stages of the sales cycle with a potential project sponsor, but they also can be very valuable later on in persuading other less actively involved stakeholders why our company and solution are the right choice.

Solution demonstrations

The second key demonstration type is the solution demonstration. This can only be effectively delivered once we have advanced our discovery process to the point where we have a clear sense of our prospective customer’s most important requirements

The clue is in the name: solution demonstrations need to show how our approach and specific selected capabilities actually solve our prospective customer’s most important needs. We need to create a sense of confidence that our solution is capable of meeting their key requirements

Proving a few things well is just as important here. Focusing on the handful of things that have been agreed to be most important, and putting those capabilities in clear context, is far more powerful than showing off a long list of often peripheral features

Kitchen sinks and muddy sticks

One of my mentors – the founder of a highly successful software company – once described the classic “everything including the kitchen sink” product demonstration approach as being no more effective than flicking a muddy stick at the wall and hoping some if it will stick. Except that the metaphor he actually used involved something a lot less attractive than mud…

It is both ineffective and disrespectful to give our customers a standardised product demonstration, even if that is what they have asked us for. It is always better to understand the context – even if it involves just a few well-chosen scoping questions up front.

Context matters!

If we have no sense of what our prospective customer is looking for, we are bound to fail. If they have no sense of what they are looking for at even a conceptual level, they are the wrong audience.

Once we understand the context, we can determine whether a conceptual or a solution demonstration is what is required and plan and prepare accordingly. And if we wrap an effective pre- and post-discussion around the right sort of demonstration, we’ll have much more impact.

Or would you rather that your salespeople flicked muddy sticks at the wall?