The first useful question is "why this, why now?"

Clients usually arrive with a solution already half-formed. "We need a portal." "We need AI in support." "We need to rebuild this service." Engineers are often quick to swat that away, but I don't think that's right. The portal solution will probably be fine. A more interesting part comes one sentence later. A sales team promised something, or an ops team is doing manual work every Friday. A customer is threatening to leave. A regulator changed the rules. The request is the surface area. The pressure behind it tells you what matters.

And it matters because problems and solutions are distinct, and treating them as a package deal makes both worse. If the real problem is that support is drowning, then the portal might still be a good idea. But first I want clarity on volume, repetition, and where the queue gets stuck. If the real problem is that sales keeps freelancing features into contracts, then a rewrite may still help, but now we can judge it against the actual problem instead of using it as a hopeful gesture. Same words, different job.

This is also why requirements sessions often feel oddly unproductive. Everyone is being honest, but not necessarily about the same thing. One person is describing the fix they already decided on. Another is describing the pain. Another is describing the internal politics in a safe dialect of project language. You have to listen for all three, then separate the problem from the proposed answer.

How often do you hear:
"You don't like my solution?? Why don't you care about my problem!?"

Once the problem is clear to everyone, the solution gets better too. More people can evaluate it on the same terms. You get better ideas, fewer weird debates, and much better buy-in. Not because everyone agrees by default, but because they're finally arguing about the same thing.

So I keep coming back to the same question.

Why this. Why now.