Most first meetings go wrong in the same direction. The client describes a solution, the engineer nods along and starts thinking about the implementation, and at the end of the call both parties leave thinking they're aligned when they've actually just agreed that some software should exist. They haven't agreed on what problem it solves.
Get to the problem under the solution
"We need a CRM" is not a problem. A CRM is a solution someone has already landed on, which means you've skipped the step where you find out whether a CRM is actually the right answer.
The question is: what's broken about how you're managing customer relationships right now? The answer to that is the problem. Sometimes it points to a CRM. Sometimes it points to a better-organized spreadsheet with a couple of automations. Sometimes it points to something specific that existing CRMs don't do, which is where custom software makes sense.
If you skip this question and just start designing the CRM, you might spend weeks building something that a $15 SaaS tool would have solved.
Questions that matter
What does the process look like today? Walk me through what happens, step by step. This reveals the actual pain rather than the described pain. It also surfaces edge cases and exceptions that the client usually forgets to mention upfront because those things feel obvious to them.
Who are the users? How many of them are there? What's their technical comfort level? This affects every design decision you'll make. Software for five internal ops people is different from software for five thousand external customers, even if the underlying functionality is similar.
What does success look like in six months? This question is useful because it distinguishes between "we need this to exist" and "we need this to change something specific." The second one is a much more useful problem statement. It also gives you a way to evaluate whether the solution actually worked.
Have you tried to solve this before? If yes, what happened? A previous failed project is not a red flag by itself. A previous failed project where the client attributes all the failure to the vendor, with no recognition of their own role in it, is worth paying attention to. It tells you something about how the relationship will go when things get difficult.
What to listen for
Vagueness about who the users are. If the client can't tell you who will use the software, that's a signal that the problem hasn't been defined precisely enough to build against. The user shapes everything.
No clear success metric. "Better than what we have now" is not a success metric. It means the project can never be finished because there's no definition of done.
Unrealistic timeline expectations. Sometimes this is just optimism and can be corrected with a conversation. Sometimes it's a sign that the project is under pressure for reasons you don't know about yet, and that pressure will show up as scope conflicts later.
What to do after the meeting
Write up what you heard. Not a proposal, not a spec, just a plain summary of the problem as you understood it, the constraints that came up, and any open questions you have. Send it to the client within 24 hours and ask them to correct anything you got wrong.
This step looks like housekeeping. It's actually the most important thing you can do in the first week. It surfaces misunderstandings early, when they're cheap to fix. It demonstrates that you were listening. And it starts building the written record that will matter when ambiguities come up three months into the project.