If your disagreement feels obvious to you, why does everyone keep walking out of the meeting thinking you’re on board?

A Stanford researcher once had people tap out familiar songs on a desk and predict how often listeners would name the tune. Tappers guessed about half the time. Listeners got three out of 120. That gap has a name: the illusion of transparency. It’s our tendency to overestimate how much other people can see what’s going on inside us, like our nerves, our disagreement, our intentions, and our tone.

Thomas Gilovich, Kenneth Savitsky, and Victoria Husted Medvec put this bias on the map in 1998, building on earlier work by Dale Miller and Cathy McFarland. Across lying, hiding disgust, and reacting to someone breaking the rules, the result was the same. People believed their insides were showing, and they mostly weren’t. We confuse how strongly we feel something with how clearly we’re showing it.

On product teams, this one hides well because it feels like everyone else’s fault. I share a roadmap review where I was sure my crossed arms and pointed questions made my concerns obvious, and my PM walked away thinking I was totally fine with it.

This week, we look at how the same bias shows up in Slack tone, design critiques, performance feedback, stakeholder negotiations, and async work, and why the fix is almost insultingly simple: say the quiet part out loud. So if you’ve ever been blindsided by “but you didn’t say anything,” give this one a listen.

Topics:

• 00:00 - Tap out Happy Birthday on your desk

• 01:00 - What is the illusion of transparency?

• 03:00 - The roadmap review where nobody knew I disagreed

• 04:25 - Why we think our feelings are visible

• 04:55 - The research behind the bias

• 05:55 - Egocentric anchoring: why this happens

• 06:30 - The spotlight effect and the curse of knowledge

• 07:00 - Can knowing about the bias fix it?

• 07:45 - Why your Slack tone gets misread

• 08:10 - The thumbs up emoji problem

• 08:55 - Design critiques and "obvious" rationale

• 09:15 - Why your feedback isn't landing

• 9:40 - Stakeholder negotiations

• 10:00 - Remote and async work turns it up to 11

• 10:45 - The insultingly simple fix

• 11:05 - Assume you're harder to read than you feel

• 11:45 - Say the obvious thing out loud

• 12:15 - Make feedback impossible to misread

• 12:50 - Read their words, not their face

• 13:20 - Build check-backs into async work

—

Thanks for listening!

We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.

If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.

• ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Get a FREE audiobook AND support the show⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

• ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Support the show on Patreon⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠• ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Check out show transcripts⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

• ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Check out our website⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

• ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Subscribe on Apple Podcasts⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

• ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Subscribe on Spotify⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠• ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Subscribe on YouTube⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

• ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Subscribe on Stitcher⁠⁠

When my team moved from Figma to Cursor, we gave things up on purpose. In this episode, I walk through the real ledger: lost visual history, the comment threads that held our why, a rejected pull request, and what we gained by designing with the real product instead of a picture of it.

When your design team trades the canvas for code, what actually disappears, and is what you get back worth more than what you lost?

A few months ago, I designed a full-page drag and drop interaction, cut it for a technical constraint, and then went looking for it a month later when that constraint disappeared. It took me 15 minutes and an AI assistant to dig it out of an old pull request. In Figma, it would've taken under a minute. And if a year had gone by, or I'd left for Costa Rica to take up surfing, nobody would've known it existed. That little treasure hunt is where this episode starts.This is episode three of "What Survives: When AI Comes for Your Design Work," and it's all about the trade-offs. I get into what my team lost when we left a canvas design tool behind: the visual iteration history that came for free, the comment threads that quietly held the why behind our decisions, the blank canvas (which, as it turns out, may have been gone long before AI showed up), and a command line skill set I can feel getting weaker every day. I also take on a fair pushback from a listener named Elena, who argues teams rarely look back at old versions anyway.But it's not a horror story. I talk through the other side of the ledger too: turning six months of Figma work into working, production-ready pages in days, the rejected PR that made me wonder if we were just cosplaying as engineers, and how we found our lane with engineering afterward. If your team has made the switch, or is about to, give this one a listen and then tell me what you traded away.

Topics:

• 03:10 - The foundation nobody sees
• 04:10 - Not a picture of the design, the design itself
• 04:50 - Losing the visual history
• 06:15 - Recovering a decision, not browsing
• 07:40 - Where the why actually lived
• 09:05 - How we kept collaboration alive
• 09:45 - When tooling costs more than a human
• 10:20 - Was the blank canvas ever blank?
• 11:15 - Auto layout was already doing the work
• 12:15 - The skills I'm renting
• 14:10 - The other side of the ledger
• 14:45 - Months of Figma work rebuilt in days
• 15:35 - The PR that got rejected
• 16:30 - Finding our lane with engineering
• 17:25 - Saved time is contested territory
• 18:15 - Engineers weren't territorial
• 19:25 - Designer or UI engineer?
• 20:05 - Back to pen and paper

—

Thanks for listening!

We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.

If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.

• ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Get a FREE audiobook AND support the show⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

• ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Support the show on Patreon⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠• ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Check out show transcripts⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

• ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Check out our website⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

• ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Subscribe on Apple Podcasts⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

• ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Subscribe on Spotify⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠• ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Subscribe on YouTube⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

• ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Subscribe on Stitcher⁠

This week we dig into belief bias, the reason your team grills the research it doesn’t like and waves through the stuff it already agrees with. Same evidence, two completely different levels of scrutiny.If you’ve ever won an argument at work, how sure are you that you made the better case and not just the more popular one?Belief bias is what happens when we judge an argument by whether we agree with where it lands instead of whether the logic actually holds up. If the conclusion sounds right, weak reasoning gets a pass. If it sounds wrong, suddenly everyone turns into a fact-checker. It’s one of the oldest reasoning errors on record, first noted back in 1928, but the study that set the template came in 1983 when Evans, Barston, and Pollard separated two things that usually travel together: whether an argument is valid and whether its conclusion is believable. People accepted believable conclusions about nine times out of ten, no matter whether the logic held.On a product team this shows up everywhere scrutiny is supposed to live. The design direction everyone already likes gets a thin rationale waved through, while the unexpected one gets picked apart. A sloppy study that confirms the roadmap is “directionally useful,” and a solid one that threatens it is suddenly “not statistically significant.” The same point lands when a senior person makes it and stalls when a junior person says the exact same thing. The fix isn’t to distrust your gut. It’s to grade the reasoning before you look at the conclusion, notice when the hard questions only come out for answers you don’t like, and slow things down when the stakes are real.Give it a listen and catch yourself before belief bias makes the call for you.Topics:

• 00:00 - Same idea, two meetings

• 03:45 - Two research studies, same afternoon

• 05:05 - What belief bias actually is (and where it came from)

• 06:00 - The 1983 study that proved it

• 07:00 - Why it happens: fast belief vs slow logic

• 08:10 - Belief bias is not confirmation bias

• 08:40 - Where it shows up on product teams

• 10:00 - Does group discussion fix it?

• 11:20 - 5 ways to catch belief bias

—

Thanks for listening!

We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.

If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.

• ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Get a FREE audiobook AND support the show⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

• ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Support the show on Patreon⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠• ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Check out show transcripts⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

• ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Check out our website⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

• ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Subscribe on Apple Podcasts⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

• ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Subscribe on Spotify⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠• ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Subscribe on YouTube⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

• ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Subscribe on Stitcher⁠⁠