Hi,
At a first meeting with a client who has expressed interest in hiring you on a freelance basis what would you bring up?
Should you focus on the project in question or your skills or their more general needs or something else?
Advice/comments appreciated :-)
Talk about what they need specifically. Proceed throughout on the unstated assumption that it's a perfect match for your skillset. You can think about whether it is or it isn't in the car on the way home.
Read-up like mad about what they do the night before. Even the guys there already doing it won't be reading-up about it in the evening.
Come prepared with knowledge of their product/business. Discuss what it is they are trying to do (i.e. WHY they are hiring you), what it is they want (WHAT they are hiring you to do), and a timeframe for the project (WHEN they...).
Don't discuss potential solutions in any great detail, as you will want to spend time preparing those. Don't discuss money, as that would depend on the solution (a solution that takes twice as long to implement would cost more). If they ask for a ballpark figure, tell them you will send that to them as a part of a proposal.
That, of course, depends...
In general: Focus on the task at hand. Show that you want to solve his problems. That's what the customer is interested in.
Specifically, I would focus on two things:
Very often they are not the same, and that difference can be the cause of many problems. It gives you an opportunity to show off with your analytical skills, and you can proceed to showing off with your problem solving skills.
Try to get an understanding of what they want. It's a mistake that many developers make talking about themselves and cool technologies when they should be listening to what the client actually wants.
In this article, I mention this exact problem and offer some general advice on how to get that good first impression (sorry if it appears that I'm blowing my own trumpet here).
Inform yourself about what the client is doing but assume you don't know.
Try to leave technology and technologial slang aside, assume the client doesn't understand the language of technology.
Instead create a story with the client. A primitive one at first, then start elaborating it. Ask question based on your tech-knowledge but phrase them in prose. Let the customer tell you what he would like to do and how and help her find the potential pitfalls.
Go back to your desk with the client story and start translating it into some more techical language like a use case or whatever you like to do. This will generate new questions for which you will probably need some more stories from the client.
Iterate a few times like that without imposing techologies, solutions, etc. until you are really sure about what the client wants to do, how he wants to do it and what you think he needs to fullfill these goals.
Taking time for story telling will potentially save you a lot of time later. Don't start prototyping too early.
Once you start, get feedback from the customer early and often.
Tech-savy ppl you won't impress with tech, non-techs you will impress anyways. You will always impress customers if you make them feel that you know exactly what they need (in prose)!
I start off with going over the project at hand and the reason for it (i.e., what they want to accomplish by doing the project). Once I start to get a feel for it, I'll also generally have time to start brainstorming possible solutions, but would never try to lock one in until I've had time to think it over more thoroughly.
I will talk cost at initial meetings, but that's because I prefer to bill hourly. I generally won't give time estimates at this stage. I also try to find out what their budget for the project is, so that I can work up an appropriate proposal instead of wasting time on coming up with something far too elaborate for their budget or shaving off features until it doesn't do all of what they wanted.
While the specifics vary from project to project -- customers wanting a Web site will have needs far different from, say, customers wanting you to write a little app to perform a specific and limited technical task -- broadly speaking, the customer wants to feel like you understand two things: what they need right now now, and where they're trying to go with it.
Basically, that means listening. Ask about what they do, ask about what they're looking for, and think about (silently) whether what they're asking for really is what it sounds like they need, because part of your responsibility as a consultant is to consult -- to determine whether the thing they're asking for is appropriate, or whether there's an alternative option or approach that might serve them better in the long term. Sometimes clients think they want something simple, but don't understand the way "simple" can end up painting them into corners. Just ask, listen, and think about the bigger picture. If they believe you truly care about their success, you'll usually get the gig.
Alain Weiss's book Getting Started in Consulting is a great resource, too. Check it out -- I recommend it highly.
As far as talking money goes, the prevailing wisdom seems to be to avoid talking numbers -- but I happen to find something disingenuous about this, because while it's true you never know what something will cost before you know what the details are, if you have some experience, you probably do have some idea what it'll cost yourself, and there's no reason not to share that with the customer, other than to protect yourself, or to avoid scaring off the customer.
The customer wants to know what it'll cost, and if you know, you should tell them -- issue caveats, of course, tell them the devil's in the details, but if you know the project they're describing usually takes, oh, such-and-such time to build, and your gut tells you it'd be, roughly, five grand as opposed to two, or fifteen rather than five, tell them. In my experience, it rarely comes as a surprise, and if it does -- if the customer freaks out and says something like, "Wow, I had no idea it cost that much to do something like this," then you'll probably have saved each other a lot of time and headache broaching the subject earlier rather than later. If you treat it as a courtesy respectful of what they genuinely want to know, it's fine.
Lastly, I have to say that Will Dean is completely wrong -- you should never, ever mislead any client into thinking you're the appropriate person for a job you're not appropriate for. If you're not an expert, say so; if it calls for Java and you don't know Java, tell them -- don't lie by omission. That's extremely bad business, and it'll bite you in the butt one day if you're not careful.
Ask them about the problem they are having you solve. Dive deep and see what kinds of issues they want to avoid.