If you’ll recall the diagram from that first post, I pointed out that freelancers either figure out business ownership, or else they wind up employees. (Whether someone else’s employees, or just employees of their own, dead-end freelancing ‘business.’) Because of this, you might assume that the ideal would be to minimize, or even skip, the freelancing state.
But today I’m going to argue that, no, that’s not necessarily ideal. The interim freelancing state serves an important risk reduction purpose that a lot of folks (past me included) need.
So yes, you should definitely enter freelancing with an exit, business-owner state in mind. But no, I wouldn’t advise skipping it until or unless you thoroughly understand it.
In my last post, I offered freelancers a primer on sales. And in that post, I promised to start talking about marketing.
After all, effective marketing — getting buyers to come to you — is the main success driver for effective sales.
But as I laced my fingers, inverted my wrists, and stretched in the universal “I’m about to do stuff” pose, I realized something. Before we can get started on how you should market, we’re going to need to spend some time unlearning a bad habit.
In fact, an entire post’s worth of time.
The bad habit in question is how you, the freelance developer, LOVE to appeal to the wrong audience.
Specifically, you love to appeal to other software developers — your peers. You probably give occasional talks at user groups and conferences and have a nice Stack Overflow score. You’re looking endlessly for semi-objective signposts that make you stand out from the crowd when hiring authorities (or buyers) grade you.
This is a failure pattern. And I’m going to spend this post beating it out of you.
Back in March, I made a fake tweet for a blog post draft.
It was a blog post about how not to handle a situation where your large, only client (i.e. your salaried employer) abruptly breaks up with you. But given that the economy collapsed in on itself like a neutron star a week later, the post seemed in poor taste and I never published it.
Still, no sense letting a good fake tweet go to waste. So I’m going to use it instead for a post about freelance dev sales, which is basically a rounding error away from salaried dev job interviews.
What I’m going to do is walk you through the sales strategies that a dev freelancer will suffer through, in numbered order, before figuring out something that actually works. I’ll also have a couple of interludes to explain a little bit about sales along the way. The goal is that hopefully you can skip some of missteps and create a strategy for faster joy.
1. Introduction to Affiliate Sales: The I Just Got Fired Tweet
Here’s something that seemingly every developer tweets at some point in their career:
Usually it has approximately 8 billion retweets and likes, a handful of comments, and, I’d assume, a conversion rate just north of the Planck constant into useful job leads.
Why would I presume that?
Well, because the call to action invites people to do something super easy. “Smash that retweet button and do your good deed for the day.” So people do… exactly, and only, that.
And then they call it a day, assuming that someone else down the line will do the actual thing that might help this person. And, if it ever happened, the “actual thing” would probably be just introducing them to a corporate recruiter or, maybe a dev manager or something.
It’s a classic case of vanity metrics in the world of marketing. But I want to talk about the sales strategy here. Let’s save freelancer marketing for another day.
Following my last post, I could have gone in a few different directions, but I’ve opted to write on the subject of niches. After all, I’m nothing, if not a man of the people.
(Actually, that’s probably a terrible way to describe myself, but I’m going to try not to get too off the rails, too quickly, here).
So let’s talk about niches. I’m no longer going to ask you to believe me, axiomatically, that it’s better to get away from being a generalist as fast as you can. I’m going to build my case in this post.
There’s a Lot of Generic Niche Advice Out There. Don’t Worry About That Advice.
I did some extensive research to see if anyone had some good arguments in favor of niching for freelancers. And, by “extensive research,” I mean I did this Google search.
Then I braced myself for the onslaught of people hawking “I’ll teach you to freelance” info-products and dug in. Yes, I braved the pop-up email capture forms and squeeze pages so that you don’t have to.
After the gigantic rant I queued up last time, I’m going to resume instructional content in this business of freelancing series. I think I’ve driven home the importance of reasoning about profit and I’ve introduced you to some business models to think about.
So let’s focus on actually hanging out your shingle and getting started.
Now, I don’t actually think you really need a website to start. But a lot of people and most of you reading would probably disagree. “How can you start a business without a website?!”
I frankly don’t care enough to argue the point. So let’s just move on and assume that you’re going to build one, whether you need it or not.
First, The Ugly: What You’re Probably About to Do If I Don’t Stop You
Alright, let’s take inventory of where you are. Just getting started, you have no clients or case studies, no testimonials or past history of business. So all of those things are out for including in your website.
As for your services… well, app dev, right? People give you requirements and you code ’em up and deploy that code that the world may bask in its well-crafted glory. Nothing much to really say there, either?
But you can’t just say nothing…
Here It Comes: The Platitudes, Cookie-Cutter Methodologies, and Life Stories
No, saying nothing won’t fly, so you decide to talk about yourself, your approach, and your philosophies in glowing, rambling terms. Oh, and in the plural of course.
Here at DogFood Inc, we strongly believe in integrity, work ethic, customers and decency. These foundational principles infuse everything that we do!
We start by having a meeting with you where we listen to all of your needs. You can think of this as gathering your requirements. We then enter what we like to call the design phase, where we bring our unique architectural experience to bear in designing your app.
Next comes implementation, where we make sure to use all of the latest design patterns and best practices. Then comes a rigorous round of testing, and finally hand-off, where we ask you to participate in our patent-pending user acceptance test process.
You may find yourself wondering why we’re named DogFood Inc. Good question! It all started 10 years ago with our founder and CEO’s dog, Spud. You see Spud…
{blah, blah, blah}
And so because of Spud, and because we believe in the practice of “dogfooding” by building every tool we use from scratch, Dogfood Inc was born! Let us take a bite out of your software needs!
Come on. You know you were going to write something like this. At least you were before I made you all self-conscious about it.
Don’t worry, I’m sure I wrote some similar drivel when I first hung out my own shingle 10 or more years ago. Years of suffering the incumbent indignities of resumes and cover letters fill us to the brim with BS, to the extent that it keeps spewing from us even as we leave that world behind.
