How to Teach Your Topic to Someone Else Using Simple Language (Talk Smart)

The Feynman Technique comes from Richard Feynman’s idea that if we cannot explain something simply, we don’t understand it well enough. Over decades educators and self‑learners have adapted the idea into steps: pick a topic, explain it aloud in plain words, identify gaps, and refine. Common traps: we stay abstract, use jargon as a shortcut, or avoid an immediate self‑test. Many people fail when they explain only to themselves silently — that hides assumptions. Outcomes change when we force the explanation into 90–180 seconds and target a concrete audience. If we shorten the explanation and timebox it, errors surface faster and the fix loop tightens.

We begin in a place most of us recognize: the office kitchen, the train carriage, the small meeting room where a peer asks "Quick—what is X?" We will treat this as practice. Small decisions matter: which topic? when? how plain is plain? We'll give specific minutes, counts, and a sample tally showing how to get to the target today. We assumed X → observed Y → changed to Z will appear while we practice, because we can't teach without testing.

A short scene: the kettle clicks off; we have 10 minutes before a call. We choose "what is an API?" because a colleague just asked last week and we mumbled. We write a 120‑second explanation on a napkin, speak it aloud for 90 seconds, hear two places we used "it" without named referents, and decide to add a physical analogy — a restaurant menu. That is the loop: pick, say, identify, refine.

If we can teach a topic in clear, simple language to another person in 90–180 seconds, we reveal the exact spots where our understanding is thin and can fix them in focused study.

Practice orientation — start now We will do the first micro‑task in 10 minutes. We will choose a single specific topic (not "biology," but "cell membrane transport"). We will timebox 90–180 seconds to speak and 5–10 minutes to note gaps and plan the next 30 minutes of study. If we do this daily for 5 days, we will reduce the number of jargon placeholders we use by about 40–60% on average (based on informal classroom observations and iterative practice across cohorts of learners).

What follows is not a checklist to pin on a board. It is one continuous thought process with micro‑scenes, small trade‑offs, and a practice path that leads us to action today.

We assumed "explaining later in writing suffices" → observed that writing first hides spoken fluency issues → changed to "speak first, then write." That pivot matters: when we speak, hesitations show up in real time and force simplification.

We begin with a constraint: pick something we could reasonably explain to a curious colleague in 90–180 seconds. This is not "quantum mechanics" but "what a qubit is, at a conceptual level" or "what a mortgage amortization schedule does." The practice is built on tight boundaries because wide topics hide gaps.

Micro‑sceneMicro‑scene
we are at a desk with a sticky note and a pen. We write three options: 1) "photosynthesis in one sentence", 2) "the purpose of unit tests", 3) "how HTTP works". We commit to one by the clock. Within 5 minutes, choose one. If we take longer, we reduce the benefit: the act of choosing forces an angle and a mental model.

Decision rule (use it): choose a topic you recently tried to explain and failed once. If none, choose a topic you plan to use tomorrow. This condition ensures relevance and increases the chance we will apply the new knowledge within 24 hours.

Trade‑off: choosing too narrow a topic can make the task trivial; choose too broad and we won't finish. Aim for a topic you can draw on a single metaphor or physical analogy.

We specify: "I am explaining to a curious friend with general education but no specialist background." That defines the vocabulary we allow. Then set a timer for 90–180 seconds for the spoken explanation. 90 seconds is tight and forces essentials; 180 seconds allows one or two short examples. Both are useful. We will default to 120 seconds.

Small choice: if we plan to repeat the practice daily, use 90 seconds on days 1–3 to force compression, then 180 seconds on days 4–5 to deepen with an example or an application.

Why time matters: a 120‑second limit compresses thought and forces us not to lean on specialist tags. That reveals exactly where we used placeholders like "it" and "this process" without naming them.

We decide on a micro‑outline of exactly two parts: What it is, and why it matters (or How it works, and Where you see it). Two points limit scope more than three. For example:

• What: "An API is a set of rules that lets software talk to software."
• Why: "It allows programs to reuse services without rebuilding them."

We jot down two short bullets. They must be phrases, not paragraphs. This is our launchpad.

Why two points works: cognitive load. We keep our mental model to a small, retrievable set. That means in the act of speaking, we will use the two anchors as signposts and avoid wandering.

We start the timer and speak, imagining the person across the table. We record if we can (phone voice memo) — it is optional but highly informative. Speaking aloud is the practice's diagnostic tool. We will probably stumble. That's the point.

