The Ultimate Product Management Interview Question

and the Curse of Knowledge bias.

Ashwini Sriram
5 min readMay 14, 2021
Photo by Kaleidico on Unsplash

A couple of years ago, I interviewed for a product manager position at a Silicon Valley company. I didn’t get the job, but it is till date one of the best PM interviews I have attended.

My interviewer asked me this deceptively simple question, and it shifted my perspective on storytelling.

The question:

“How would you verbally explain the rules of your favorite game to someone who has never played it?”

During the interview, I picked my favorite early 2000s mobile game — Snake. I then started explaining the rules of the game:

As the player, you need to press the arrow keys to move your “snake” in the direction of the food. As your snake eats the food, it will grow longer, and it becomes harder to navigate the snake. Your goal is to ensure that the snake doesn’t go off the sides of the screen, or that it doesn’t run into itself.

Fairly simple, right?

Wrong. My explanation assumes that my imaginary audience has the same context that I do about mobile phones, mobile games, using arrow keys on a mobile keypad, and even what I’m thinking when I say “snake” and “food”.

The first question I should have asked is

“Who am I explaining it to and what do they already know?”

As a product manager, your job mainly involves building a shared context among your teammates about the problems you are trying to solve. This is hard to do because of a bias we all suffer from called the “Curse of Knowledge” bias.

What is the Curse of Knowledge Bias?

The curse of knowledge is a cognitive bias that occurs when an individual, communicating with other individuals, unknowingly assumes that the others have the background to understand.*

It was best demonstrated in 1990 by a Stanford University graduate student of psychology, Elizabeth Newton. She recruited people for a game involving “tapping” and “listening”. The “tappers” were asked to communicate a well-known song like Happy Birthday by just using a table-top to “tap out” the rhythm. The “listeners” were asked to guess the song.

Listeners guessed only 2.5% of the songs, even though they predicted they’d get 50% right. Why the discrepancy between expectation and reality?

When the “tappers” tapped out tunes, they couldn’t help but hear the tunes in their heads, while the listeners actually only heard a morse-code-like staggered tapping. This probably annoyed the tappers and made them look at the listeners like they were idiots.

Here’s the deal: You, as a product manager, are probably making the same error as the “tappers” in the experiment. You are likely overestimating the extent to which the other person has the same context that you do.

While I thought I was doing a good job of explaining the rules of ‘Snake’, I was actually suffering from the same Curse of Knowledge bias. In my head, I could imagine the Nokia 1100 phone, the Snake moving across the screen, growing in length, the blinking bits of “food” I was supposed to navigate the “Snake” towards, using the “arrow keys” which were actually the 2, 4, 6, and 8 buttons on the phone. I didn’t explain any of these details to the interviewer or my imaginary audience.

Image courtesy:

Ways to correct for the Curse of Knowledge bias

We all think that the people we speak to have the same mental models as us. As we begin to build global products, for different kinds of people, we need to be aware of the Curse of Knowledge bias. Here are some methods I use, to combat the “Curse of Knowledge” bias at work.

1. Set the right context

Ask yourself why you are telling a story (example: explaining the rules of Snake), to whom.

Don’t make assumptions about your audience and what they know. When you are presenting, include a context setting slide to get everyone up to speed on what you are talking about.

When you are writing product requirements, although you might have explained the product to your audience before, start the document by answering a set of basic questions about your product, and the document itself.

  • The document: What is the goal of the document/presentation? Who is it for? What other knowledge does your audience need to effectively read it?
  • The product: What does your product do? What problem does it solve, and for whom?
  • The team: Who is building the product?

2. Be specific

Your leader might say “Let’s build customer delight!”.
You might think: “Oh great. Another corporate person saying something vague and non-descriptive.”

You don’t make the same mistake. Give examples wherever possible.

For example (ha!): Trader Joe’s describes its target customer as an “unemployed college professor who drives a very, very used Volvo.”. That is specific. It helps paint a picture to its employees looking to experiment with selling new foods.

3. Use visual aids

If the interviewer had allowed me to draw, I’d have drawn the snake, the food, and the brick-like Nokia 1100 to paint my audience a picture of “Snake”. A picture makes your audience go ‘Aha!’ in a fraction of the time that it takes for you to explain it otherwise.

(I should have drawn this ^ idea!)

I always create simple block diagrams explaining my mental model, i.e., my thought process about how something works in the real world, before I walk into meetings. It saves a TON of time. It really doesn’t have to be fancy. There is no “right” or “wrong” here. You just need to describe your mental model.

My mental model for what it takes for me to be productive at work.

As a product manager, you are probably in many customer meetings, talking to various stakeholders, and getting multiple perspectives on the problem you are solving. Remember that the teams you work with are likely to have less context than you. Beware of the Curse of Knowledge bias.

It is known to have caused failed military actions.




Ashwini Sriram

Technology leader from Chennai living and writing in San Francisco.