There's a particular sound a product makes when it fails, and it isn't a complaint, it's a question.
"Wait, where's…"
I've heard it in an operations control room. I've heard it from a dispatcher out in the field, hands full, a device in each. It comes about ninety seconds into someone using the thing you built, and it is the most expensive sentence in software, because by the time you hear it, you have already shipped.
What follows that question is never a feature request. It's a fact so obvious to the person saying it that they never thought to mention it. Of course you'd see that. Why would you approve something without knowing it? Everyone does it that way.
I call these silent essentials. They're the things nobody asks for, because nobody knows they need to say them out loud.
Why requirements don't find them
Requirements capture what people can articulate, and that's the job. You ask what the system needs to do, people tell you, and you write it down.
The problem is that expertise doesn't live in the articulable part. Someone who has done a job for fifteen years has compressed thousands of decisions into instinct. They don't experience their own knowledge as knowledge, they experience it as how things are, and you cannot ask someone to describe water when they've never been out of it.
So you can run a perfect discovery process, tick every requirement, satisfy every stated need, and still build something people quietly stop using, not because you got anything wrong, but because you got everything they said and none of what they meant.
This is why "we gathered requirements" is not a defence: the requirements were never the risk.
Three kinds of silence
Not all silent essentials are silent for the same reason, and the reason tells you how to find them.
Too obvious to say. The thing so fundamental to the work that mentioning it would be strange. Ask someone what they need to see before they approve a job, and they'll list the fields on the form. They won't tell you they need to know whether the equipment is actually isolated first, because in their world you obviously know that. It isn't a requirement, it's the ground.
Too embarrassing to say. The workaround: the spreadsheet everyone maintains alongside the official system, the photo taken on a personal phone because the real process is too slow. Nobody volunteers these in a requirements session, because in a room with their manager, describing the workaround sounds like admitting to doing the job wrong. It isn't, it's the system telling you where it failed, and people patching it at their own expense.
Only visible in failure. What you reach for when it goes wrong at three in the morning: the undo, the record of who changed what, the way back. Nobody designs for the bad night, because when you ask people about their work, they describe the good day. But adoption is decided on the bad night. That's when someone finds out whether the tool is with them or in the way.
Let the work do the talking
If people can't tell you what they know, then interviewing harder is not the answer. More questions produce more of the same articulable surface.
What works is showing them something wrong.
I build prototypes that are deliberately incomplete. Sometimes they're rough, so the gaps show and people fill them in for me. Sometimes they're suggestive, leaning toward a direction to see whether someone follows it or pulls back. Either way, it's there to provoke a reaction I can treat as data, because people cannot reliably tell you what right looks like, but they will tell you the moment something is off. That reaction isn't a preference, it's expertise surfacing on its own, and it's the closest thing to a direct read of a mental model you're going to get.
The incompleteness is the instrument, and its fidelity is a dial I set on purpose. Too polished and it looks decided, so people hand me politeness instead of a reaction. Too rough and they react to the roughness itself, the missing states and the placeholder labels, which is noise I don't need. What I'm after is just enough fidelity that the thing feels real and not a touch more, so the reaction lands on the decision I'm testing rather than on the rendering.
The questions that work are small and concrete. What would you do next? What breaks if this is wrong? Would you ever act on this data? Each one puts the person back inside the work, where the knowledge actually lives, instead of asking them to hover above it and describe themselves.
Becoming someone's everyday
All that effort to surface silent essentials points at one thing, which is whether the product actually gets used. Working is the low bar, and it's why so many correct products sit unused. Anything can be bought and rolled out, but being picked up, kept, and woven into someone's day is a different thing entirely, and it's the only version of success that holds. The best outcome is when a product quietly becomes part of someone's everyday.
That doesn't happen in one step. It moves through acceptance, then trust, then habit, then dependency. First they try it, then they believe what it tells them, then they reach for it without thinking, and then they cannot work without it.
Silent essentials weigh most at that first gate. One "wait, where's…" and acceptance stalls, so trust never gets a chance to form, and the rest rarely follows. It doesn't matter how much of the spec you delivered, because the person made a judgment in ninety seconds about whether this thing understands their job, and you failed it on something you were never told about.
That's the uncomfortable part: the thing that holds a product back usually isn't in the backlog, and it never was, because nobody knew it needed to be there.
What this means if you're building something
Technology can say yes to almost anything now, and building is no longer the hard part, because anyone can generate an interface, spin up a prototype, ship a feature.
The gap is knowing what's worth building. And the things most worth building are frequently the ones nobody requested, because they're too obvious, too embarrassing, or only visible when everything has already gone wrong.
So when you write the requirements, assume they're incomplete in a way the people who gave them to you cannot see. Then go and be wrong in front of them, on purpose, early, while it's still cheap.
The reaction is the requirement.