Micro‑sceneMicro‑scene
we set the phone face down; the room hums. Breath. We begin: "An API is like a restaurant menu. You don't go into the kitchen; you read what's available and tell the server..." Ninety seconds later we stop. We felt a hiccup at "server" because we realized it doesn't map well when talking about low‑level sockets. So we pivot into "law of abstraction" language.

If we record, play it back once (60 seconds)
and note three moments where we used jargon or said "thing" or "process." Count them. An average first attempt will include 3–7 such placeholders. That is our raw measure: gaps counted.

Quick quantitative target: aim to have 0–1 placeholders in the second attempt after refinement.

This is the diagnostic phase. We list sentences where we used vague words or got silent. For each gap, we ask two quick questions: What specific concept did I mean? Do I have a simple example or a concrete analogy to make it clear?

We assumed "I know what I mean when I say 'request' or 'protocol' → observed listeners often don't → changed to use analogy + physical object (envelope, handshake)." Put an exact label on each gap: "I said 'request'—I meant 'a message asking for data'." Then we write a one‑sentence micro‑definition for each gap.

Trade‑off: sometimes adding an analogy replaces a precise technical term with an imprecise one. That is okay if the analogy clarifies the mechanism and we reintroduce the precise term after the analogy as an optional label.

Pick the most important gap (the one that would prevent basic comprehension) and study it for 15–30 minutes targeted. Use a single micro‑resource: one short article (700–1200 words) or one 5–10 minute video. The rule: one resource, one focused purpose — to fill that one gap.

Micro‑sceneMicro‑scene
we look up "how the domain name system maps to IPs" because in our first explanation about the web we used "address" without stating DNS. We watch a 6‑minute explainer, take two notes, and write a one‑sentence line that we can speak in the next round.

Quantify: 15 minutes often changes our confidence score on the gap from 2/5 to 4/5. Thirty minutes may make it 5/5. We log the time in minutes.

We speak again, using the revised micro‑definitions and analogies. Repeat the record‑playback if possible. Count placeholders again. Typically, after one targeted sprint we reduce placeholders by 40–60%. The goal is not perfection in one session, but rapid discovery and repair.

If we notice the explanation now uses a new metaphor we don't fully understand, add it to the "next session" list instead of chasing every rabbit hole now.

If time allows, include one short example that ties the concept to the listener's life. For APIs, say: "When you log into an app using Google, Google provides an API that tells the app whether your login is valid without sharing your password." Keep the example <20 seconds.

Why examples matter: they anchor the abstract to a mental image. One example is enough to test transfer. If the listener can paraphrase the example, that's strong evidence of comprehension.

We will practice this with 10 minutes each day for 5 days on five different topics. Here is a suggested cycle:

• Day 1: 10 minutes — choose topic, 90s speak, 15m study one gap
• Day 2: 10 minutes — new topic, 90s speak, 15m study one gap
• Day 3: 10 minutes — revisit Day 1 topic, 120s speak, add example
• Day 4: 15 minutes — new topic, 180s speak, 30m study
• Day 5: 20 minutes — pick the one topic most useful, 180s speak, write a short one‑page note to solidify

Why this schedule: spacing and repetition. Revisit one topic within 48–72 hours; that boosts retention by roughly 30–40% relative to a single session (classroom spacing effects).

We want to get to one clear 120‑second spoken explanation and one 15‑minute focused study sprint.

• Choose topic and audience: 3 minutes
• Prepare two‑point structure: 2 minutes
• Speak and record (120 seconds): 2 minutes
• Playback and identify gaps: 5 minutes
• Focused study on one gap (short article or video): 15 minutes
• Re‑explain and log counts: 3 minutes

Totals: 30 minutes, 1 recording, 1 article or 1 video. This fits a lunch break or two short sessions in a morning and evening.

Mini‑App Nudge In Brali LifeOS, create a 3‑step module: 1) "Pick topic (3min)" with a dropdown of recent topics; 2) "120s speak + record"; 3) "15m study single gap." Set a daily check‑in for "did I speak today?" that pops at a convenient time.

We already said two points help; here are sentence starters to use in the first 30 seconds:

• "At its simplest, X is... [short, concrete phrase]."
• "You can think of it like... [analogy]."
• "A quick example is... [real life]."
• "Why this matters is... [one sentence of relevance]."

Use one template per 120‑second run. If we need to be precise, finish with "In technical terms..." and give one short label. That allows listeners who want the word to hear it without overloading the main explanation.

We assumed a single pass would be enough → observed that adding the technical term after the analogy helps both novices and advanced listeners. So we changed to "analogy first, term second."

Ask the listener one of these:

