How to Explain a Complex Automation Product in 60 Seconds: 7 Rules

Your product took years to engineer. Your viewer gives you a minute. Here's how to survive the compression.

If you market an automation product, you've lived this meeting: engineering says the video oversimplifies, sales says it's still too complicated, and somewhere a 60-second cut is waiting for approval from both. The problem isn't your product — it's that a complex system and a short video obey different physics, and someone has to negotiate between them.

We've done that negotiation many times, filming autonomous systems and industrial machines in the field and then compressing them into a minute. These seven rules are how the good 60-second explainers get made.

1. One Message Per Video

The fatal mistake is trying to say everything. A 60-second video holds one idea well, two ideas badly, and three not at all. Decide the single sentence a viewer should be able to repeat afterward — "this robot picks parts no human wants to pick," "this system keeps the fleet routed without a dispatcher" — and cut everything that doesn't serve it.

Every feature you defer isn't lost. It becomes the next video. That reframe usually ends the stakeholder tug-of-war, because nobody's feature is deleted — it's just scheduled. It also happens to be better strategy: a library of focused one-minute videos, each answering a different stakeholder's question, outperforms one overloaded film at every stage of a long B2B cycle.

2. Outcome Before Mechanism

Structure the minute in this order: the problem, the outcome, then — only if there's room — the mechanism. Viewers lend you attention for how it works only after they care that it works. A script that opens with sensor architecture is answering a question nobody has asked yet.

A rough shape that reliably works:

1. 0–10s: the task or pain, shown concretely
2. 10–35s: the product doing the task, outcome on screen
3. 35–50s: one differentiating "how" — the single mechanism worth explaining
4. 50–60s: who it's for and what to do next

3. Concrete Beats Abstract — Show the Task Being Done

"Optimizes intralogistics workflows" is a phrase; a robot moving a pallet from dock to rack is a fact. Whenever a script line is abstract, ask what the camera would actually see. If the answer is "nothing," rewrite the line until it names a task, a place, and a result. Automation has an unfair advantage here: the product visibly does something. Point a camera at that.

This is also where field footage beats stock and renders. A real facility carries texture — forklift traffic, scuffed floors, actual product moving — that tells the viewer this isn't a concept. Sixty seconds doesn't leave room to argue for credibility; the frame has to carry it on sight.

4. Use Analogies That Survive Engineering Review

Analogies are how a minute carries complexity — but a sloppy one dies in review and takes your timeline with it. The analogies that survive share three traits:

• They map to what the system actually does, not to what sounds impressive
• They're scoped: "it works like X in this one respect," not "it's basically X"
• They've been pressure-tested with an engineer before the script is locked

Bring your skeptical engineer in early, ask "where does this analogy break?", and adjust the wording until the break point sits outside the video's claim. That ten-minute conversation saves two rounds of revisions.

5. Design the Visual Hierarchy — Decide What the Eye Follows

In sixty seconds, the viewer's eye can't wander and still get the message. Every shot should have one designated thing to look at: the gripper closing, the path the vehicle takes, the number changing on the interface. Composition, focus, lighting, and on-screen graphics all exist to enforce that hierarchy. When we storyboard these videos — often with quick AI pre-vis passes in Midjourney or Runway before the shoot — the first question on every frame is "what does the eye follow here?" If the answer takes a sentence, the shot is too busy.

6. Let Animation Carry the Invisible

Live footage proves; animation explains. The rule of thumb: if the thing you're describing is visible — a robot arm, a vehicle, a conveyor — film it. If it's invisible — software logic, sensor coverage, a data pipeline, what happens inside the enclosure — animate it. Motion graphics can show a lidar field sweeping a room or a decision flowing through a system in a way no camera can.

The strongest explainers cut between the two: real footage of the machine acting, animation revealing why it acted. The footage earns trust; the animation earns understanding.

Two practical notes. Keep animated sequences in the same visual language as your footage — matched color, matched pacing — so the cut between them feels like one video, not two stitched together. And keep animation honest to scale and behavior: an engineer will notice a sensor field drawn wider than the spec sheet allows, and the whole video pays for it.

7. Run the Accuracy-vs-Clarity Negotiation Deliberately

The tension between engineering accuracy and marketing clarity never disappears — so manage it instead of suffering it. A process that works:

• Marketing drafts the script for clarity first, flagging every simplification knowingly made
• Engineering reviews with one question: "is anything here false?" — not "is anything incomplete?"
• Disputed lines get rewritten together, live, in one session — not over email threads
• Both sides accept the standard: simplified-but-true beats complete-but-unwatched

Agree on that standard before scripting starts and reviews stop being battles. The 60-second video isn't the technical documentation; it's the reason someone reads the technical documentation.

The Bottom Line

Sixty seconds is enough — if you spend it on one message, lead with the outcome, show the task concretely, and split the work honestly between footage that proves and animation that explains. The discipline isn't in the edit; it's in the decisions before the edit. Make them deliberately and the minute will hold more than you think.