The real requirements are never in the requirements doc. They’re in the spreadsheet someone built because the official system doesn’t work.
Every organization runs two processes at once. There’s the documented one — in the SOP, the one people describe in meetings. And there’s the actual one — the workarounds, the shadow spreadsheets, the “oh, we don’t really use that field,” the steps everyone quietly skips.
The gap between those two is where the truth lives. And it’s the part requirements interviews almost always miss, because people describe the process they’re supposed to follow, not the one they actually do.
This is where AI earns its place in discovery. Point it at the messy evidence of how work really happens — the tickets, the exports, the email threads, the tools people built for themselves — and it can synthesize the actual workflow out of the noise. Not what they say they do. What the evidence shows they do.
I’ve watched a single shadow spreadsheet rewrite an entire set of requirements, because it revealed the real bottleneck nobody mentioned in a single interview.
Build for the documented process and you ship something technically correct that no one uses. Build for the actual one and you ship something that fits how people already work.
Stop asking people to describe their process. Go find the evidence of it.