[[TITLE]]

You’re in a meeting, trying to explain a simple idea. You believe it’s crystal clear. Heads nod. Then, a week later, the thing you explained gets built… completely differently from what you meant. You feel baffled: “But I said it. It was obvious!” The truth: it was obvious only inside your head.

That gap has a name. The Curse of Knowledge is when you forget what it’s like to be a beginner and accidentally assume others know what you know.

We’re the MetalHatsCats team. We’re building a Cognitive Biases app because we’re tired of watching good ideas die between one brain and another. This one—forgetting beginner eyes—breaks communication, training, product design, support, docs, and trust. Let’s fix it.

What Is the Curse of Knowledge—and Why It Matters

Imagine tapping your finger on a table to “play” a song. You hear the melody in your head. You assume others can too. They hear random knocks. In a famous experiment, “tappers” expected listeners to guess the song around 50% of the time; listeners got it right 2.5% of the time (Newton, 1990). The tapper’s knowledge biased their estimate. Once you know a thing, you can’t easily imagine not knowing it. That’s the Curse of Knowledge.

It matters because it quietly sabotages:

• Communication: We skip the missing steps and declare victory.
• Teaching: We flood beginners with abstractions they can’t yet hold.
• Product design: We name buttons after internal systems, not user goals.
• Leadership: We set goals with blurry definitions and assume shared context.
• Hiring and onboarding: We hand a map to people who don’t speak our mapping language.

It also wears people down. Newcomers feel dumb when they’re not; experts feel ignored when they’re not. The curse creates distance and resentment. It’s no one’s fault and everyone’s problem.

The good news: once you know the curse is lurking, you can build simple habits that break it. We’ll show you how.

Examples: Stories from the Trench Floor

Abstract advice smells like air. Concrete stories smell like coffee and panic. Here are moments we’ve seen or lived where the curse sneaked in and stole time, money, or morale.

The Senior Engineer and the Invisible Pointer

Mina, a senior engineer, explained pointers to a new hire, Jess:

“Think of a pointer as a reference to memory. You increment it to move along an array. It’s O(1).”

Jess nodded, face composed, mind on fire. “Reference to what memory? How big is an increment? Why is O(1) good? What is an array?” Jess didn’t ask. Asking felt like confessing.

Result: Jess shipped a function that worked “in the happy path” and corrupted memory on edge cases. Bug bash week cost 60 hours. The team wrote tests. Mina learned to draw boxes and arrows. She started with: “Imagine a row of mailboxes. Each box holds a value. A pointer is the mailbox number. Increment by one to check the next box.” No jargon. Visuals first, terms after. Shipping improved.

The curse didn’t make Mina unkind. It made her brain forget how it once struggled.

The Support Page that Solved the Wrong Problem

A small fintech wrote a brilliant help article: “Reconcile Outstanding Journal Entries.” It answered “how to audit ledger items.” Their customers searched “why is my balance wrong” and never found it. The support page assumed a mental model (“journal entries”) many customers didn’t have.

They renamed it: “Why your balance looks wrong (and how to fix it).” First paragraph: “Your bank balance and app balance can differ for three common reasons. We’ll show you how to spot each one.” They added three screenshots and one checklist. Support tickets dropped 28% in a month.

What changed? They wrote to the beginner’s world—search terms, context, and pain—not the expert’s world.

The Onboarding That Felt Like a Test

A manager onboarded new teammates with a “concise” Notion page full of internal acronyms: “Please update CRM with TRI for MQL->SQL movement. Weekly EBR covers P1 SEV tickets. See SOP.”

The new folks nodded. Then slacked each other: “What is TRI?” “What’s SEV vs. P?” They spent six hours building an unofficial glossary. “Concise” was a lie; it was dense. The curse had compressed context into opaque codes.

The fix: The manager added a one-page “Rosetta Stone” that defined every acronym with examples, and linked each to a “Why it exists” paragraph. The team stopped feeling like they were trespassing.

