You've Never Met Your User — You've Only Met Yourself

Day 1: You Already Have a Persona — It's a Mirror

Every time you decide what to log, what to default, or which edge case to just skip — you're making a call about someone. You never wrote that someone down. That doesn't mean the slot is empty. It means it's filled with you. Fine when you're building a CLI for other engineers. Expensive fast when what you're shipping is an AI agent that a non-technical person is going to trust to act on their behalf.

The feature you loved that nobody used

A few years back I shipped a verbose debug mode for an internal agent tool — every tool call, every retry, every token of reasoning streamed straight to the terminal. I loved it. I lived in that log. Two weeks later a support ticket landed: "the tool is broken, it just prints garbage forever." I pulled the session recording. The user had never asked to see the agent's reasoning. They wanted a yes or a no and a result. I'd built the feature for the one user I actually know how to observe: myself.

Name the mechanism: 'I use this too' becomes 'therefore I know'

Engineers are almost always the primary user of their own dev tools — CLIs, internal dashboards, agent harnesses, the product itself before it ever ships. That's genuinely useful. Dogfooding catches real bugs. The trap is the inference that rides in quietly behind it: I use this, I understand this, therefore I know what users want. That's not empathy. That's self-projection wearing empathy's clothes. And it feels like real user understanding, because you do have a real, detailed mental model of a real user. It just happens to be you.

Why this is invisible, not stupid

Nobody hands you a persona doc on day one and says interrogate this before you ship. There's no `assumed_user` variable in the code forcing you to fill it in. So the slot fills itself, quietly, with whatever data point is closest to hand — your own head. This isn't a competence problem. Smart, careful engineers do this constantly, because catching it means noticing an assumption that never announced itself as an assumption.

The tell: 'obviously' and 'nobody would want that'

Listen for it in your own design discussions. "Obviously we should just surface the raw error." "Nobody wants a confirmation dialog here, that's annoying." Every one of those is a claim about a whole population of users, backed by a sample size of one — you, at your desk, with your context, your patience, your tolerance for jargon. It's not wrong because it's confident. It's wrong because it's citing a persona nobody ever named out loud.

• ▹"Obviously users want X" → obvious to whom, exactly?
• ▹"Nobody would click that" → nobody, or you, specifically, right now?
• ▹"This is self-explanatory" → self-explanatory to someone who wrote the code?
• ▹"I'd just read the docs" → you wrote software for a living. Would they?

Same mirror, sharper edges when you're building AI products

This bias doesn't get better with AI products. It gets sharper, for two reasons. First: if you're building an agent or a copilot, you're probably the most sophisticated prompter who will ever touch it. You know its failure modes. You phrase requests the way it likes. You catch a wrong tool call before it does any damage. Your real users won't. A support engineer using your agent to triage tickets isn't going to write a careful three-clause prompt with constraints — they'll type what they'd type to a human, and the gap between those two interactions is exactly where your persona-of-one breaks. Second: teams increasingly "eval" agents by vibes — an engineer chats with the model for five minutes, decides it feels smart, and ships. That's the same persona-of-one bias, now applied to your quality bar instead of your UX. Real eval sets, built from actual user transcripts, exist precisely to route around this.

Today's self-check

• ▹Next code review or design decision, pause on any sentence that starts with "obviously" or "users would".
• ▹Ask yourself directly: am I picturing a real user session I've actually seen — or myself, at 11pm, fixing this bug?
• ▹If you can't name a specific session, ticket, or transcript behind the claim, flag it as an assumption out loud. Don't ship it as a fact.
• ▹No framework needed yet. Today's just about building the noticing habit — catching the moment before you act on the mirror.

Noticing the gap is the whole job for Day 1 — you don't need a fix yet. Tomorrow: where to actually look instead of your own head. Real usage. Real transcripts. Real sessions. Not vibes.

Extend your knowledge

• ▹Read Rob Fitzpatrick's 'The Mom Test' — it's built almost entirely around catching yourself asking leading questions that confirm your own persona-of-one instead of surfacing a real one.
• ▹Pull up one real support ticket or session recording from your own product this week — not a summary, the raw transcript — and hold it against the last assumption you shipped without checking.
• ▹Building or evaluating an AI agent? Find, or start, a small eval set built from real user transcripts, and grade the agent against that instead of chatting with it yourself for five minutes.
• ▹Marty Cagan's 'Inspired' is a good companion read on why strong engineering instincts don't automatically make you a reliable stand-in for the actual user — useful context for why this bias is so common on eng-heavy teams.