The Unlikely Explainer: Turn Any Technical Concept Into a Dialogue Between Two People Who'd Never Meet
Why this prompt matters
Technical explainers that don't stick get asked about again, not referenced again: teams that can't retain how a system actually works end up either overpromising to customers on capacity they don't understand, or routing every follow-up question straight back to a senior engineer — a pattern that commonly costs 20-30 minutes of that engineer's time per ticket an explanation delivered once, memorably, would have prevented. A scene people can replay in their head outlasts a diagram they skimmed once.
What we use it for
A developer relations lead at a 40-person SaaS company has 15 minutes at the start of a Monday all-hands to explain why engineering is migrating from a single load balancer to a multi-region setup with least-connections routing — before the sales and customer success teams field renewal-call questions about 'why did the site feel slow last Tuesday.' A slide with a round-robin-vs-least-connections diagram lost the room in under two minutes at the last attempt.
Prompt
Role: You are a science communicator who specializes in making technical systems unforgettable by dramatizing them as conversations between two characters who would never normally talk to each other. Context: I need to explain [TECHNICAL CONCEPT] to [WHO NEEDS TO UNDERSTAND THIS, AND WHY — e.g. "our sales team before a customer renewal call" or "a new hire with no backend experience"]. Here is what I actually need them to walk away understanding: [THE 2-3 THINGS THAT MATTER MOST, IN YOUR OWN WORDS]. Optional — if you already have two characters in mind, name them here: [CHARACTER 1] and [CHARACTER 2]. If you leave this blank, choose two characters whose own work has a genuine structural parallel to how [TECHNICAL CONCEPT] actually behaves — not just a surface-level resemblance. Task: Write a short dialogue (400-600 words) set in one concrete scene with real stakes, where one character explains [TECHNICAL CONCEPT] to the other using only analogies drawn from their own world. Every major mechanism in [TECHNICAL CONCEPT] must map to a specific, correct moment in the scene — not a vague gesture at similarity. The second character should push back, misunderstand, or ask the question a smart skeptical reader would actually ask, and get a real answer. Constraints: - Do not sacrifice technical accuracy for a better joke. If an analogy would mislead someone who later had to act on it, drop the analogy, not the accuracy. - Every analogy must survive this test: could someone who has never heard of [TECHNICAL CONCEPT] use it to correctly predict what happens in a new scenario? If not, replace it. - Do not use an analogy that itself requires background knowledge the reader in [WHO NEEDS TO UNDERSTAND THIS] doesn't have. - No narration-only exposition dumps — the explanation has to happen IN the back-and-forth, through disagreement or curiosity, not a monologue. Output format: 1. One line: scene heading (where, when, what's at stake) 2. The dialogue itself, with character names before each line 3. A closing line, clearly separated, labeled 'Plain explanation:' that states what [TECHNICAL CONCEPT] actually does in one or two sentences with no metaphor — so the reader can check the dialogue against ground truth.
Result
Scene: The host stand at a fully booked restaurant, 7:40 PM on a Friday. One of the three reservation podiums just lost its tablet connection.
Dana: I've got forty walk-ins stacking up and only two podiums working. I'm sending everyone to whichever line looks shortest, but the short line keeps getting the six-tops and backing up anyway.
Marcus: That's your bug right there. You're routing by line length, not by how long each table actually takes to turn. Towers don't clear planes by "whichever runway looks emptier" — we clear by who's actually ready to land fastest, which depends on what's already queued behind them.
Dana: So I should send people to whoever's fastest, not whoever's shortest?
Marcus: Exactly — "least connections," not round robin. Send the next party to whichever podium currently has the fewest tables still being worked, not whichever has the fewest people standing in front of it. A line of two four-tops that just sat down clears faster than a line of one six-top mid-appetizer.
Dana: And if a podium tablet dies completely?
Marcus: Then it stops getting new parties entirely until it's back — a dead runway doesn't get new landing clearances just because it's "its turn." You don't queue anyone behind a failure.
Dana: So three podiums, same host stand, but I stop treating them as interchangeable and start tracking actual load.
Marcus: And you recheck constantly. Towers reassess every few seconds, not once per shift.
Plain explanation: A load balancer with a least-connections algorithm sends each new request to whichever backend server currently has the fewest active connections — not simply the next one in rotation (round robin). It continuously tracks server load in real time and stops routing to any server that fails a health check, so traffic shifts automatically toward whichever servers can actually handle more work right now.
"Explain it to me like I'm five" produces analogies that are fun and wrong. The analogy lands, the listener nods, and then they go repeat something that doesn't actually hold up the first time a real edge case shows up. The problem isn't the use of analogy — it's that nothing forces the analogy to be checked against the thing it's standing in for.
This prompt fixes that by making the explanation happen inside a dialogue instead of a monologue. A monologue lets an explainer glide past the part that doesn't quite work. A second character who pushes back, asks the obvious skeptical question, or genuinely misunderstands forces the explanation to hold up under a follow-up — which is exactly what happens when the same explanation gets used in a real meeting.
The constraint that does the real work is the prediction test: an analogy only counts if someone who's never heard of the real concept could use it to correctly guess what happens in a new scenario. That rules out analogies that are only cosmetically similar — a shared vocabulary word, a vague shape — and forces a structural match between the fictional world and the technical one. It's also why the prompt insists on picking characters whose own work runs on a parallel logic, rather than characters who are just charming.
The closing "Plain explanation" line exists so nothing is lost in translation. The dialogue does the memorable work; the plain-language line underneath is what a reader checks the dialogue against, and what they'd actually say out loud if someone asked them to drop the story and just state the fact.
Use case: a developer relations lead with fifteen minutes at a Monday all-hands to explain a load balancer migration before sales and customer success start fielding renewal-call questions about a slow Tuesday — a diagram of round-robin versus least-connections routing lost the room in under two minutes the last time it was tried.
Why it matters: explanations that don't stick get asked about again instead of referenced again. Teams that can't retain how a system works either overpromise to customers on capacity they don't understand, or route every follow-up straight back to a senior engineer — commonly 20 to 30 minutes of that engineer's time per ticket an explanation delivered once, memorably, would have prevented.
This works best for onboarding, cross-functional briefings, and any moment where a concept has to survive being retold by someone who wasn't in the room when it was first explained. It's the wrong tool when precision matters more than memorability — contract language, compliance thresholds, anything where a reader might act on the metaphor instead of the fact underneath it.