Assume Nothing is the title of the book I am writing. It also works as a practical rule for explaining anything: before you explain, write down what you are assuming the other person already knows.
I have spent years explaining technically complex products to people outside the engineering team. The pattern repeats. The expert's knowledge becomes invisible to the expert. You stop noticing the acronym you never defined, the step you skip because it is obvious to you, the reason a feature exists that nobody told the listener.
Listeners rarely interrupt to say so. They cannot ask you to define something they did not realise was missing. They nod, and the gap goes with them into the next meeting.
A prompt has the same gap
A prompt is an explanation to a reader that has no context at all. It cannot nod, and it cannot tell you that something is missing. It fills the gap with a plausible guess and hands back something fluent. That is why the result so often reads as generic. I made a related argument in The Machine Is Doing It, and the AI enablement page sets out what to supply before the prompt: your context, your standards and what good output looks like.
A check before a briefing, a talk or a prompt
List the terms you are using. Mark the ones the listener may not share.
List what you are assuming has already been decided or agreed.
Write down the one thing the listener should be able to do or decide when you finish.
Afterwards, ask one person to say it back in their own words.
The fourth step is the one people skip, and it is the only one that tells you whether the first three worked.
What is one thing you explain regularly that you have never checked the other person actually understood?
Sources: No external sources. Written from Partha's own experience of explaining technical products.