The CEO’s All-Hands That Backfired

The CEO shared a new strategy: “We’re moving upmarket.” To her, that meant longer sales cycles, enterprise security, procurement processes, and a don’t-break-stuff roadmap. To engineering, it meant “we’ll build the ‘pro’ features we actually want.” To support, it meant “we’re going to drown in tickets.” To marketing, it meant “change ICP and content now.” Everyone acted on their own translation. Chaos.

In week two, the CEO realized and hosted a “strategy unpacking” session. She defined “upmarket” with numbers: “ACV > $50k, 10–100 seats, procurement, SSO, uptime SLA 99.99%.” She walked through one real prospect’s RFP and redlined the gaps between what they sold and what they had. Misalignment shrank. People calmed down. The curse had been silently multiplying meetings until someone drew the same map.

The Designer and the Perfect Dead End

A designer crafted a beautiful mobile onboarding: three screens, a subtle skip link, 8pt font “Learn more,” and a tutorial that assumed the user had already used a competitor app. In tests, five of eight users got stuck and abandoned.

When the designer watched those recordings with a PM and a support rep, they created an absurd but clarifying constraint: “Design this for your mom after a long day at work.” They cut onboarding to one screen with two choices and a small demo that matched a real task. Completion rates jumped by half. The curse had made the first design elegant to insiders and brittle to everyone else.

The Teacher Who Thought She Was Being Clear

In a middle school class, a teacher introduced fractions: “A fraction is a rational number representing a ratio.” She’d said the right thing by the book. Blank faces. She shifted: “Imagine a pizza cut into eight slices. Three slices is 3 out of 8. 3/8.” Heads tilted. “Now draw your own pizza and slice it.” Pencils moved. The class got it.

Experts move fast. They collapse steps into labels. Beginners learn slow. They need the steps back.

The Developer Documentation That Made Users Feel Small

A library README stated: “Supports HMR, tree-shaking, and custom loaders. See the examples.” A user trying to do “Upload an image and get back a URL” searched fruitlessly. A developer on the team watched a user’s screen for 30 minutes. They wrote one new example with that exact use case and a 15-line code snippet. Stars and adoption jumped. The curse had assumed users cared about the internals. They cared about the first success.

How to Recognize and Avoid the Curse of Knowledge

You can’t remove the curse, but you can outsmart it. It sneaks in at predictable moments: when you’re teaching, writing, presenting, or designing. Here’s how to see it and fix it.

Warning Signs You’re Cursed Right Now

• You’re surprised people “don’t get it,” and your fix is repeating yourself louder.
• You say “just,” “simply,” or “obviously” more than you think.
• You jump to exceptions, edge cases, or internals before anyone asks.
• People nod but don’t do the thing you thought they would.
• You feel annoyed at questions you’ve answered “already.”
• Your docs are short but spawn long clarification threads.
• You write jargon or acronyms without definitions.
• Feedback includes “what does X mean?” or “where do I start?”

When you notice these, stop. Not because you’re wrong, but because your map has more detail than their map. Time to redraw the route.

Tactics That Work When Stakes Are Real

Start at the edge of the other person’s knowledge, not your own. Then take one step.

• Ask for their current picture. “Before I jump in, what’s your current understanding of webhooks?” You’ll learn exactly where to begin and what to skip.
• Use concrete tasks, not labels. “Let’s get your first event logged” beats “Let’s discuss our analytics SDK.”
• Show before you name. Demo the thing. Then give it a label. People remember experiences over abstractions.
• Use “for example” like a comma. When a sentence sounds smart, add an example that sounds dumb. Dumb is good. It sticks.
• Remove “simply.” Replace with the missing steps. If you can’t, you don’t have the steps.
• Use the “next-click test.” Give someone the screen and ask, “Where would you click next, and why?” If they hesitate, your design assumes too much.
• Co-create definitions. “When we say ‘qualified lead,’ we mean X and Y.” Write it down. Pin it.
• Write one beginner path. If your doc starts with “Advanced,” rewrite. Add a “First win in 5 minutes” section.
• Teach with stories. “We had a customer named Maya who…” shows the shape of a problem in 3D.
• Build a glossary you update as you speak. Throw unknown words into a shared list and define them at the end.
• End with a check-for-understanding. “Can you explain this back to me in your own words?” Ask nicely. Listen.
• Record and rewind. Watch a new person use your thing. Better: shut up while they do. The cringe you feel is the curse breaking.

