Knowing Too Much to Explain Clearly
In 1990, Elizabeth Newton conducted a memorable experiment at Stanford. She divided participants into "tappers" — who would tap out the rhythm of a well-known song on a table — and "listeners" — who would try to guess the song. The tappers predicted that listeners would guess correctly about 50% of the time. The actual success rate was 2.5%. The tappers couldn't understand why listeners were failing: the tune was so obvious to them, playing clearly in their heads, that they couldn't hear the meaningless sequence of taps the listeners were actually hearing.
This is the curse of knowledge: once you understand something, you cannot fully recreate the mental state of not understanding it. Your knowledge becomes a filter you cannot remove. You know the song; you cannot unknow it to hear only the taps.
The cognitive mechanism
The curse operates through the failure of perspective-taking under conditions of asymmetric expertise. When you know something thoroughly, your knowledge is chunked into high-level structures that are automatically accessed. You don't think about individual steps — you think about concepts that compress many steps. When you communicate with someone who hasn't formed those chunks, you're translating from compressed expert representations to uncompressed novice experience — a translation you're not doing, because you don't realize it's needed.
Baruch Fischhoff called a related phenomenon "hindsight bias": after learning the outcome of an event, people consistently overestimate how predictable that outcome was beforehand. Knowing the answer makes it feel obvious; and once it feels obvious, you can't reconstruct how non-obvious it was to you before you knew. The outcome knowledge corrupts your ability to retrieve your prior uncertainty.
Where the curse shows up
Expert teaching: The most common experts are often poor teachers of beginners. They've forgotten what it's like to not know the fundamentals, they skip steps that seem obvious, they use jargon they no longer recognize as jargon, and they frame explanations around structures that only make sense if you already have much of the knowledge they're trying to convey. The best teachers are not always the most expert — they are often people who can still access the novice's perspective.
Technical writing: Documentation written by engineers for engineers, then released to users who don't share that background, is the canonical manifestation. Instructions skip steps assumed to be obvious. Jargon is left undefined. Warnings are omitted for edge cases the writer never experiences.
Business strategy: Founders and executives who have lived with a product or strategy for years are often unable to communicate its value simply. They are cursed with knowledge of the details, the history, the alternatives considered — context that audiences don't have and don't need. The curse produces explanations that are exhaustive to the expert and unintelligible to the audience.
Design: The person who built a product knows how to use it. Their knowledge makes it invisible that the product has a learning curve — they've internalized all the steps. New users encounter the product without that internalized knowledge and find it confusing. Usability testing by definition recruits people without the curse; that's why the results consistently surprise development teams.
Countermeasures
The curse can be mitigated but not cured, because you can't unknow what you know.
Recruit the uncursed: The most reliable solution is to put uncursed users in front of your product, document, or explanation and observe what confuses them. Their confusion is real information about where your curse is blinding you. This is why user testing, editing by people outside your domain, and teaching novices are all valuable — not as nice-to-haves but as necessary corrections to systematic bias.
Reconstruct the novice path: Deliberately try to identify every step you've automated. What does someone need to know before they can understand what you're trying to explain? Work backward from the assumed knowledge to the baseline. This is hard and requires deliberate effort — the automation of expertise works against it.
Use concrete examples before abstractions: Experts think in abstractions; novices need concrete cases first. The curse causes experts to present the abstraction and trust that examples will follow from it. Novices need the examples to construct the abstraction. Reversing the pedagogical order — case first, principle second — is a reliable remedy in teaching and in writing.
Quick answers
What is Curse of Knowledge?
The curse of knowledge: once you understand something, it's hard to remember what it was like not to understand it — making you a worse teacher and communicator.
Where does this concept come from?
The concept originates with Colin Camerer, George Loewenstein & Martin Weber (1989); popularised by Chip Heath & Dan Heath, "Made to Stick" (2006).
