The Allegory of the Cave and User Requirements
Users describe symptoms, not problems. Building software from requirements is building what cave dwellers think they need.
Your eyes hurt when you work on your laptop at night. You go buy a desk lamp. Better lighting should fix it, right?
It doesn’t. The problem was never ambient light. It’s the blue light from your screen. What you needed was a pair of blue-light filtering glasses, or the Night Shift setting that’s been on your laptop the whole time. You bought a lamp because your mental model of “eyes hurt at night” maps to “not enough light.” A reasonable solution to the wrong problem.
This is Plato’s allegory of the cave, applied to building software.
In the allegory, prisoners chained inside a cave see only shadows projected on a wall. They take the shadows for reality because they’ve never seen the objects casting them. The shadows aren’t random — they correlate with real things. But they’re flat, incomplete, and misleading if you try to reconstruct the world from them alone.
User requirements are shadows.
Requirements Are Symptoms in Disguise
Users don’t describe problems. They describe symptoms filtered through their mental model of the problem space. That mental model is almost always incomplete — not because users are incapable, but because they operate in the symptom space, not the problem space. They are experts in their domain (sales, logistics, operations), not in the medium you’re shaping (software, data systems, infrastructure).
“We need a dashboard.” What that usually means: “I can’t tell if things are working.” The real fix might be better alerting that pushes the right signal at the right time. The dashboard gets built, nobody checks it after the first week, and the original problem remains.
“We need a faster export.” What that might mean: the export shouldn’t exist at all. The downstream system should pull the data directly. But the user has only ever interacted with the export, so that’s what they ask to improve.
Every requirement is a solution disguised as a need. The user has already done the problem-solving in their head — using the wrong model — and handed you the conclusion. Engineering that starts from requirements starts from shadows.
This Isn’t a Communication Problem
More user interviews won’t fix this. Neither will better requirements documents, longer discovery phases, or more empathetic listening. Those are all valuable, but they operate within the same constraint: the user can only describe what they can see.
Asking a user what software to build is like asking someone who’s never left the cave to describe the sun. They’ll describe a very bright shadow. It’ll be internally consistent. It’ll sound reasonable. And it’ll be wrong.
The gap between what users ask for and what they actually need is not a process failure. It’s structural. It’s inherent to the relationship between someone who lives in a domain and someone who builds systems to serve that domain. The user knows their world deeply. They don’t know yours. And the solution lives at the intersection.
Study the Sun Before Entering the Cave
The engineer’s job is not to ignore the user. It’s to understand the problem space before talking to them.
Say someone asks you to build a system to track customer interactions. You don’t start by collecting their requirements. You go study how people who deeply understand customer relationship management have designed solutions — Salesforce, HubSpot, Zendesk. Not to copy their features, but to understand how they see the problem. The architecture of a solution built by people who spent decades in a problem space is a map of how they decompose that problem. Leads, opportunities, pipelines, lifecycle stages — these aren’t arbitrary features. They’re how domain experts think about customer relationships. Studying how the solution works teaches you how they view the problem space.
Then you enter the cave.
Now the shadows make sense. When a user says “we need a spreadsheet where reps log their calls,” you hear the shadow and you see the object: they need structured activity tracking tied to a contact lifecycle. The spreadsheet is the shadow of that need.
And here’s what matters most: once you understand the problem space, you can tell the difference between what is true about customer relationship management in general and what is true about how this team does it right now. Leads and opportunities are domain concepts — they’ll exist in some form no matter how the business evolves. But the specific scoring rules, the routing logic, the stage names — those are current business rules. They will change.
The person in the cave can’t make this distinction. To them, their view of the world is the world. “We score leads by company size and industry” feels as fundamental as “leads exist.” An engineer who’s studied the sun knows which part is the object and which part is the shadow. You build the system so that the universal structure is stable and the current-specific rules are easy to evolve without touching the rest.
The Job That Remains
Drew Hoskins recently published The Product-Minded Engineer on this topic — about engineers developing the instinct to look past what users ask for and understand what they actually need. I haven’t read it yet, but the premise resonates with this argument.
The deeper point stands regardless: this is the fundamental reason software engineering exists as a discipline. Someone has to understand the world outside the cave, then go back in and build something that addresses reality rather than shadows.
AI makes this sharper, not softer. AI is extraordinarily good at building what you ask for. If what you asked for is a lamp, you’ll get an excellent lamp, faster than ever. The bottleneck was never building. It was figuring out that you needed glasses.