Designs and scripts hardware product demonstrations: live demos, 60-second distribution videos, and application library content. Applies the five-step demo sequence and no-narration rule. Outputs a demo script, video brief, or application library structure depending on the context. For hardware and robotics products, the demo IS the sales pitch — this skill prevents the most common demo failure modes.
Designs and scripts hardware product demonstrations: live demos, 60-second distribution videos, and application library content. Applies the five-step demo sequence and no-narration rule. Outputs a demo script, video brief, or application library structure depending on the context. For hardware and robotics products, the demo IS the sales pitch — this skill prevents the most common demo failure modes.
triggers
["/demo-strategy","/demo","user is preparing a hardware product demo","user needs to create a demo video or application library","partner needs demo assets before customer meetings"]
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
