This morning I had the opportunity to overhear a young freelance developer talk with a store owner about a potential e-commerce project. It reminded me of a lot of the early pitches I made when I first started freelancing: a somewhat aimless and overly technical conversation that ended ambiguously.
We (developers) are great at solving technical problems, but we kind of suck at selling our hard earned (and valuable!) skills to people who aren't technical. Over the last fifteen years my pitching technique has evolved considerably. I hope that this introduction can give other freelance developers a healthy framework for those awkward prospecting meetings.
Sales with Integrity
Marketing! Sales! Presentations! Contracts! These are not the things that most software developers enjoy pursuing in their spare time, but they are critical components of building a successful freelancing business.
Take a deep breath. Empty your head of visions of pink Polo shirts, fake tans, and awful PowerPoint animations. Focus on one simple idea: how can I make my clients happy without sacrificing my integrity?
In essence, a sales meeting with a client boils down to five activities:
- Communicate at their level.
- Establish that you are trust worthy.
- Establish that you are interested in their goals.
- Establish that you can help them achieve their goals.
- Leave them with good information.
Communicating at Their Level
This is a difficult task for any human: how do you figure out how to effectively communicate with someone with different interests, different skills, and different motives than you?
The answer is relatively simple, but requires practice to get it right: use reflection and reinforcement.
Reflection is communicating at the same level as your prospect, using the same words and terminology. If they say "actionable," you might have to bite the bullet and say "actionable" in your response. You may want to beat your forehead against the wall for using certain phrases, but remember that these (horrible, cliche) words actually mean something to the person you're communicating with.
I have a tendency towards linguistic pedantry, and I know many other developers do as well. When you hear vague, irritating, or improperly used phrases, try to refrain from correcting or debating in the moment. There will be plenty of time for that later.
Reinforcement is demonstrating that you understand what your prospect is talking about, by asking questions that show your interest and knowledge. If someone says they want to meet and talk about building a web site to sell childrens clothing, spend some quality time on Google to find a couple of existing sites that achieve that goal, but in different ways. For example: "Do you have some examples of sites you like? I checked out HannaAnderson.com and LittleUrbanites.com; I'd love to hear more about what your vision is."
Obligatory Shout Out -- I highly recommend using Little Bird for researching companies and industries; it's great for finding key people and current events. Full disclosure: I'm the CTO, but I use it all the time to do exactly this kind of research!
Unless you're talking with a technical manager or another developer, refrain from referring to specific technologies or methodologies in your first engagement with a potential client. There are plenty of opportunities to establish specifics at a later date; in the beginning, the most important thing you can do is demonstrate that you can effectively communicate with them.
Trust is key to a freelancing relationship: someone will pay you good money to solve a problem they can't handle on their own, and chances are they don't know who you are, or understand how you do what you do. This is a risky position for your prospect. To help ease their mind, provide references, offer a non-disclosure agreement (NDA), and when you don't know something, say so!
References are the best evidence that you can be trusted. The best references come from clients in the same industry, for similar kinds of projects -- but those aren't always available, especially if you're just getting started.
With or without references, offering an NDA demonstrates that you are hungry for more information, and that you are comfortable committing to a relationship. If you bring your own NDA, it also shows that you are prepared. NDAs are a complex topic in and of themselves. I can't make specific recommendations on how to craft or deal with NDAs, other than it's best to keep it simple, and that you should never sign an NDA that contains an anti-competition clause (you're effectively a mercenary; if they don't want you to work with their competitors, they need to make you a hell of a good deal).
Admitting that you don't know something can be difficult. That said, it is infinitely better to ask for help than it is to make a bad assumption. Attitude counts when you don't know something: if you are positive about finding the answer, your clients will be happy to help you out, and trust that you have good intent.
In that same vein, the most effective "sales technique" I've found is enthusiasm. When I get excited, my clients get excited -- and vice versa. Expressing positive emotions and encouraging people to talk about their goals is an excellent bonding experience.
The difficulty is figuring out what to get excited about. For example, if your client is a designer working on an international marketing campaign, getting excited about the number of servers may not be something you can connect on. On the other hand, you may have better luck getting excited about reactive layouts and extending their designs to mobile devices.
The key is finding topics at the intersection of your skills, and having fun learning from your client.
The most awesome evidence in the universe is pointing at a successful project with a previous client that directly relates to the goals of your prospect. However, this isn't always possible: sometimes you're prohibited by a confidentiality agreement, or maybe you're trying to get started in a new industry.
Spend a little time working through a real problem. Ask questions, and offer answers. Don't get defensive if they disagree with you. Demonstrating how you work can be an adequate substitute for showing what you've done in the past, and it's the icing on the cake if you can provide references as well.
The trick is working through a problem in a way the prospective client understands. Remember that this is a sales process -- it won't help to scaffold a Rails application and build a few migrations. The goal is to engage with the client, not bore them with typing.
My favorite example is diagramming actor relationships on a whiteboard or sketch pad: talking with the prospect about who will be using the software (customers and administrators), how they will be interacting with it, and blocking out the major features. This will generate more questions than you have time to work out, which is perfect: wrap up the session by saying that you're running out of time, but excited to continue fleshing out the project.
Give Them Good Information
The goal of a sales meeting is to see if you and your potential client are a good fit. After establishing trust, interest, and expertise ... it's time to deal with time and money.
All projects have budget and time constraints. Ask what they are. The answer may not be clear (or even remotely feasible), but at least you know what their point of reference is.
To wrap up your conversation and give someone information that they can act on, you want to communicate five things:
- Your understanding of the project.
- How long you expect the project to take.
- How much you expect it to cost.
- Your confidence in your estimates.
- "Next steps."
Expressing your understanding is reasonably straight forward: quickly summarize the prospect's goals, and the project constraints.
Estimating is a dark art, and it's unlikely you can produce solid figure at this point: you're operating with limited information, so your estimates will be very imprecise! Never the less, you need to sketch out some ranges for delivery dates and total cost. Your goal is to figure out if you're in the same ball park as your prospect, not to make commitments. For example:
"If we start on June 1st, I expect that we will be able to release the website within three or four months. Given my rate of $100 per hour, I think the total cost for the project will be in the neighborhood of $30,000 to $40,000."
The workaround for lack of information is your confidence statement: You want to communicate to the client how confident you are in the estimate, and why. For example:
"I've done several of these projects before, and I'm very confident we can complete your app in about two months if everything goes smoothly."
... or if you're not feeling so confident:
"This is a complex project, and I expect that we may have to make some hard decisions about features in order to get this done within your time and budget constraints."
Finally, wrap up the meeting by suggesting the next steps to take in the process:
- Request that the client send you more information about some outstanding questions so that you can continue refining your estimate.
- Restate any additional information the client has asked you to provide, if any.
- Establish a time to reconnect.
Phew. That was a long introduction, and I suspect this post raised more questions than it answered -- there's heaps of related issues around rates, estimates, contracts, intellectual property, etc. I'm thinking about writing a handbook for developers who are interested in freelancing; anyone interested?