When you ask people what they need, they often tell you what they want. Most of the time those line up. Sometimes they don't, and that gap is where a product quietly misses.
Asking is still the right place to start. It sets the boundaries, it tells you roughly where the problem sits, and people are often clearest about what they don't want. Best case, they know exactly what they're after and you're off to a strong start. The harder case is the one that looks fine: you build precisely what was asked for, ship it, and it turns out not to solve the thing underneath.
Part of why is that someone who has done a job for fifteen years, let alone thirty, knows things they can't easily put into words. The expertise that matters most has turned into instinct, and instinct is hard to say out loud, especially to someone who isn't in the same line of work.
So alongside the asking, I show them something. A rough prototype, deliberately incomplete, with the gaps aimed at the trickiest parts of the problem. Then I watch. People can't always tell you what's right, but they will tell you the moment something is off, and they'll tell you fast. That reaction fills the gap the questions leave.
Asking sets the edges of the problem, and showing catches what asking can't. The questions paint the boundaries, the line between what they need and what they want, and the prototype is how you explore inside it, rather than letting the work wander past the edges with nothing to hold it.