There's a particular sound a product makes when it fails. It isn't a complaint. It's a question.
"Wait, where's…"
I've heard it in a control room on a vessel. I've heard it from a dispatcher with fifteen tabs open. 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 that. 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. That's the job. You ask what the system needs to do, and 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. 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.
You can't ask. You can only show.
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 rough, and sometimes deliberately incorrect. Not as a deliverable. As a provocation. Because people cannot reliably tell you what right looks like, but they will tell you instantly when something is off. That reaction is not a preference. It's expertise surfacing involuntarily, and it is the closest thing to a direct read of the mental model you're going to get.
Show a safety officer a permit approval screen that doesn't display isolation status, and he won't say "the requirement is to display isolation status." He'll say "hang on, I can't sign this." Then he'll explain why, and in explaining why, he'll hand you three more things you never would have found.
The wrongness is the instrument. A polished prototype gets you politeness. A rough one gets you the truth.
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.
Why this decides adoption
Most teams measure whether a product works. That's the wrong bar, and it's why so many correct products sit unused.
The real path is acceptance, then trust, then habit, then dependency. People try it. Then they believe what it tells them. Then they reach for it without thinking. Then they cannot work without it.
Silent essentials sit at the first gate. One "wait, where's…" and you don't get acceptance, so you never get to trust, and the rest never happens. It doesn't matter how much of the spec you delivered. 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 kills the product is usually not in the backlog. It was never in the backlog. Nobody put it there, because nobody knew it needed to be.
What this means if you're building something
Technology can say yes to almost anything now. Building is no longer the hard part. 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.