You don’t need all of these. Pick three that match your context and practice them until they’re boring.

Micro-Patterns for Common Situations

• Explaining a concept to a colleague: Start with a picture. “This is like a library card pointing to the book on a shelf.” Then show a tiny working example. Then name it: “That pointer points to memory.”
• Writing docs: Begin with: “Who is this for? What’s their first win? What mistake will they make first?” Write those answers. Then add the advanced parts after.
• Shipping an internal memo: Define big nouns once. “Platform: the services serving both A and B.” “Migration: moving C from X to Y with no downtime.” Put those at the top.
• Reviewing a design: Swap in plain-language labels. “Upload profile photo” instead of “Asset ingestion.” If it feels too simple, you’re closer.
• Teaching a workshop: Use the 20/80 rule. 20% concept, 80% doing. After each concept, ship a tiny success. End with a cheat sheet they can use tomorrow.

The Checklist: Quick Self-Audit Before You Explain

• Have I defined the outcome in plain language?
• Do I know the other person’s starting point?
• Did I strip out jargon or define it in one line?
• Do I have one concrete example? Screenshot, code, or sketch?
• Can I describe the first step and the next click?
• Do I have a five-minute win baked in?
• Did I invite questions with real time to answer?
• Did I ask them to explain it back to me?
• Did I watch one new person try it?
• Did I remove “just,” “obviously,” and “simply”?

Tape this near your monitor. We did.

What We’ve Found Works as a Team

We built two rituals into our week:

• The “Beginner Hour.” One person demos something to a teammate who’s never seen it. The listener narrates their thoughts. No fixing allowed. We take notes on every assumption. We ship one doc or UI change from what we learn.
• The “Glossary Pass.” At the end of standup on Fridays, we pick a term we keep saying. We write a single-sentence definition and one example. We pin it. New people feel the ground under their feet.

We also use our own Cognitive Biases app to sprinkle gentle nudges in Slack. If a post has three or more undefined acronyms or the words “simply/obviously,” it flags: “Are we sure the path is obvious to a newcomer?” Annoying? A little. Effective? Very.

Related or Confusable Ideas

Biases come in families. The Curse of Knowledge hangs out with a few relatives. Knowing who’s who clarifies which tool to use.

• Illusion of transparency: You think your internal state is visible to others. You believe your sarcasm reads clearly, your anxiety shows, or your half-explained plan makes sense because you feel it strongly. Related: you assume others hear the song you hear (Gilovich, Savitsky, & Medvec, 1998).
• Hindsight bias: After something happens, it feels like it was inevitable. “We knew that bug would bite us.” Not the same as the curse, but it reinforces it—once you know, it’s hard to remember not knowing (Fischhoff, 1975).
• Expert blind spot: Teachers or experts fail to notice the steps novices need. They focus on high-level schemas. Basically the curse in classrooms (Nathan & Koedinger, 2000).
• Jargon trap: Using insider terms as if they’re universal. Jargon isn’t evil; unmarked jargon is. Mark it or ditch it.
• Dunning–Kruger effect: Beginners overestimate their ability; experts sometimes underestimate how hard it is for others. The curse shows up in the expert side: they assume something is easy because it is for them (Kruger & Dunning, 1999).
• Planning fallacy: You underestimate how long it will take, partly because you forget the learning curve for others. The curse shrinks that curve in your mind (Kahneman & Tversky, 1979).
• Complexity bias: We prefer complicated explanations over simple ones. Under the curse, simple feels wrong to experts, even if it’s perfect for beginners.

