Demo builder

Purpose

A demo should create a buying decision, not complete a product tour. The buyer should see the outcome in the first minute, understand why this product delivers it when alternatives do not, see two or three realistic use cases, and be offered one next step. Depth is earned, not assumed. This skill builds that structure for a recording or a live session.

When to use

• A demo script or recording is needed.
• A live demo needs preparing.
• A demo keeps running long, or the buyer loses interest in the middle.
• A demo has been delivered and feedback should be captured.

Route elsewhere when:

• The question is which pains to prove and what to cut. Use discovery-to-demo-bridge.
• The question is the product's positioning. Use positioning-messaging-designer.

Inputs

1. Product and the full list of capabilities. Never demonstrate a capability that is not on the list.
2. Audience: role, seniority, buying stage, and technical level.
3. Industry or segment, which shapes the data and language.
4. Primary outcome for the audience, stated as their success, not the product's.
5. Mode: pre-recorded or live.
6. Alternatives: the competitors in the deal, the spreadsheet or manual process, and the status quo. Ask for these; do not infer them.
7. The differentiator against each alternative. If it is unclear, work through where each alternative breaks and what the product does there.

Optional, with defaults: length (three to five minutes recorded, twenty to thirty minutes live) and the environment (assume a live instance).

Procedure

1. Write the demo thesis. One sentence that connects outcome, segment, and differentiator. Every screen serves this thesis. A demo without a point of view is a tour.
2. Open with the outcome. Show the finished result: the dashboard, the output, the insight. No company overview, feature list, or login screen first.
3. Explain the mechanism. One minute on why the product delivers the outcome when the incumbent approach does not. Describe the mechanism, not the feature list.
4. Show two or three use cases, most important first. For each: the painful current method, the product doing the job in the fewest clicks, and the result in time, output, or error reduction. Each use case stands on its own.
5. Hold depth in reserve. Integrations, technical detail, and edge cases appear only when the buyer asks, the stage requires them, or an objection needs evidence. Have the screens ready, but do not show them unprompted.
6. Close. Recap the outcome, give one before-and-after story as proof, and offer one next step, not a menu.
7. Prepare the live version with discovery checkpoints, objection handles, a fallback if a screen fails, and an attendee map.
8. Debrief after delivery. Record what landed, what drew doubt, and what changed. If the same correction is needed twice, the skill is the gap. If the same doubt recurs across buyers, the narrative is the gap.

Output

• Pre-recorded: demo brief, script with voiceover, screen directions, and timing, and an optional shot list.
• Live: demo brief, talk track in bullets, click path with branches, checkpoints, objection handles, and a fallback plan.
• After delivery: a short debrief with one to three specific observations.

Quality bar

The outcome appears before the mechanism, and the mechanism before any feature. Every shown capability is on the list. Data is realistic for the segment. The close offers one next step. Watch for openings with the company's history, demos that show every module, invented capabilities, and multiple calls to action at the end.