Essay · AI & Defensibility
I lost a room a few months ago and it took me a while to work out why.
The meeting was going well. I was explaining the architecture of a company I help run, and I was explaining it accurately. Piezoelectric actuation. A resonant spiral scan. Four software modules with their regulatory pathway mapped out. Every sentence was true and every sentence was load-bearing. About eleven minutes in I watched a very smart investor stop taking notes, and I kept going anyway, which is the part I am least proud of.
Afterwards I did what most operators do, which is blame the audience a little. Then my own team told me they did not fully understand the same thing, and that excuse stopped working. These are people who have every incentive to understand it and who sit ten feet from the engineering. If they were fuzzy, the problem was upstream of the listener.
Here is what I had been doing wrong. I was explaining the mechanism when I should have been explaining the consequence. Those feel like the same act from the inside. They are not remotely the same act from the outside.
The sentence that fixed it
The company builds a very small imaging probe that looks forward inside a blood vessel. Existing devices look sideways. That distinction is the entire technical achievement, and I had been trying to convey it through the physics of how it is accomplished.
Existing imaging looks sideways, which is driving with only side mirrors. Our probe is a headlight. Once you have headlights, a navigation system becomes possible. The software is the navigation system.
That is it. No actuator, no scan geometry, no regulatory vocabulary. And the reaction was different in a way I did not anticipate. People stopped asking me what the software was and started asking what it would do. The analogy had not simply explained the product. It had made the product feel inevitable.
That last effect is the one worth understanding, because it is not what most analogies do.
Simplifying is not compressing
The common advice is to simplify. I think that advice is wrong, or at least badly incomplete. Simplifying means removing content until what remains is easy. Compressing means finding a smaller container that holds all of the content. One of those loses the argument. The other preserves it.
The headlight sentence is not a simplification. It carries the competitive claim, that nobody else can see forward. It carries the architectural claim, that the software depends on the hardware. And it carries the sequencing claim, that the hardware has to come first, which is the one that determines where the money goes. Three arguments in twenty-eight words. Nothing was thrown away. It was folded.
Which suggests a test. A simplification breaks when you push on it, because the content you removed is exactly what you need to answer the follow-up question. A compression extends, because the content is still in there.
Four tests for a load-bearing analogy
I have started applying these before I use one in a room that matters.
Does it extend without breaking? The headlight version kept going further than I intended. The four software modules turned out to map cleanly onto the four things a navigation system does. One identifies what is blocking the road, since a rockslide and standing water call for different responses. One reads whether the road will carry traffic once it is cleared. One puts every layer on a single map rather than four displays. One delivers all of it turn by turn while you are driving. I did not design that mapping. I found it, which is usually the sign that an analogy is structural rather than decorative.
Does it carry the hard part? A weak analogy explains the easy half and abandons you at the objection. The hardest question we get is what stops a large incumbent from doing this next year. Inside the same metaphor the answer is already sitting there. Navigation systems improve because a fleet of vehicles feeds them road data, and you cannot download someone else's miles.
Does it constrain you honestly? This is the one people skip. A good analogy should make your overclaims visible to you before it makes them visible to a specialist. Ours did. A navigation system does not steer the car, and the moment I said that out loud I understood something about how the product had to be positioned that I had been fumbling toward for months.
Does it survive the retelling? This is the real test and almost nobody applies it. You are rarely talking to the decision maker. You are talking to the person who has to reconstruct your argument, from memory, for people who were not in the room. Four technical names do not survive that trip. A navigation system does.
The failure mode
Analogies are dangerous in one specific way, and I walked straight into it.
Once the headlight framing worked, we built a visual around it. The first version carried a caption promising that the technology reveals all obstacles and curves and provides comprehensive real-time mapping. Both phrases are false for our device in a way a specialist would catch in about two seconds. The analogy had done what a good metaphor always tries to do, which is complete itself. Real navigation systems do map comprehensively. Ours does something narrower and more specific.
The analogy is allowed to explain the product. It is never allowed to describe the product. The moment it starts generating claims rather than conveying them, pull it back.
We rewrote the caption. The narrower version is still a very good story, and now it is a true one. That sequence, overclaim then correction, is worth expecting rather than being embarrassed by. A metaphor strong enough to be useful is strong enough to run ahead of the facts, and the discipline is catching it before a customer does.
Why this generalizes
Early in my career I wrote software on a hospital research team, and the job was to take a paper instrument the clinicians already understood and rebuild it for a computer. I was the least expert person in every one of those rooms. Later I spent most of a decade at Microsoft explaining technology across fifty-four countries, to audiences who shared neither my vocabulary nor much of my context. Those were the years I should have learned this lesson properly.
What I actually learned then, and then forgot, is that the explanation is not a wrapper around the product. In any business where the buyer cannot personally evaluate the technology, the explanation is part of the product. A thing that cannot be retold accurately is a thing that will be retold inaccurately, and you do not get to choose which version travels.
The expertise that lets you build something is the same expertise that makes you bad at describing it. You lose access to what it is like not to know. That is not a character flaw and you cannot think your way out of it, which is exactly why you need a test rather than an instinct.
The test I use now
It is simple enough to apply in the moment. Not: did they understand me. That question flatters both parties and it is easy to pass. The better question is whether they could explain it to somebody else tomorrow, without me in the room, and get it right.
Most of the time the honest answer is no. That is not a communication problem. It means I have not finished thinking.