Demo Delivery And Storytelling

Demo Delivery & Storytelling

Purpose

Turn a working prototype into a convincing demo. A working prototype and a good demo are not the same thing — many technically competent prototypes fail at demo time because they're presented as a feature list ("let's look at everything this can do") instead of concretely proving the customer's own critical business issue. This skill applies Peter Cohan's Great Demo! methodology (an established framework in the sales-engineering literature) to an AI consultant's demo situation.

Anchored in research

• Cohan, Peter E. — Great Demo! How To Create And Execute Stunning Software Demonstrations (third edition) and Paul Pearce's "Great Demo! Five Imperatives" application: Discovery, Demo Prep, Demo Delivery, Documentation, Debrief. Core concepts: the Situation Slide (a concise summary of the customer's situation before the demo), the critical business issue (CBI), and "do the last thing first" / the inverted pyramid (show first the thing that produces the "wow" effect — don't build the demo chronologically as a product walkthrough).

Method

Applied Great Demo! Five Imperatives structure:

1. Discovery — before you build anything for the demo. Establish the customer's critical business issue (CBI): what concrete pain do they have today, who owns it, when does it need to be solved, and how much value would a solution create. If you can't answer these, you're not ready to build a demo yet — go back to ../../../opportunity-recognition/skills/pattern-and-analogy-connector/SKILL.md or ../../../ai-strategy-and-governance/skills/ai-capability-pattern-matching/SKILL.md to sharpen the situation first.
2. Demo Prep — write the Situation Slide before the demo. One slide/paragraph summarizing: the customer's situation, the CBI, the capabilities needed, the value sought, the timeline. Also assemble: the demo's outline and agenda, possible side paths in case the customer asks something unexpected, demo data that resembles the customer's OWN data (generic sample data is noticeably weaker), and reference stories from similar situations.
3. Demo Delivery — apply "do the last thing first." Don't start with an overview or the technical architecture — start with the one thing that concretely resolves the CBI and produces a "wow" reaction. The inverted pyramid: the most important thing first, background and detail only if interest holds up. Ask questions during the demo instead of delivering a monologue — this reveals in real time how the audience is experiencing the value and what they still need to decide.
4. Always tie the demo back to the frame already set in ../demo-framing-and-expectation-setting/SKILL.md: remind the audience what this demo proves and what it doesn't, and don't let the drama of the demo carry the frame away (an excited audience easily over-interprets).
5. Documentation — share the Situation Slide and a demo summary immediately after the demo. Research (see References) shows that most of a demo's content is forgotten within a week — the written summary is what the audience actually takes away and shares within their organization. Record the CBI, what was proven in the demo, and the agreed next steps.
6. Debrief — review what worked and what didn't right after the demo, while it's still fresh: which questions were surprising, which part of the demo produced the most reaction, what should be done differently next time. This matters especially for an AI consultant who runs several similar demos back-to-back for different customers — learnings compound quickly if the debrief is done systematically.
7. A special note for vibe-coded prototypes: never improvise, in a live demo, paths that haven't been tested in advance — the failure modes of an AI-assisted prototype can be unpredictable. Keep the demo strictly to the 2-3 tested paths confirmed to work during Demo Prep (see ../rapid-prototype-and-vibe-coding-craft/SKILL.md step 4).

What this skill does NOT do

• Doesn't build the prototype itself — see ../rapid-prototype-and-vibe-coding-craft/SKILL.md.
• Doesn't set the demo's frame (the PoC/Pilot/MVP term, the proves/doesn't-prove pair) — that's done before this skill in ../demo-framing-and-expectation-setting/SKILL.md.
• Doesn't replace the sales process as a whole — it focuses on one demo event following the Great Demo! methodology, not the entire sales cycle.
• Doesn't guarantee that a good demo leads to a deal or advancement — a good demo removes obstacles, but the decision is always the customer's.

Refinement notes

Areas to keep deepening with real practice:

• your own Situation Slide templates (into ../../references/)
• concrete examples of demos that worked especially well — and what made them work
• rules of thumb for how to react when a demo goes wrong live (e.g. the AI gives a wrong answer mid-demo)

This is an internal working note, not a claim about the skill's current usability. Track depth privately via the maturity field in skills_index.json (see ../../../meta/maturity_levels.md). Don't add new fields to the frontmatter — name and description are the only ones allowed (see ../../../meta/frontmatter_schema.md).

Continue from here

• Before this (prototyping): ../rapid-prototype-and-vibe-coding-craft/SKILL.md
• Before this (framing): ../demo-framing-and-expectation-setting/SKILL.md
• A deeper narrative for leadership: ../../../change-and-communication/skills/executive-narrative-and-storyline/SKILL.md
• If the demo succeeds: ../demo-to-business-case-bridge/SKILL.md
• A ready-made skill chain for this situation: see ../../../playbooks/
• This pack's shared guardrails: ../../CLAUDE.md

References

• Cohan, Peter E. — Great Demo! How To Create And Execute Stunning Software Demonstrations
• Pearce, Paul H. — "Great Demo! Five Imperatives" application (Discovery, Demo Prep, Demo Delivery, Documentation, Debrief)
• Research on demo content being forgotten without written documentation (sales engineering literature)
• ../../references/ — the pack's shared background material
• ../../CLAUDE.md — the pack's shared guardrails