When in doubt, ask: “Is this about forgetting the beginner’s mind?” Then you’re dealing with the curse.

How to Recognize You’re the Beginner (And Ask Better)

The curse cuts both ways. Sometimes you’re the one nodding while lost. Here’s how to make that easier.

• Admit your map. “I’m missing steps between B and C. Can you show me one example?”
• Ask “What does [term] mean here?” Not “What does it mean?” Context matters.
• Repeat back what you heard. “So, the pointer is the mailbox number, not the value. Right?” Quick confirms save hours.
• Request the next click. “If I’m on this screen, where should I click next?”
• Ask for a five-minute win. “What’s the smallest thing I can do to know it’s working?”
• Time-box and write. “Can we take five to write the steps? I’ll try them while we’re on the call.”

You’re not being annoying. You’re building the bridge while walking it. People respect that.

How We Bake Beginner Eyes into Products

We’ve learned to design for first wins. A few product habits:

• Every feature or doc must have a “first success in five minutes” path.
• We watch three cold users try to do one basic task before release. We fix the first stuck point, not the fourth.
• We label buttons by user goal, not system function. “Send test email” beats “Dispatch event.”
• We prefer examples to config screens. Example first, config later.
• We name things the way our users talk in support tickets, not how our code talks in repos.

If you’re a PM or a founder, set these as rules, not preferences.

Two Small Exercises That Pay Off Big

Try these with your team.

The Rubber Duck and the Forgotten Step

Grab a rubber duck or a mug. Explain to it how to make a peanut butter sandwich. Say each step aloud. Every time you assume a step (like “open the jar”), stop and write it. You’ll discover missing verbs: open, spread, align, cut. Do the same with your onboarding. It’s humbling. It’s also clarifying.

The 3-Reads Test for Writing

Before you publish a doc, get three people:

• One expert: checks for accuracy.
• One peer: checks for clarity.
• One outsider: checks for legibility.

Ask each “Where did you stumble?” Fix only those places. Ship. This turns vague “make it better” feedback into surgical edits.

A Few Short, Useful Scripts

Use them verbatim if you want.

• Before a meeting: “I’m going to explain X. If I skip a step or use a word you don’t know, please stop me. I’d rather repeat than confuse.”
• When you catch yourself rushing: “Let me slow down and show an example before naming the concept.”
• When someone is lost: “My bad. I jumped ahead. Can you tell me where you are on this map?”
• When you don’t know a term: “I’m new to this; could you define [acronym] in one sentence for this project?”
• When a doc is unclear: “I tried steps 1–3 and got stuck at 4; here’s a screenshot. What should I click next?”
• When naming a feature: “How would a user describe this to their friend? Let’s use those words.”

These sound basic. That’s the point.

Why It’s Hard: A Quick Glance at the Brain

We don’t fight our brains; we work with them.

Once you build a mental model, your brain compresses steps. That’s how expertise works. You see patterns and skip the slow path. You also get worse at noticing what you’re skipping. That’s the curse. It’s efficient but blind.

Research backs pieces of this:

• People overestimate how well others understand their messages (Gilovich et al., 1998).
• Knowledge changes perception of difficulty; experts predict that novices will learn faster than they actually do (Camerer, Loewenstein, & Weber, 1989).
• Teachers with strong pattern knowledge can overlook beginner steps (Nathan & Koedinger, 2000).

We don’t need to memorize papers. We need rituals that offset the blind spot. Think seatbelt, not surgery.

FAQ: Real Questions, Short Answers

Q: How do I know if my explanation is too advanced? A: Test it on one true beginner. If they can’t get a five-minute win, it’s too advanced. Also scan for “just/simply/obviously” and undefined acronyms. Those are red flags.

Q: I don’t have time to teach slowly. What then? A: Teach small. Give a first win and a next step. Record a two-minute Loom doing the task. Slow once to go fast later. Reuse the recording a hundred times.

