How should I structure a sales demo?

Open by recapping discovery so the demo is about their problems, not your product. Then run tell-show-tell once per priority: tell them what you'll show and why it matters to them, show it on their use case, tell them the outcome. Check in after each moment, then close by confirming what they saw solves what they came for and asking them to name the next step.

What is tell-show-tell in a demo?

A three-part loop for each thing you demo. Tell: name the problem and say you'll show how it's handled, so the prospect knows what to watch for. Show: walk the actual workflow on their use case. Tell: connect what they just saw back to the outcome they care about. The opening tell sets the lens, the show proves it, the closing tell makes it matter.

How many features should I show in a demo?

Three or four, each tied to a problem the prospect named in discovery, not your full feature set. A feature that doesn't map to something they told you hurts is noise, and noise dilutes the things that do matter. The strongest demos feel short because every moment is relevant. Forty features shown is forty chances to lose attention.

Why is my demo not converting?

Usually one of three reasons: it's a feature tour instead of a problem-solving session, it isn't anchored to discovery so it has nothing to be about, or it's a silent monologue with no check-ins, so objections pile up until the close. Fix it by recapping discovery up front, showing only what maps to stated problems, and asking how each moment compares to how they work today.

Resources · Demo

Sales demo script.

A demo framework that sells instead of features-dumps: tell-show-tell, tied back to discovery, structured so the prospect sees their own problem solved, not a product tour.

In short

The best demo is not a feature tour. It's three to four moments, each tied to a problem the prospect named in discovery, run through tell-show-tell.
Tell them what you'll show and why it matters to them, show it on their use case, then tell them the outcome. Repeat for each priority.
Open by recapping discovery so the demo is about their problem, not your product. Close by confirming what they saw solves what they came for.

Why most demos lose the deal

The default demo is a tour: click through every feature, hope something sticks. It loses because it makes the prospect do the work of mapping your product onto their problem, and they won't. A demo that sells does the opposite. It shows three or four things, each tied directly to something the prospect told you hurts, and it does the mapping for them.

The framework below is built on two rules. First, the demo is anchored to discovery, if you didn't run good discovery, you have nothing to anchor to, and the demo will drift into a tour. Second, every moment runs through tell-show-tell so the prospect always knows why they're watching this.

Step 1

Open by recapping discovery

Say: "Before I show you anything, last time you told me [problem one], [problem two], and [problem three] were the big ones, and that [the impact] was what made this urgent. Did I get that right, and is that still where you want me to focus?"

Why it works: this single move reframes the entire demo from "watch my product" to "watch me solve your problem." It also gets a yes that makes everything after it feel relevant, and it gives the prospect a chance to re-rank their priorities so you spend your time on what matters most to them today.

Step 2

Tell-show-tell, once per priority

For each problem they named, run the loop. Tell: "You said [problem]. Here's how we handle that." Show: walk through the exact workflow on their use case, using their language and their data shape, not a generic sample. Tell: "So instead of [the old painful way], it's [the new way], which means [the outcome they care about]."

Why it works: the opening tell sets the lens so the prospect knows what to watch for. The show proves it's real. The closing tell connects what they just saw to the outcome they told you they wanted. Three or four of these, in priority order, beats forty features every time. When a feature doesn't map to a problem they named, cut it, it's noise.

Step 3

Check in between moments

After each tell-show-tell, stop and ask: "How does that compare to how you do it today?" or "Is that the kind of thing that'd move the needle for your team?"

Why it works: a demo is a conversation, not a presentation. These check-ins keep the prospect engaged, surface objections while you can still address them, and tell you whether to go deeper or move on. A monologue demo lets doubts pile up silently until the end, when they come out as "let me think about it."

Step 4

Close by tying it back

Say: "So we covered [problem one], [problem two], [problem three], the three things you said mattered most. Did what you saw handle them the way you'd hoped? And what's the natural next step on your side?"

Why it works: the close confirms the demo did its job, solved the problems they came with, and hands the prospect the job of naming the next step, which commits them more than you naming it. If something didn't land, this is where you find out, while you're still in the room to fix it.

Nobody buys a feature tour. They buy seeing their own problem solved. Show three things they care about, not forty things you built.

The Lateral team

Demo mistakes that cost deals

The big one is the feature dump, showing everything because you're proud of it, instead of the few things they need. The second is no anchor: if you skipped discovery or didn't recap it, the demo has nothing to be about and turns into a tour by default. The third is the silent monologue, talking for twenty minutes without a single check-in, so objections pile up until the close.

The fix for all three is the same discipline: anchor to discovery, show only what maps to a stated problem, and check in after every moment. Get those right and the demo stops being a tour and starts being the reason they buy.

Frequently asked

How should I structure a sales demo?: Open by recapping discovery so the demo is about their problems, not your product. Then run tell-show-tell once per priority: tell them what you'll show and why it matters to them, show it on their use case, tell them the outcome. Check in after each moment, then close by confirming what they saw solves what they came for and asking them to name the next step.
What is tell-show-tell in a demo?: A three-part loop for each thing you demo. Tell: name the problem and say you'll show how it's handled, so the prospect knows what to watch for. Show: walk the actual workflow on their use case. Tell: connect what they just saw back to the outcome they care about. The opening tell sets the lens, the show proves it, the closing tell makes it matter.
How many features should I show in a demo?: Three or four, each tied to a problem the prospect named in discovery, not your full feature set. A feature that doesn't map to something they told you hurts is noise, and noise dilutes the things that do matter. The strongest demos feel short because every moment is relevant. Forty features shown is forty chances to lose attention.
Why is my demo not converting?: Usually one of three reasons: it's a feature tour instead of a problem-solving session, it isn't anchored to discovery so it has nothing to be about, or it's a silent monologue with no check-ins, so objections pile up until the close. Fix it by recapping discovery up front, showing only what maps to stated problems, and asking how each moment compares to how they work today.