Teaching Something Badly Reveals What You Don't Actually Know
Imagine being asked to explain monsoon formation to someone with no background in meteorology at all — not summarise a textbook paragraph, actually explain it, start to finish, in your own words. It is a harder test than it sounds, even for someone who just answered a quiz question on the same topic correctly, because recognising a correct answer among options and producing a clear, unprompted explanation draw on genuinely different kinds of knowledge.
Physicist Richard Feynman was known for exactly this skill — explaining difficult material in plain language a non-specialist could follow — and the technique named after him turns that skill into a repeatable habit: treat explaining a concept simply as the real test of whether you understand it, rather than treating recognition or familiarity as evidence of understanding.
The Technique in Four Steps
Step one: choose a concept. Pick something specific enough to explain in a page or less — not "economics" but "why a price ceiling can cause a shortage," not "photosynthesis" but "why plants need both light and carbon dioxide for photosynthesis to occur." A concept that is too broad makes every subsequent step harder, because you cannot tell whether a gap in your explanation is a real gap in understanding or just a reasonable choice to leave something out.
Step two: explain it as if teaching a twelve-year-old. Write or say the explanation out loud, using plain language and no jargon — or, if a technical term is unavoidable, define it in plain language the moment you use it. This constraint is doing real work: jargon lets you gesture at understanding without demonstrating it, because a technical term can stand in for an explanation you have not actually worked out. Plain language removes that option.
Step three: find where you get stuck. Somewhere in the explanation, you will likely hit a point where you reach for a term you cannot actually define simply, skip a step because explaining it would be awkward, or realize your explanation only works for a special case rather than the general one. That moment — not the parts that flowed easily — is the valuable part of the exercise. It tells you precisely what to go back and relearn.
Step four: go back, relearn the specific gap, and simplify further. Return to your source material, but only for the specific point where you got stuck, not the whole topic again. Once you have a better handle on that piece, revise your explanation, and if possible, find or construct a simple analogy that captures the core idea — a good analogy is often a sign that you have compressed the concept down to something genuinely understood rather than memorized.
A Worked Example
Take compound interest. A surface-level explanation might be: "compound interest is interest on interest, so your money grows faster than with simple interest." That sentence is not wrong, but try explaining why it grows faster, in plain language, to someone with no background.
A fuller attempt: "Say you put money in an account that pays interest once a year. With simple interest, you earn the same amount of interest every year, because it's always calculated on your original amount. With compound interest, each year's interest gets added to your balance, so next year's interest is calculated on a slightly bigger number than before — you're earning interest on your earlier interest, not just your original deposit. Over many years, this difference compounds, which is why even a small difference in the interest rate or a few extra years of waiting can lead to a surprisingly large difference in the final amount."
Writing that version likely surfaces a specific sticking point: can you actually explain why a small rate difference leads to a surprisingly large difference over time, rather than just asserting that it does? That is the next gap to go back and relearn — perhaps by working through a concrete numeric example over ten or twenty years and watching the numbers diverge, which turns an abstract claim into something you have actually seen happen.
How This Differs From Re-Reading or Summarizing
Summarizing a passage in your own words is a genuinely useful step, closely related to active recall, but it is not quite the same exercise as the Feynman technique. A summary can still rely on the structure and vocabulary of the source material, restating its logic in slightly different words without necessarily exposing whether you could reconstruct that logic independently.
The Feynman technique's specific constraint — plain language, as if teaching someone with no background — is what forces a deeper test. It is much harder to disguise a gap in understanding behind simplified language than behind a close paraphrase of the original text, because plain language removes the vocabulary that let the gap hide in the first place.
When to Use It
The Feynman technique is demanding, and using it on every single fact you need to learn would be slow and unnecessary — plenty of material is straightforward enough that active recall or spaced review is sufficient. It earns its cost specifically for concepts that feel shaky despite having been studied, ideas you can state but struggle to apply to a new example, or material where you suspect you have memorized the shape of an explanation without actually understanding the reasoning behind it.
A practical signal for when to reach for it: if you get a practice question wrong and your honest reaction is "I knew that, I just mixed it up," the Feynman technique is a good way to check whether you actually knew it or only recognized it. Try to explain the underlying concept in plain language before looking at the explanation again, and see whether the explanation holds together on its own.
Frequently Asked Questions
Do I need to explain it to an actual person, or does writing it down work?
Writing or speaking it aloud alone works — the value comes from being forced to produce a clear, simple explanation, not specifically from having a listener. Explaining to a real person, especially someone who will ask genuine follow-up questions, adds an extra layer of pressure-testing, but it is not required for the core benefit.
How is this different from just teaching a topic to a study group?
Teaching a study group is a great real-world application of the same principle, and the questions peers ask can surface gaps you would not have found alone. The structured version described here is a way to get a similar benefit on your own, on a schedule you control, without needing to coordinate a group session every time you want to check your understanding of something.
What if I get stuck immediately and cannot explain anything?
That is useful information, not a failure of the method — it tells you the concept needs to be relearned from a more basic level than you assumed, rather than just polished. Go back to the source material, relearn the fundamentals, and try the explanation again once you have something more solid to work with.
A Second Worked Example
Take a concept from civics: why a written constitution typically separates powers between a legislature, an executive, and a judiciary. A shallow explanation might say "it prevents any one branch from having too much power" — true, but vague enough to hide whether you actually understand the mechanism.
A plain-language attempt forces more precision: "If the same group that makes the laws could also enforce them and judge disputes about them without anyone else checking their work, there would be nothing stopping them from making a law that benefits only themselves and then both enforcing and justifying it however they liked. Splitting these jobs between different groups means each one can act as a check on the others — the judiciary can rule a law unconstitutional, the executive can be limited by laws it did not write, and the legislature cannot directly punish anyone, only pass laws that others carry out." Writing that version out tends to surface a genuine sticking point — can you give a concrete real example of one branch actually checking another, rather than just restating the principle in the abstract? That is the next gap worth closing.
Common Mistakes When Using This Technique
The most common mistake is stopping at step two — writing a simple explanation — without actually completing step three, honestly hunting for the point where it breaks down. It is easy to write something that sounds simple and plain without it being rigorously tested, especially if you stop as soon as the explanation feels reasonably fluent rather than pushing it to cover edge cases or a concrete example.
A second mistake is treating any use of a technical term as an automatic failure, even when the term is genuinely necessary and has been properly defined in plain language first. The constraint is not "never use any specialized vocabulary" — it is "never use a term as a substitute for understanding what it means." Using a term you can define simply is fine; using one you cannot is the actual problem the technique is built to catch.
The ThinkZene Concepts Desk breaks down explanation-based learning methods and tests them against genuinely difficult, jargon-heavy material.