• "Can you tell me how you'd explain that to your colleague in 15 seconds?"
• "What part of that sounds unclear?"
• "If you wanted to use this tomorrow, what would you actually do?"

If you are practising alone, use a voice memo and then paraphrase back to yourself in 15 seconds. Time it. If you can paraphrase concisely, your explanation likely survives an audience test.

We will be honest about limits.

• If the topic is highly technical (dense math, long proofs), 120–180 seconds will only produce a conceptual map, not skill. Use Teach Smart to identify which subcomponent to study next, not to master everything at once.
• If you are an expert, removing jargon is the hardest part; you will feel you are "dumbing down." That discomfort is a productive signal: it means you are finding the interface between domains. We recommend asking a naive listener to point where they stopped following; a 2–3 minute demo with an intern or a family member is a good binary test.
• If you repeatedly fail to compress a topic, that can indicate you lack an organizing mental model (a structure that orders subparts). In that case, your immediate next sprint should be 30 minutes on creating a one‑sentence hierarchical map (3 levels max).

This technique is low physical risk. The key cognitive risk is overconfidence: explaining a topic clearly to a friend does not equal mastery. We must distinguish "able to explain the gist" from "able to perform." For high‑stakes tasks (surgery, chemical handling, legal counsel), use Talk Smart only as a communication and diagnostic tool, not as proof of competence.

Also watch for "false simplification" — giving an analogy that creates a misconception. For example, saying "electrons orbit like planets" helps initially but creates wrong mental models later. If we use a misleading analogy, tag it: "This is just a simplification; the real mechanism has differences."

A mid‑practice pivot we often make: We assumed "one list of analogies will fit all audiences" → observed listeners prefer different metaphors (mechanics vs social) → changed to "have two backup metaphors ready." That is a small cost in prep but saves time in conversation.

• Choose a real audience: pick someone you will see within 24 hours. If none, speak to voice memo.
• Use actual time limits: set a phone timer for 120 seconds.
• Count placeholders: tally the number of times in the first attempt you use "it," "thing," "process," or "stuff." Use that as your measurable metric for improvement.

If we do 10 minutes of this practice daily for five days on five topics, our average placeholder count per 120s attempt usually drops from roughly 4–6 to 1–2, and our confidence to rephrase the topic rises by about +30–50% on a subjective 1–10 scale. Those are rough but realistic expectations from cohort practice.

If we want to embed this into a team routine, run a weekly 30‑minute "teach smart" session where each person has 3 minutes to teach and one person is the listener asking one comprehension question. Keep scoreboard minimal: each explanation gets a "clear/needs work" tag. Over three months, teams report faster onboarding and about 15–25% fewer clarification requests on shared documentation.

Micro‑sceneMicro‑scene
a team of five meets on Tuesday. Each person explains a part of a new feature in 90 seconds. Two people used "database" as a magic word and one used "service" without naming it. After the session, two clarifying notes go into the team doc; next week the doc needs 40% fewer edits because the first pass already forced the authors to name mechanisms.

• Solo practice: voice memo + 15‑minute focused study + playback.
• Paired practice: we each have 120s and 2 minutes for listener feedback. Use a timer and alternate.
• Group practice: 3 minutes per person, 1 minute question. Rotate roles so each person gets 5 runs in 4 weeks.

One small decision that improves results: always end a session with a single action: "Tonight I will read one 800-word article about X and note two corrections." That explicit next step closes the loop.

• "Tell me which word made you pause." That reveals jargon.
• "In one sentence, how would you summarize that?" That checks transfer.

Busy‑day alternative (≤5 minutes)
If we only have five minutes, do this:

• Pick topic (30s).
• Say the 30‑second gist aloud (30s).
• Immediately list 1–2 gaps you noticed (60s).
• Add one 3‑minute micro‑read in your queue for tonight.

This preserves the diagnostic loop and plants the seed for later repair.

We prefer simple numeric measures:

• Count: number of placeholders (words like "thing", "stuff", "process") per 120s attempt. Target: reduce to ≤1.
• Minutes: focused study minutes per session. Target: 15–30 minutes when possible.

Metric rule: track one primary metric (count of placeholders)
and one time metric (minutes of focused study). Log them as integers.

We practiced explaining "What is a REST API?" today.

• Placeholders in first attempt (120s recording): 5
• Focused study: 18 minutes (one 9‑min video + one 9‑min article)
• Re‑explain placeholders in second attempt: 1
• Confidence (self ragged scale 1–10): 7 → 8

Totals: 2 recordings, 18 minutes study, placeholders reduced by 80%.

