How to Explain Deep Tech on Camera Without a Whiteboard

Every deep tech founder we film has the same instinct. About ten minutes into the interview they reach for something to draw on: a whiteboard, a napkin, the back of the call sheet, whatever is nearest.

It makes sense. The thing they are explaining is genuinely complicated, and drawing it is how they have explained it to every engineer they have ever worked with.

Then they turn around to draw, and the camera spends ninety seconds watching someone's back.

Every deep tech video we have made has run into some version of this, whether the subject was quantum computing or language technology. The subject matter is real. The person explaining it knows more about it than anyone else in the room. And the format that works beautifully in a meeting falls apart the moment it has to survive on a phone screen, in a feed, with the sound off.

Complexity is rarely the real problem. Sequence is.

A viewer will follow almost anything, as long as each piece arrives in an order they can absorb and nothing lands before they are ready for it.

Most technical explanations fail because the expert starts in the middle. They start where their own attention lives, which after fifteen years in a field is a very long way down the road. The viewer is still at the beginning, working out why any of this should matter to them.

So we open every interview somewhere else entirely: what was broken before this existed?

That question does two useful things. It hands the viewer a problem to hold onto, which is the only thing that makes a solution interesting. And it gets the founder talking like a person instead of a spec sheet, because they remember the frustration, and the frustration is where the energy is.

Cut the definition, keep the consequence

On camera, the instinct is to define terms. Explain precisely what the technology is before saying what it does.

Definitions are where attention goes to die. In most of our edits, the definitional passage is the first thing out of the timeline. What stays is the consequence: this used to take six weeks, now it takes an afternoon. The same information, arriving in a form a human can actually use.

If the precise definition matters, and sometimes it really does, it belongs on the website, in the documentation, in the technical one pager. The video's job is to make someone want to go and read those.

One idea per shot

A shot can carry one idea. Two ideas in one shot means the viewer keeps the first and loses the second, and they will not tell you which one they lost.

This sounds obvious until you watch a founder answer a question in a single unbroken ninety second take containing four separate arguments. The answer is often excellent. It is also unusable as one piece.

So we break it. Each idea becomes its own beat, with its own visual, its own pause, its own breath. The total runtime barely changes. What changes is how much of it survives contact with the viewer.

Let the edit carry the diagram

Here the whiteboard instinct is right. Some ideas genuinely are spatial, and words alone will not carry them.

We move that into post rather than staging it on camera. The founder describes the idea looking down the lens, and the diagram builds underneath them, one element at a time, paced to the sentence. Nobody turns their back. Nothing gets drawn badly under time pressure. And the build can be revised six months later when the architecture changes, without booking a reshoot.

Motion graphics tend to get sold as decoration. Used properly they are the load bearing part of a technical explanation, and they usually cost less than the extra shoot day people budget instead.

The script gets written in the interview

We arrive with questions rather than a finished script, because the sentence a founder says without thinking is almost always better than the sentence they would have written.

Written technical copy drifts towards the passive and the abstract. Spoken answers stay concrete, because the person is remembering something specific that actually happened. Our job on the day is to ask the question that makes them remember the right thing, and then to stay quiet long enough for them to get there.

The edit is where the script really gets assembled, out of what was said rather than what was planned.

The test we use before anything goes out

We show the cut to someone with no background in the subject and ask them to explain it back to us.

Not whether they liked it. Explain it back. If they can say what the problem was and roughly what the technology does about it, the video works. If they compliment the visuals and still cannot tell you what the company does, it does not, however good it looks.

That test has killed more of our own edits than any client note ever has. It is also the reason the ones that survive tend to do their job.

The takeaway

If you are sitting on a technology that everyone inside your industry understands and nobody outside it does, the gap is usually in the order the story arrives in. Sort the sequence first, then spend the money on the shoot.

You can see how that plays out across our client work.