A demo that nobody finishes is almost never one bad demo. It's a good demo that collected a screen at a time until the payoff moved to step eleven.
Nobody decided to build an eleven-step demo. Someone asked for the settings screen. Someone else wanted the integration mentioned. Each addition was reasonable on its own, and the demo got longer with no single moment where it went wrong.
Whether a demo is worth building at all covers the length rule. This is what to do once you've already broken it.
Find the step that pays off
Click your demo through and mark the first step where the viewer gets what they were promised. Not where the workflow finishes — where the point lands.
That's usually earlier than you'd expect, and it's rarely the last step. In most long demos the payoff sits somewhere in the middle and the remaining steps are completeness: the confirmation screen, the settings that prove it's configurable, the second example.
Everything after the payoff is optional. Everything before it is either necessary setup or padding, and the next two sections sort out which.
Cut behind the payoff
Start at the end and work backward. For each step after the payoff, ask one question: if this step disappeared, would the viewer be confused or just less informed?
Confused means it stays. Less informed means it goes.
For example: a confirmation screen that shows the result actually landed can be the thing that makes the demo believable — keep it. A settings panel demonstrating you can change the defaults is completeness. It answers a question this viewer hasn't asked yet, and it costs you the people who would have finished without it.
Most long demos lose three to five steps here without losing anything a first-time viewer needed.
Absorb the setup into the first frame
Now go to the front. Setup steps — navigating a menu, opening the right screen, choosing the record you'll work with — teach nothing and cost you viewers at exactly the moment their interest is highest.
Two ways to remove them:
Start further in. Open the demo on the screen where the work happens rather than at the dashboard. The viewer doesn't need to watch you arrive.
Fold the context into the first step's text. "You're in the campaign editor with a draft open" does in one sentence what three clicks did, and nobody skipped it because it was boring.
The rule of thumb: the first step should show the product doing something, not the product being found.
Check that the middle still reads as a sequence
Cutting from both ends leaves a seam. Two steps that were four apart are now adjacent, and the instruction on the second one may reference something the viewer no longer saw.
Click the whole thing through from the start, as a stranger, in one sitting. You're looking for three things:
- A step that references an action that's now cut.
- A jump where the screen changes more than the instruction explains.
- A step whose text still says "next" or "finally" in the wrong place.
This pass takes two minutes and it's the one people skip. A demo with a broken seam is worse than the long version, because the viewer now thinks they missed something.
Then decide whether it should have been two demos
Sometimes the cut reveals the real problem: the demo was answering two questions. One about setup, one about daily use. One for an evaluator, one for an admin.
If your list of "less informed" steps is long and internally coherent, that's the second demo. Publishing two focused demos and linking between them beats one that serves neither reader, and each one gets to be short.
The test: can you write a one-sentence promise for the whole thing? If the sentence needs an "and," you probably have two.
What not to do
Don't target a step count. Five steps is not a rule. A demo that needs seven steps to land its point should have seven. The question is whether every step is carrying the promise, not whether the total matches a number you read somewhere.
Don't speed up instead of cutting. Compressing the text on eleven steps leaves eleven steps. Length is the number of decisions the viewer has to make, not the word count.
Don't cut the payoff to save time. It happens more than you'd think — the confirmation goes because it looks like a formality, and the demo now ends before it proves anything.
Don't rewrite everything at once. Cut, publish, and watch where people stop now. One change, one reading.
How Arclet fits
In Arclet, steps are editable after capture, so this is an edit rather than a re-record: remove the steps you cut, rewrite the first step's text to carry the context, and publish the same demo link again.
After it's live, step-level engagement shows where viewers now stop — which tells you whether the cut moved the drop-off or just relocated it. Measuring demo engagement covers how to read that without over-reading it.
If the demo you're cutting also went stale, which demos a release breaks is the other repair pass worth doing while you're in there.