The fastest way to design the wrong thing is to start designing in the first meeting.
There's a pull, in presales, to solution early. Someone describes a problem and the architecture assembles itself in your head before they've finished the sentence. You've seen this shape before. You know what it needs. Reaching for the answer feels like competence, and it's flattering to be the person with the design already half-drawn.
It's also how you end up solving the problem they described instead of the one they have. The first articulation of a requirement is rarely the real one. It's the symptom they noticed, framed in the language they happen to use, shaped by a solution they've already half-imagined. Take it at face value, design straight to it, and you build something technically sound and quietly beside the point.
Discovery is the discipline of staying in the question longer than is comfortable. Why this, why now, what happens if nothing changes, what does good actually look like to you. Boring questions that feel like they're delaying the clever part. They're not delaying it. They're aiming it.
The strongest solution architects I know are the slowest to draw the diagram. They've learned that the diagram is cheap, and being right about the problem is everything.
Understand first. Design second. In that order it's a solution. In the other order it's a guess that happens to look like one.