The first demo

When demoing a tool to a business for the first time, there are plenty of things you could show them.

Different features, workflows, integrations. And since you know the tool so well, you could easily spend the whole meeting listing out all the different areas where they could get value.

But the buyer is left needing to figure out which parts matter to them, how it would fit into their business, and what their team would need to change to make all of this work.

Last week, I wrote about removing the obstacles in front of a buying decision. The first demo is an ideal place to put that skill into practice.

Here’s how I would approach it.

Before the meeting.

Choose one task, or one workflow, to focus on.

You need to understand how they do it today, the people involved, the tools they use, and the data they work with.

People. Tools. Data.

It could be a report that they produce, how they follow up with customer enquiries, or the admin that comes after a customer call.

This allows them to judge your tool against a benchmark, something they’re familiar with. And if you can’t use their actual work, you want to create an example as close to it as you can. Use their terminology, the kind of information they deal with, and the likely steps their team would recognise.

Start by agreeing on the benchmark.

Before you show your tool, talk through your understanding of their current process. This is where you want to show them you understand their business and allow them to correct you as they fill in the details. The person who actually does the work might see the problem in a different way. This is all valuable information and helps direct your demo.

Show one workflow.

Introduce your tool in sixty seconds. It’s not until the buyer knows you can actually help them that they’re willing to absorb information about the breadth of your tool.

Start with a broad introduction lasting sixty seconds, then spend most of the meeting on the bespoke demo. Come back to the broader capabilities at the end, only if required.

1. Sixty-second introduction
2. Bespoke demo (most of the meeting)
3. Broader capabilities (only if required)

That’s the setup.

The goal of your demo is to show your tool working with one specific workflow, because that will then raise questions about how it can work on other workflows. So your demo is always aligned with their needs, as opposed to you positioning features that could be helpful.

Agree on the next steps.

At this point, you’ll have a good understanding of where they see value and what they would still need to see before they can move forwards.

This is where a pilot can be really useful. Now that they’ve seen the tool working in a demo, they’ll want to understand how their team would actually use it with their data and within the realities of their day-to-day business.

The aim is to choose a small scope together, agree on the people involved, and define the success factors.

The questions they raised during the demo should help you shape the pilot. This takes more preparation from you, because you need to understand their work, build a demo around it, and give them a manageable way to test everything.

But that’s how you help them make a well-informed decision. They’ll be able to see where the value is and what would need to change.

When your demo is based on features, it leaves the buyer to do all the work. They need to imagine it working in their world.

When your demo is based on their workflow, you’ve done all the hard work. It leaves the buyer thinking, “How else could this help me?”

Cheers,

P.S. If someone came to mind while reading this, forward it to them. “Four minutes, worth it” does the job.

← All issues