There's a version of rigour that ships a 90-page requirements document after six months and calls it progress. Everyone has been interviewed. Every workshop has a Miro board. And nothing anybody believes has been tested against reality, because nothing has been built.
Discovery matters; we put our name on it as the first stage of how we work. The question is not whether to understand the problem. It's how long understanding is allowed to remain theoretical.
Understanding is verified by building
The most information-dense artefact in any software project is working software in front of the people who will use it. A fortnight of focused discovery followed by a working slice of the riskiest part of the system produces better requirements than a quarter of workshops, because the slice makes people react to something real. 'That's not how we do it' arrives in week four, when it's cheap, instead of month nine, when it's a change request.
This is also, frankly, a test of your supplier. A firm that needs six months before the first line of code is telling you about its cost structure, not your problem's complexity.
So we keep discovery short, intense and honest, and we let the building start while the understanding is still warm. Complex problems don't get clearer by being described for longer. They get clearer by being worked.