As a business analyst running CRM and ERP discovery for clients, I sat in a lot of rooms where a stakeholder described their process and I nodded, wrote it down, and moved to the next question. That's the version of discovery that produces a document. It is not the version that produces a good product.
Most requirements gathering optimizes for the wrong thing
The easy failure mode in discovery is treating it as a transcription job: capture what the stakeholder said, structure it, ship it as a requirements doc. That produces an accurate record of what one person, on one day, remembers about a process they may not run end to end themselves.
The gaps are never in what people tell you. They're in what nobody thought to mention, because it's the part of the process so routine it stopped feeling like a decision.
In any discovery session, ask specifically about the step the stakeholder skips over fastest, the one that sounds too obvious to explain. That step is disproportionately likely to be where the real requirement, and the real gap, is hiding. People narrate exceptions. They don't narrate habits.
Why this matters more before code than after
A scope gap found in discovery costs a sentence: "wait, walk me through that part again." A scope gap found in sprint three costs a change request, a re-estimate, and a stakeholder who now wonders whether you understood the project at all.
That asymmetry is the entire argument for investing more in discovery than feels proportionate. It doesn't feel like "real work" to spend three extra days asking questions before anything gets built. It is, by a wide margin, the highest-leverage three days on the project.
Feasibility isn't a gate you pass once, at the start. It's a question you should still be able to answer in sprint six. If you can't, discovery didn't happen. Something that looked like discovery happened.
What I do differently now
- Map the as-is process with the person who runs it, not the person who owns it. Owners describe the process as designed. Operators describe the process as it actually happens, including the workaround nobody wrote down. Both perspectives are true. Only one of them is buildable against.
- Run a gap analysis before a feasibility check, not after. You can't assess feasibility of a requirement you haven't yet noticed is missing. Gap analysis surfaces the requirement. Feasibility tells you what it costs.
- Write the scope gaps down as risks, not as footnotes. A gap you found and didn't flag is a liability with your name on it. A gap you found and flagged, even if nobody fixes it yet, is a documented risk the business chose to accept.
The real skill isn't asking questions
Anyone can run a discovery session. The skill is noticing which answer was too smooth, too fast, too obvious to be examined, and going back to poke at exactly that one. Scope gaps hide in the parts of the story everyone already agrees on. That's why nobody looks there first.