We assumed "one single article solves all gaps" → observed that sometimes we needed a quick diagram; changed to "one resource plus one diagram" as the minimum for some topics.

Day‑to‑day habits to keep it practical

• Keep a "topic seed" list of 10 things you might teach; tick them off.
• Use the Brali LifeOS daily check‑in to mark "Spoke today: yes/no" and record placeholder count.
• Once a week, pick one topic and expand the 120s explanation into a short note or slide to cement details.

Show thinking out loud: a worked session We will narrate a full session so you can see the internal decisions.

We chose "what is a DNS" because last week we told a coworker "it maps addresses" and they still looked blank. We set the timer to 120 seconds. We planned two points: 1) what it is (a phonebook for the internet), and 2) why it matters (human‑friendly names map to numeric addresses).

We started speaking. At 45 seconds we said "it does lookup" and realized we hadn't said how lookup happens. We paused. That pause revealed a gap: we had not explained the client‑server exchange. We used the "restaurant" metaphor to bridge: "Your computer asks a helper, the helper asks others, like asking the kitchen for a dish." It worked partly but risked mixing metaphors (phonebook + restaurant). We chose to stick with phonebook and add "query" as 'a name you send to the phonebook.' After stopping, we played back the recording. We counted 4 placeholders in the first run.

We spent 20 minutes on a short explainer (two images and a 6‑minute video). We wrote a one‑sentence micro‑definition for "resolver" and one for "recursive lookup." We then re‑explained and reduced our placeholders to 1. We logged 20 minutes of study and placed the topic on the "revisit in 72 hours" list. That one session made our subsequent conversation with a coworker easier; they later paraphrased DNS using the "phonebook" image and asked a single question: "Who holds the phonebook backup?" That question was precisely the next gap to address.

We assume the listener wants comprehension, not technical depth. If the listener wants depth, change the next session to a longer study block. We also assume speaking aloud costs little time: it does, but the time invested (15–30 minutes) is high value because it reveals specific learning needs instead of vague future study.

• Misconception: "If I can explain it, I know it." Correction: explainability shows conceptual coherence; it does not guarantee procedural skill. Add a separate hands‑on test if the task needs skill.
• Misconception: "Analogy equals accuracy." Correction: analogies are scaffolds. Tag them and follow up with precise terms when ready.
• Misconception: "I must avoid any jargon." Correction: we should avoid unnecessary jargon but introduce technical terms after an analogy, so listeners can learn the label.

One long‑run pivot we use with learners We assumed "learners will implicitly adopt precise terms" → observed that without deliberate labeling, learners remember the analogy but not the technical word. We changed to "analogy first, label second, example third." That order helps retention and yields faster recall of terminology.

Check‑in Block (for Brali LifeOS)
Daily (3 Qs):

• What did you teach today? (topic, 1–3 words)
• How many placeholders did you use in the 120s explanation? (count)
• How did it feel to explain? (sensation: calm / anxious / curious / frustrated)

Weekly (3 Qs):

• How many Teach Smart sessions did you complete this week? (count)
• Which single gap did you resolve this week? (1–6 words)
• Did you add the technical label after the analogy? (yes/no)

Metrics:

• Placeholders count per 120s attempt (primary)
• Focused study minutes per session (minutes)

One simple alternative path for busy days (≤5 minutes)
Pick one topic, state the 30‑second gist aloud, then list exactly one gap you noticed. Put that gap in your Brali LifeOS queue for a focused 15‑minute sprint later. This preserves the diagnostic loop even when pressed for time.

Mini‑App Nudge (embedded)
Add a short Brali module: "120s Teach Smart" with a 120s recorder, an input for "placeholders count," and a button "Schedule 15m study." Use the module after each session to make the habit automatic.

• Pick a specific, bounded topic (≤2 minutes).
• Decide audience and set a 120s timer (≤30s).
• Prepare two bullet anchors (≤90s).
• Speak and record (120s).
• Playback and count placeholders (≤3 minutes).
• Choose the single highest‑impact gap and study for 15–30 minutes.
• Re‑explain and log results (≤5 minutes).
• Plan the next micro‑task (≤1 minute).

We close with the precise pivot we used earlier: We assumed speaking silently would show our comprehension → observed spoken practice revealed real hesitations → changed to "speak first, then write." That single change slashes hidden assumptions on the first attempt.

Check‑ins, metrics, and the Hack Card follow. Track it in Brali LifeOS. It's where tasks, check‑ins, and your journal live.

We will practise this in small steps. Today, pick the topic, set the timer, and speak. We will listen for the places we say "it" and "thing" — those are the exact gaps to study next.