The User You’re Designing For Is a Myth. Here’s What’s Real.

You know the feeling. You sit in a meeting, nod along, write down every request. The manager wants more configuration. The frontline worker wants fewer fields. The compliance officer wants every click logged. You go back to your desk, build a requirements document that looks like a masterpiece of stakeholder alignment. And then, six months later, the system is a bloated mess that nobody actually likes.

Here’s the uncomfortable truth: You’re not a product manager. You’re a stenographer. You’re treating user statements as gospel, when in reality, they’re just the surface of a much deeper problem. The user you think you’re designing for — that stable, consistent persona with clear preferences — doesn’t exist. Not in the way you think.

I’ve been there. I’ve written those documents. I’ve watched teams burn months on features that solved nothing because we were too busy recording ‘who said what’ instead of asking ‘why did they say it now?’

Let me show you what’s really going on.

The Same Person Will Ask for the Opposite Things

Here’s a trap every product manager falls into: the same user, different days, contradictory demands. One day, the operator wants fewer fields and faster flows. The next day, during an audit review, that same person wants every action logged, every validation strict, every change traceable. You think they’re inconsistent. You think they don’t know what they want.

Wrong. The user isn’t changing. The scenario is. When they’re entering data, their job is speed and accuracy. When they’re being audited, their job is proof and blame avoidance. The same person, two different contexts, two different sets of needs. The mistake is treating the person as a single, stable source of truth.

This is why your product feels like it’s fighting itself. You’re trying to satisfy both voices without understanding the switch that flips between them.

Your Persona Is a Label, Not a Key

Personas are comforting. ‘This is the operator. He wants simplicity.’ ‘This is the manager. She wants control.’ But here’s the problem: A persona can explain who someone is, but it can’t explain why they need something right now.

An operator on a low-risk, routine task is a different person than the same operator on a high-stakes, blame-sensitive task. A manager approving a routine expense report is not the same as a manager approving a million-dollar contract. The role is the same. The scenario — and the risk — is not.

I’ve seen teams spend weeks building a ‘flexible configuration panel’ because the manager said she wanted flexibility. Then they realized the real need was not flexibility — it was avoiding the risk of being stuck waiting for a developer every time a business rule changed. The feature request was a symptom, not a solution.

The Real Problem Is Blame Avoidance

Here’s the provocative angle that most product managers won’t admit: A lot of ‘requirements’ are actually requests for organizational risk transfer. The manager wants configuration because she doesn’t want to be blamed when the system can’t adapt. The operator wants fewer fields because he doesn’t want to be blamed for making a mistake on a cluttered screen. The compliance officer wants logs because she needs to prove she did her job if something goes wrong.

You’re not just building features. You’re building mechanisms for blame avoidance. And if you don’t see that, you’ll keep adding layers — more configuration, more fields, more logs — until the system collapses under its own weight. Every stakeholder’s request gets a response, but no one is happy.

The Only Unit That Matters: The Scenario

So what do you do? Stop designing for ‘users.’ Start designing for scenarios. Every time someone says ‘I need X,’ ask yourself: What task are they trying to complete right now? What outcome are they responsible for? What constraints are they under? Who will take the fall if it fails?

This is not about being difficult. It’s about being honest. A ‘query’ function is not a query function. In a low-risk operation, it should be fast and simple. In an audit context, it must be complete, immutable, and traceable. Same feature name, completely different design.

I’ve seen teams transform their velocity when they shifted from persona-based to scenario-based analysis. They stopped building features that served abstract ‘users’ and started building tools that served real moments — with real stakes, real constraints, and real consequences.

The Four Layers You Must Separate

Every time you get a request, tear it apart into four layers: the person (who they are), the expression (what they said), the persona (the role you think they have), and the real need (what task, goal, and constraint triggered the statement). Most product managers stop at layer two. The best ones dig to layer four.

Write down the exact words. Then ask: ‘Why are you saying this now? What happened just before this meeting? What are you afraid will happen if we don’t do this?’ The answers will shock you. They’ll reveal that the real need is often not a feature — it’s a process change, a policy clarification, or a risk mitigation strategy.

This is the difference between building a product and building a dumpster fire of features that exist only to cover someone’s ass.

The Bottom Line

Stop treating your users as stable individuals. They’re not. They’re nodes of needs that activate differently depending on the scenario, the task, and the risk. The product manager who understands this stops being a stenographer and starts being a diagnostician. You don’t need more features. You need better questions.

And the next time someone tells you ‘the user needs X,’ remember: The user is not a person. The user is a set of problems waiting for the right context to emerge. Design for the context, not the label.