Forward-deployed / Learning zone
Product sensea standalone module
Lesson 02

Cognitive empathy: anticipating unvoiced needs

TL;DR

Cognitive empathy is understanding how users think, decide, and experience your product. It's distinct from emotional empathy, which is feeling their pain. It lets you predict what a user will need or do next, because you can simulate their perspective. Three tools build it: metacognition (examining your own thinking and biases), intellectual flexibility (changing your mind as evidence arrives), and simulation (mentally or literally walking the user's journey). Together they fight the curse of knowledge — the expert's blindness to what a novice sees.

🎯 For the AI PM

Why it matters — With an AI product, you're deep in the model's capabilities and jargon, so the curse of knowledge is acute. You know the prompt that works. The user has no idea what to type, what the model can do, or why it just refused them.

What it changes in your decisions — You design for the user's actual mental model of a chat box or a suggestion, not your expert one. You build the affordances — examples, hints, graceful failure — that a first-timer needs.

Ask yourself — "What does a user who has never seen our model assume it can do — and where will that assumption break?"

Risk if ignored — A powerful model that only power users can operate, because the team mistook its own fluency for the user's.

Metacognition — thinking about thinking

Cognitive empathy

Simulate, then verify · the loop that fights the curse of knowledge

Metacognition surfaces the assumption; reality either holds it or updates it.

Simulate the user — "if I were them, doing X…"
Surface your assumptions — metacognitive check
Verify with reality — watch users, talk, data
Model wrong
Intellectual flexibility

Change your mind — update the model

↻ loops back to simulate, again
Model held
Act on it

Build, cut, or fix with confidence

Metacognition is stepping back to examine your own decision process. For a PM, it guards against knee-jerk assumptions and the curse of knowledge — where an expert forgets what it's like to be a novice. A payments PM steeped in fintech jargon assumes an onboarding step is "obvious." A first-timer finds it baffling. Metacognitive awareness turns that assumption into a testable question: run a quick test with a first-timer rather than trusting expert intuition.

It also catches overconfidence. Teams grow sure of a solution after months on it, but people routinely overestimate their own accuracy. Two techniques:

In meetings, metacognition can be literal: pause and say "let's break down how we're arriving at this conclusion," making the implicit logic explicit and examinable.

Intellectual flexibility — changing your mind

Cognitive empathy needs flexibility: adapting your thinking as new data arrives, and holding perspectives other than your own. In fast-moving domains, rigidity leads to obsolescence. Flexibility means being able to say "I was wrong" or "the market changed, so our approach should too" without ego.

Cultivate it deliberately:

Simulation — walking in the user's shoes

To anticipate needs, simulate the user: "if I were a [target user] trying to do [X] in [context], what would I feel or do next?" Mental simulation surfaces gaps before they hit production. Ways to do it:

Some PMs write mini-narratives — "Jane opens the app to do X, expects Y, sees Z, gets frustrated" — because vividly imagining a task engages circuits close to actually doing it.

Many tactics, one strategy: talk to your users

A working PM's version of everything above comes from Twitter's Paul Rosania. There are many tactics for staying in tune with users, "but only one strategy: talk to your users." Three of his observations are worth keeping:

That last point is the practical answer to "can product sense be learned?" — yes, at the rate you accumulate direct user contact, and no faster.

Actionable steps

📦 Mini-case — the password "bug." Twitter PM Paul Rosania volunteered at computer-help sessions, and watched users mistype their password repeatedly and conclude Twitter was broken. No support ticket, survey, or dashboard would ever surface that as a product problem, because the users didn't know what happened, so they couldn't report it. Only direct observation catches the problems users can't articulate. That's the concrete case for simulation plus verification, never simulation alone.

Failure modes

Practitioner checklist