---
name: show_and_tell_video
description: "Make show-and-tell videos from real work: inventory the proof you already have, score episode ideas, and order the shoot so the strongest evidence leads. Use when planning a demo, case study, build log, portfolio, launch, or work-in-progress video from finished work, tests, before-and-after results, or a customer outcome."
---

# Show and Tell Video

## Purpose

Turn work that already happened into a video a viewer can believe. The method starts from proof, not from a script. You list what you can actually show, score ideas against that proof, and build the episode around the strongest evidence first. Any subject fits: software, craft, design, a service job, a repair, a research result, a community project.

A weak version lists features and asks the viewer to trust the narration. A strong version pairs every claim with a shot that proves it, shows a limit honestly, and ends with a result the viewer saw happen.

## Workflow

### 1. Inventory the proof you already have

Walk the last 30 to 90 days of work and fill a proof inventory before writing any script. One row per item:

| Field | What to record |
|---|---|
| Proof item | The artifact, result, or moment itself |
| Type | Finished artifact, before and after, live test, screen recording, process artifact, metric, quote, failure and fix, third-party check |
| Claim it supports | One sentence, in plain words |
| Source | File, link, log, dashboard, or person who can confirm it |
| Permission | Cleared, needs ask, or private. Note redactions needed |
| Showability | Can a camera or screen capture show it clearly in under 10 seconds? |
| Date | When the work happened, so stale proof gets flagged |

Hunt in places people forget: shipped files, tagged releases, test output, photos of the physical result, customer messages with permission, support threads, version history, and the messy middle steps. Process artifacts count. A sketch, a failed print, or a reverted draft proves the work was real in a way a polished final shot cannot.

Rule: if a row has no source and no way to show it, it is not proof yet. Park it.

### 2. Score episode ideas before committing

Group proof items into episode ideas. One idea needs one clear outcome for one audience. Then score each idea with `bin/score_episodes.py` (rubric in `references/scoring-and-slates.md`):

- Proof strength (0 to 5): 0 is assertion only, 3 is a visible result, 5 is an independent or measured result the viewer can inspect.
- Audience pain (0 to 5): how sharply the target viewer feels the problem this work solves.
- Showability (0 to 5): how well the proof reads on screen, muted, at phone size.
- Specificity (0 to 5): named job, real constraints, real numbers with a source, over general claims.
- Effort (0 to 5): shoot and edit cost. High effort lowers the total.

Total = proof + pain + showability + specificity + (5 - effort), out of 25.

Cutoffs from the scorer: 18 or more, shoot it and lead the slate. 13 to 17, shoot it after fixing the weakest score. 12 or under, park it or merge it into a stronger episode. Any idea with proof strength under 3 does not ship as a standalone episode, whatever the total. That gate is the whole point of the method.

### 3. Order the shoot so the strongest evidence leads

Shoot in this order, which is also the edit order:

1. Lead proof (first seconds): the finished result, the passed test, or the before and after contrast. No logo, no host intro, no agenda. The viewer sees the payoff the title promised.
2. Context (one or two sentences): who had what problem, under what constraint.
3. Process: the two or three steps that matter, each shown, not described at length.
4. Second proof: a different kind of evidence than the lead. If the lead was a visual result, this one is a measurement, a live test, or the user of the work reacting to it.
5. Honest limit: one thing that failed, cost time, or still does not work well. Name the fix or the current status.
6. Result recap and one next step: restate the outcome with its source on screen, then a single call to action or the next episode in the series.

Shoot the lead proof first while setups are fresh and light is best. If the lead shot fails on the day, you learn it early and can rebuild the episode around the second proof instead of discovering the problem in the edit.

Length follows the job, using Wistia 2026 State of Video planning ranges: under 1 minute for awareness clips, 1 to 5 minutes for explainers and demos, 5 to 30 minutes for case studies and walkthroughs that need to convert an already interested viewer. Pick the range before scripting and write to it. See `references/scoring-and-slates.md` for the source note.

### 4. Script as claim and evidence pairs

Write the script as a two-column shot list, not prose:

| Claim (narration or caption) | Evidence shot |
|---|---|
| The export used to break on large files | Screen recording of the old failure, then the same file exporting clean |
| It held up in daily use for a month | Dated photos or logs across the month, plus the owner saying what broke, if anything |

Rules for the list:

- Every claim gets a shot, a source on screen, or a cut. Opinion is allowed when labelled as opinion in the narration.
- Numbers appear with their source and date on screen. A number you cannot source does not go in.
- Before and after shots use the same angle, scale, and conditions, or the difference gets explained on camera.
- Tests run live or in one continuous take where the result matters. Cutaway edits inside a test invite doubt.
- Quotes come from real users of the work, with permission recorded in the inventory.

### 5. Shoot for the edit

- Capture the room or screen state before you change anything. You cannot reshoot a true before.
- Record clean audio for narration and at least 10 seconds of natural sound per location for edit points.
- Get each proof item twice: a wide shot for context and a tight shot that reads at phone size.
- Say the date, version, or job name on camera at the start of a test take. It anchors the proof and costs nothing.
- Log takes against inventory row numbers as you go. The edit then starts from proof, not from scrubbing hours of footage.

### 6. Edit and check

- Muted test: watch the full cut with sound off. The story and the proof should still read from picture and captions.
- Captions: provide checked captions, not raw auto-generated text. W3C WAI guidance treats auto-generated captions alone as insufficient. Check sync, punctuation, speaker labels, and important sounds.
- Visual information: if a chart, label, or on-screen result carries the proof, the narration or a descriptive transcript must carry it too, so viewers who cannot see the screen still get the evidence.
- Title check: the title makes one promise. The lead proof must confirm that promise. If it cannot, retitle the video to match what the proof shows.
- Retention review after publishing: in YouTube Analytics, use the key moments for audience retention report to find where viewers left, and log the timestamp and the beat that sat there. Feed that into the next episode's ordering. This is a check on your structure, not a vanity metric.

## Output Contract

Deliver, in this order:

1. Proof inventory table, with permission and source for every row used.
2. Scored episode slate: each idea with its five scores, total, verdict, and the scorer output.
3. Chosen episode shot list in claim and evidence pairs, in lead-proof-first order, with a target length and the goal it matches.
4. Shoot order for the day: lead proof first, then the rest, with setups grouped to avoid rebuilding them.
5. Publish checklist result: muted test, caption check, title against lead proof, numbers sourced on screen, permissions cleared.
6. After publishing, a short retention note: where viewers dropped, which beat was there, and one change for the next episode.

## Operating Rules

- Proof before script, always. An idea with no inventory rows behind it waits.
- Never stage a result and present it as a real outcome. A recreated step is labelled as a recreation on screen.
- Never invent numbers, dates, quotes, or outcomes. Unverifiable material gets cut or framed as opinion.
- Redact private data in proof before shooting, not in post where a frame can leak.
- One outcome per episode. Two outcomes means two episodes or one clear primary with the second cut to a mention.
- Show a real limit in every episode. A video with no friction reads as an ad and viewers discount the proof in it.
- Keep the raw proof files with the project after publishing. If a claim gets questioned later, the source should be findable in minutes.