Q: How do I push back on jargon without sounding pedantic? A: Ask for context, not purity. “For this doc, can we define ‘tenant’ in one line at the top? It’ll save support time.” Tie it to outcomes, not style.

Q: My team thinks examples are “hand-holding.” How do I change that? A: Measure outcomes. Ship a doc with an example and track support tickets or task completion. When metrics improve, skepticism fades.

Q: What if the beginner is defensive or afraid to ask questions? A: Lower the stakes. Say, “Assume I’m missing something. Interrupt me.” Share your own confusion stories. Pair them with another new person to compare notes. Psychological safety unlocks honesty.

Q: How can I write better “first win” docs? A: Pick one tiny goal (“Send your first API request”). Show the shortest path with copy-pastable code and the expected output. Put advanced options in a separate section. Link to them, don’t mix them in.

Q: What about designing for mixed audiences? A: Layer your content. Start with “Basics (5 minutes).” Then “If you need X,” then “Advanced.” Clear signposts let experts jump and beginners climb.

Q: I keep repeating myself. How do I scale explanations? A: Turn the best explanation into a reusable asset: a one-pager, a short video, a demo script. Build a quick index so people can find it. Repetition turns into links.

Q: Does the curse apply to visuals, too? A: Yes. A dense diagram is just jargon with arrows. Start with a simple picture and add layers. Label in the user’s language first.

Q: How do I bring this up without blaming people? A: Blame the bias, not the person. “We’re all subject to the Curse of Knowledge. Let’s run a beginner check.” Make it a shared habit, not a critique.

The Recognize/Avoid Checklist

• Define the outcome in user words.
• Ask the other person’s starting point.
• Use one concrete example.
• Strip or define jargon and acronyms.
• Show the next click or first step.
• Bake in a five-minute win.
• Invite interruptions and questions.
• Ask for a teach-back in their words.
• Watch one beginner try it and note the first stuck point.
• Remove “just/simply/obviously.”

Keep it visible. Update it over time.

Wrap-Up: Remember the First Time

Think back to the last thing you learned that made you feel small. Maybe a new codebase, a medical portal, a legal form. Remember the heat in your face, the scrolling, the feeling of “I should know this.” You weren’t stupid. The map was missing.

The Curse of Knowledge isn’t malice. It’s memory loss. We forget the wobble of the first bike ride, the first pointer, the first sales call. We forget the fear. The fix isn’t to pretend we’re beginners again. It’s to act like guides who remember what the trail feels like in the rain.

So here’s our ask. This week, pick one place where you explain something—your docs, your onboarding, your next meeting. Use one idea from this article. Add an example. Define a term. Ask for a teach-back. Watch one real person try your thing. Then ship one improvement.

We built our Cognitive Biases app to remind teams, gently, that our brains are brilliant and biased. It nudges when our words get ahead of our audience. It won’t make you perfect. It will make you kinder and clearer. That’s enough to change your week.

From all of us at MetalHatsCats: keep the tap, but hum out loud. Let others hear the song.

References (short and selective)

• Camerer, C., Loewenstein, G., & Weber, M. (1989). The curse of knowledge in economic settings.
• Newton, E. (1990). The “tapper-listener” study on overestimating communication.
• Gilovich, T., Savitsky, K., & Medvec, V. (1998). The illusion of transparency.
• Fischhoff, B. (1975). Hindsight bias.
• Nathan, M., & Koedinger, K. (2000). Expert blind spot in teaching.
• Kruger, J., & Dunning, D. (1999). Unskilled and unaware of it.
• Kahneman, D., & Tversky, A. (1979). Planning fallacy and decision-making.

Quick Checklist: Use Tomorrow

• Start with the user’s goal in plain words.
• Show one example before naming concepts.
• Define acronyms at the top.
• Deliver a five-minute win.
• Ask for a teach-back.
• Watch one beginner use it; fix their first stuck point.