Demo strategy

Demo Strategy

Before starting

Confirm (ask or infer) before running:

• Demo type — live demo (customer site / showroom) / trade show / distribution video / partner demo kit?
• Audience — operations manager, EHS/safety, procurement, executive, technical engineer? (each requires different emphasis)
• Application — which exact task(s) will be shown? (demo = most compelling application, not most impressive spec)
• Customer's current process — what are they doing today? (the demo must show the contrast)
• Hard case available? — can you show an edge case or failure-and-recovery in this demo? (the most credible trust signal)
• Video destination — if video: LinkedIn / trade show screen / website hero / YouTube / sales email? (determines length)

---

Contract

This skill guarantees:

• Every demo output follows "show work, not specs" — specs appear only as validation of what was just shown
• The five-step sequence is applied (or the deviation is explicitly justified)
• The hard case (step 3) is included — not skipped "because showing failure looks bad"
• Video length is matched to its destination
• Application library is structured for partner lookup, not internal documentation

---

Role: Demo Director. For hardware and robotics products, the demo IS the sales pitch. A mediocre demo of a great product is a failed sales motion. A great demo of a mediocre product wins deals. Your job is to design the demo as a persuasion artifact, not a technical walkthrough.

---

Inputs

Required before proceeding:

• Product name and the specific application being demonstrated
• The customer's current process (the "before" state)
• Key performance numbers (cycle time, accuracy, uptime — real, measured)
• At least one edge case or failure-and-recovery the system can demonstrate
• Demo context (live or video; audience type; destination if video)

---

The core principle

WRONG: "This robot has a 6-axis arm, 2mm repeatability, and 10kg payload capacity."
RIGHT: "Watch it pick this part from a randomly oriented bin, verify it against
        the quality spec, and place it precisely — 40 times per minute, for 8
        hours without adjustment."

Every demo answers one question: What does this change about the customer's operations?

Specs appear AFTER the demo shows the result — as validation, not as the pitch.

---

Step 1 — Select the demo format

FORMAT SELECTION

IF demo context = live (customer site or showroom)
  → Run Step 2 (five-step live demo sequence)
  → Also run Step 4 (customer site specifics)

IF demo context = video for distribution
  → Run Step 3 (video formula by length)
  → Also specify destination from the length table

IF demo context = partner demo kit
  → Run Step 2 (five-step sequence as the script)
  → Run Step 5 (application library structure)
  → Note: partner demo kits require the hard case documented in writing;
    partners cannot handle demo failures without preparation

IF demo context = trade show
  → Run Step 3 (15–30 second loop format)
  → Design for no narration required — trade show floor is loud;
    the demo must work silently with data overlays only

---

Step 2 — Five-step live demo sequence

FIVE-STEP SEQUENCE

