a security demo that opens on the alert

A demo is an argument made with software. Its job is to prove, for specific people, that specific capabilities solve a problem they told you about. A tour of features is a weaker thing. So do discovery before you demo, open with the result the buyer cares about most, show the shortest path to it, and let the buyer’s questions decide how deep you go. In security this matters more than elsewhere, because the value is often invisible until something goes wrong.

why security demos go wrong

Peter Cohan, whose Great Demo! method is the most referenced practitioner framework for software demos, catalogues the same failures for decades: marching through every tab, spending half the session on configuration the buyer will never perform, opening with a long company overview, and guessing at the buyer’s problem because nobody did discovery.

Security products add a specific trap. Their value usually appears as something that didn’t happen: an attack blocked, a privileged session that couldn’t escalate, an audit question answered in a minute. A demo that walks from the login screen to the dashboard shows none of that. It shows a product. The buyer wanted to see their problem go away.

the buyer has already seen your product

Gartner reported in 2026 that 67% of B2B buyers prefer a rep-free buying experience, from a survey of 646 buyers. In Navattic’s 2026 survey of presales staff, run with the PreSales Collective, the engineer joined on average after 1.6 calls. By the time your engineer shares a screen, the buyer has often watched a video, clicked through a tour on your website or read a comparison. The first live demo is frequently a second look. Treat it as one: ask what they’ve already seen and what they still doubt.

show the last thing first

Cohan’s central rule is to show the end result first. He calls it the Illustration: the screen the buyer would look at on Monday morning. Then show the shortest path to produce it, with the fewest clicks. Then peel back layers only when someone asks. Then summarise in the buyer’s terms.

the tour

login screen first

• Company overview, then login, then dashboard
• Every module in menu order
• Configuration screens for people who will never configure
• The alert the CISO cares about appears in minute 50, if at all

discovery-led

result first

• Restate the buyer's situation and check it is still right
• Open on the result: the blocked escalation, the audit report, the alert
• Show the shortest path to it, then stop and ask
• Go deeper only where someone asks

For a security product, a useful test is Cohan’s choice between journey and destination. If the value is in improving steps of a workflow, such as an analyst triaging alerts faster, show the journey. If the value appears only at the end, such as a compliance status, a session recording or a detected misuse, show the destination. Most security products are destinations.

check you are ready to demo

Great Demo! treats readiness as something you can test. Before the demo, write down for each key person:

1. Their role and the goal at risk this quarter or this year.
2. Why that goal is hard to reach today.
3. The specific capabilities they need, described from their side.
4. The measurable value of change, in their numbers.
5. What they need to see to believe it.

If you can’t fill this in, you are not ready to show anything specific. Run another discovery call, or a short preparation call where you open with your hypotheses and let the buyer pick from a short menu of topics.

one demo, three audiences

1. executivethe outcome, in minutesOne or two result screens in their measures: risk reduced, audit time cut, a NIS2 requirement covered.
2. managerthe change for the teamWhat the security team stops doing manually. What it can now see.
3. engineerhow it really worksArchitecture, integration, failure behaviour, limits. Often a separate session.

Technical audiences in security are sceptical of polish. They want the real product, unscripted paths on request, and straight answers about what it can’t do. A rehearsed answer to “what happens when the agent loses connectivity?” costs more trust than “it does X, and here is where that breaks.”

let questions steer, and park the rest visibly

“Any questions?” usually gets silence. Ask specific questions instead: how many steps does this take today, what would have changed if this alert had fired last quarter.

Cohan sorts questions into three kinds. Questions that move the argument forward: answer them immediately and briefly. Legitimate questions that are too deep for now: give a one-sentence answer and park them. Unhelpful ones: park them too. A parking lot only works if everyone can see it and you answer every item in writing after the meeting. Parked questions that never get answered are a quiet way to lose trust.

“I don’t know, I’ll find out” is fine. An invented answer in a security sale tends to resurface in the POC or the security review, where it costs more.

what the evidence says, honestly

Almost every number on demo structure comes from vendors analysing their own customers. Gong’s 2017 analysis of 67,149 recorded demos found that successful demos had 21% more speaker switches per minute than unsuccessful ones, and that no demo in a won deal had more than 76 seconds of uninterrupted pitching. Gong’s analysis of 121,828 web meetings found that intro meetings ending in a won deal averaged 9.1 minutes of slides, against 11.4 minutes in lost deals. Both are correlations from one platform.

Read together they support a modest conclusion: long presenter-led stretches correlate with worse outcomes, and buyer participation correlates with better ones. No public study isolates the effect of any demo method with a control group. Test it on your own pipeline: compare stage progression after demos run each way.

have a fallback for every live demo

Security demos depend on environments: a lab with simulated attacks, realistic users, sample logs. They break. Navattic’s 2026 survey found that maintaining demo environments took about three hours per person per week, and that only 39% of teams had dedicated resourcing for it. Keep a captured version of the same story, or full-screen screenshots of the key results, for every live demo. If the lab is down, the inverted order means you can still show the result first.

the question for your presales team

In your last five demos, at what minute did the buyer first see the result they told you they wanted?