1. THE PROBLEM (30 seconds)
   Show the status quo: the manual task, the error rate, the person doing the job.
   Make the inefficiency visible. Never assume the prospect already feels this pain.
   
   What to show: real footage or live demonstration of the current process,
   OR a verbal description of the problem with a single number ("This takes 3 people
   and produces a 2% defect rate")
   
   Do NOT skip this step. If you start with the robot, the audience has no contrast.

2. THE SOLUTION IN STEADY STATE (1–2 minutes)
   Show the system running the same task, working correctly, at production speed.
   Do not narrate more than necessary. Let the machine speak.
   
   Narration rule: name what's happening once ("picking from a randomly oriented bin"),
   then stay silent. Running commentary reduces perceived competence.
   
   What to show: the full cycle, unedited, at actual speed (not accelerated).
   If the cycle is faster than it appears — state the speed; don't show a time-lapse.

3. THE HARD CASE (30–60 seconds — the trust signal)
   Show a challenging input: an edge case, a failure-and-recovery, a variant
   the system handles.
   
   This is where most hardware demos fail. Teams skip it because "showing failure
   looks bad." The opposite is true: a system that fails gracefully and recovers
   predictably is MORE trustworthy than one that appears only in perfect conditions.
   
   What to show:
   - An edge case part (unusual size, orientation, surface condition) the system handles
   - OR a deliberate interruption (something placed incorrectly) and the system's response
   - OR a failure mode and recovery sequence
   
   Script for the hard case: "Now I'm going to show you something our customers always ask
   about — what happens when [edge case]. Watch." [Demonstrate.] "The system [detected /
   paused / recovered] and [specific behavior]. This is designed behavior, not luck."

4. THE NUMBERS (30 seconds)
   One to three outcomes stated plainly with real units.
   
   Format: "[Metric]: [Value]. [Metric]: [Value]. [Metric]: [Value]."
   Example: "Cycle time: 18 seconds. Error rate: less than 0.1 percent.
             Uptime over three months: 99.2 percent."
   
   Rules:
   - Real numbers only — estimates and projections are flagged as such
   - No ranges in the headline ("18–24 seconds") — use the worst-case real number
   - If you cannot state real numbers, explain what the POC will measure

5. THE CONTEXT (30 seconds)
   Who else uses this. One customer name if permitted, or a category description.
   A system running in production elsewhere is worth more than any claim.
   
   Format: "[Customer name / tier-1 automotive supplier / three food processing plants]
            has been running this system for [duration] at [location type].
            Results: [one sentence on outcome]."
   
   If no customer reference exists yet: "We have run this application in our
   facility under production conditions for [duration]. Results: [specific data]."
   A self-reference with real data outperforms a vague claim about customer success.

---

Step 3 — Video formula by destination

VIDEO LENGTH TABLE

Length     | Best destination                              | Format
15–30s     | LinkedIn, Twitter/X, trade show screens      | Loop-optimized; no narration required
60s        | Website hero, YouTube pre-roll, sales emails | Standard formula (see below)
3–5 min    | Technical deep dive, YouTube, customer follow-up | Extended five-step sequence
10–20 min  | Full demo for qualified prospects, conference | Full demo + Q&A simulation

60-SECOND VIDEO FORMULA

0–8s:   THE PROBLEM. One visual, no narration. Show the before.
        Example: person manually inspecting parts on a line, stack of rejected units
8–45s:  THE SYSTEM WORKING. Close-up of the key action. Data overlays only
        (speed counter, accuracy display, cycle count) — no voiceover.
        The machine is the narrator.
45–55s: THE OUTCOME NUMBER. Large text on screen. One metric.
        Example: "99.2% uptime. 3 months. 0 unplanned stops."
55–60s: PRODUCT NAME + ONE-LINE CLAIM.

NO NARRATION RULE (core demo segment, seconds 8–45):
A robot doing its job is more convincing than a narrator describing it.
Narration during the demo signals that the visual alone is not convincing.
If the demo needs a narrator to explain why it's impressive, the demo is not impressive enough.

TRADE SHOW LOOP (15–30s):
Design for: no audio dependency, high contrast visuals, single metric
The only text on screen is: [action happening] + [one number]

---

Step 4 — Customer site demo specifics

CUSTOMER SITE DEMO PROTOCOL (highest credibility format)

Before the visit:
  → Request a sample of the customer's actual parts/materials before the visit
  → Confirm parts in advance; run internal test with customer parts before the demo
  → IF customer parts cannot be obtained → use the closest available substitute
    and state clearly: "We're using [substitute]. Your parts will be provided for the POC."

At the demo:
  → Run the demo with their parts, in their facility, with their team watching
  → A robot that handles the customer's actual edge case in their facility is worth
    10 trade show demos
  → If a failure occurs during the demo: name the failure clearly.
    Do NOT ignore it or explain it away.
    
    FAILURE SCRIPT: "The system [stopped / flagged / recovered] because [specific reason].
    In production, this would be handled by [specific mechanism].
    Let me show you that recovery."
    
    Transparency during a failure is a buying signal.
    Customers evaluate your process, not your luck.

After the demo:
  → Confirm the next step before leaving: POC or more qualification?
  → If the customer requests a POC: proceed to hardware-gtm/poc-pilot/SKILL.md

---

Step 5 — Application library structure

An application library is the partner's answer to "does it handle [specific thing]?"

APPLICATION LIBRARY STRUCTURE

Organize by:
  Level 1: Industry (automotive / food & beverage / electronics / logistics / other)
  Level 2: Task type (pick-and-place / inspection / assembly / palletizing / other)
  Level 3: Specific application (bin picking, kitting, quality check, etc.)

Each entry contains:
  [ ] Video clip (60 seconds or under) — the five-step sequence compressed
  [ ] Part specification: what was handled (material, weight, size range, surface)
  [ ] Performance numbers: cycle time, accuracy, uptime — real measured values
  [ ] Edge cases shown: which hard cases appear in the video
  [ ] Customer reference: permission level (named / industry category / "internal test")

PARTNER USAGE:
  When a prospect asks "does it handle [specific part type]?" →
  Partner searches application library by industry + task type →
  Sends the closest video clip with a note: "Here's a similar application.
  We can run your specific parts in a POC."

ANTI-PATTERN: an application library organized by product feature instead of
customer application. Partners look for "automotive bin picking" not "vision system v2".

---

Output format

## Demo Brief

**Product:** [Name]
**Application:** [Exact task being demonstrated]
**Audience:** [Role(s) — what they care about]
**Format:** [Live / 60s video / Trade show loop / Partner kit]

### The contrast statement
Before: [Customer's current process — one sentence with a number]
After: [What the system does differently — one sentence]

### Five-step script (live demo)

Step 1 — Problem (30s):
[Script: what to show and say]

Step 2 — Steady state (1–2 min):
[Script: what to show; narration instruction]

Step 3 — Hard case (30–60s):
[Script: which edge case; what to say when it happens]

Step 4 — Numbers (30s):
[Exact metric statement: "Cycle time: X. Error rate: Y. Uptime: Z."]

Step 5 — Context (30s):
[Reference statement]

### Video brief (if applicable)
Destination: [LinkedIn / Website / Trade show / etc.]
Length: [Xs]
Narration: [None (seconds 8–45) / Voiceover for intro/outro only]
Key metric on screen: [One number]

### Application library entry (if applicable)
Industry: [Category]
Task type: [Category]
Specific application: [Name]
Parts handled: [Description]
Performance numbers: [Real values]
Hard cases shown: [List]

---

Brain reads / writes

If a companion brain repo is connected:

Before starting:

• Read knowledge/icp-map.md — ICP segment determines which metrics the audience cares about most (operations manager cares about uptime; EHS cares about safety data; procurement cares about cost per unit)
• Read playbooks/messaging.md — confirm the demo contrast statement matches the positioning narrative

Brain write (after demo is used):

• Write demo performance notes to decisions/: which format, audience, outcome (POC requested / not requested), and one observation about what landed

Brain not connected: proceed normally.

---

Anti-patterns

Anti-pattern	Why it fails	Fix
Opening with specs	Audience has no context for whether specs are good or bad without seeing the work	Open with the problem; show the work; specs validate after
Narrating during the core demo	Running commentary signals the visual isn't convincing on its own	Let the machine run; narrate before and after, not during
Skipping the hard case	Audience assumes perfect conditions only; trust never builds	The hard case is not optional; it is the trust signal
Using accelerated video	Looks like you're hiding the real speed; destroys credibility	Show at actual speed; state the cycle time as a number
Organizing application library by feature, not application	Partners can't find what they need during a customer meeting	Organize by industry → task → specific application
No customer reference at the end	The demo is a claim without social proof	"A tier-1 automotive supplier has been running this for 8 months" beats any feature description
Vague outcome numbers ("significant improvement")	Buyers can't build a business case with adjectives	Real numbers with units only; if no real numbers yet, describe the POC metric design

---

Benchmarks (2025–2026)

Benchmark	Value	Notes
Demo-to-POC conversion rate (well-designed live demo)	30–50%	For well-matched ICP; drops sharply if demo application doesn't match buyer use case
Demo-to-POC conversion rate (trade show demo, cold audience)	5–15%	Trade shows are awareness, not qualification; follow-up is where conversion happens
Optimal video length for LinkedIn hardware demo	30–60 seconds	Drop-off after 60s is sharp; first 3s determine if viewer continues
Customer site demo vs. trade show demo (conversion rate ratio)	3–5x higher for customer site	Customer's own parts + their facility = highest credibility context
Application library search-to-demo rate (qualified partners)	Partner can answer a prospect question in <2 minutes with the library	If partner has to ask you, the library needs work
Hard case inclusion rate in demos that closed to POC	Highly correlated with trust building	Not quantified universally, but absence is consistently cited in lost deal analyses

---

Related skills

Skill	When to use
hardware-gtm/poc-pilot/SKILL.md	Demo that earns a POC commitment; POC design follows the demo
hardware-gtm/channel-strategy/SKILL.md	Partner enablement requires demo kits and application library
hardware-gtm/safety-trust/SKILL.md	Demo audience includes EHS/safety stakeholders: safety data belongs in Step 4
pmm/content-review/SKILL.md	Demo scripts and video briefs can be reviewed for messaging quality

---

Validation criteria

• Demo opens with the problem (not specs)
• Core demo segment runs without narration
• Hard case is included and scripted — not skipped
• Numbers in Step 4 are real measured values (no estimates presented as results)
• Customer or deployment reference included in Step 5
• Video length matches its destination
• Application library organized by industry and task type (not product feature)

References & Sources

Tier 1:

• hw-demo-strategy (growth-skills v1.0, score 7.5/10): five-step demo sequence, 60-second video formula, live demo design, no-narration rule, application library structure