It’s not as dirty as it sounds, but it’s still worth getting excited about!
In Part 1 of this Two-Part Series (Freelance Fail), I talked about the process of building my first app (discussed in detail in a previous post here) and described my situation where I simply couldn’t award a freelance job on Elance for several reasons:
- The pool of candidates was not large enough;
- The skill level of candidates’ who did response was not on par with expectations; and
- The quote from the one candidate who I would’ve confidently hired was too high.
…And I blamed myself.
In this post, Part 2 of the Two-Part Series (How to Sextuple Your Qualified Freelancers), I teardown the exact job description used – showing you the changes made and lessons learned.
These changes essentially turned a failed freelance job’s prospects from 5 unqualified candidates at 10-15x over budget, to 31 pre-qualified candidates at ½ the budget (and in half the timeframe)!
How I turned this around
I want to get right into it, because there’s a lot of detail in this post that can help a ton of people.
Below is a copy of the original post, with the revised edits in track-changes. Have a look at the subtle (and not so subtle) differences and high-level summary of changes; and then read the “Lessons Learned” below that explain how, based on the initial poor responses, I used these small changes to bring this project in under budget, under timeframe, with the luxury of choosing among 31 candidates:
High-level Summary of Changes:
- I changed the job’s “headline” or title, to further refine the underlying foundation for the proposed app – which is the need for an application programming interface (API) with stock data. It was important that candidates applying had an understanding of that type of functionality (which was lacking the first time around);
- I removed the reference to the app being “feature rich”, not because it isn’t, but because that’s for the developer to determine. You don’t want someone give you a higher quote simply because of your own preconceived notion of value, if what your proposing is actually pretty straight-forward from their perspective.
- Similar to the headline, I got more specific about the experience I was seeking from a programmer;
- Previously I led with a very high-level explanation of what the app did – again, trying to reserve some of the more sensitive information for after a non-disclosure agreement (NDA) had been signed. This can backfire. A description with specific expectations on functionality is necessary for anyone who is trying to determine if they can do the work you are advertising. In generalized terms, attempt to list the features of the product or app, so expectations can be made;
- When posting your job on Elance for a project-based flat fee (preferred over hourly fee), you have to choose a price range for your project. The first time I posted this project, I undershot the cost – and the proposals reflected that, in quality and quantity. How did I come back from that, without breaking the bank? The second time around, I moved the range up, but in the body of the description, was very explicit about the project’s budget and cautioned candidates that bids above this budget would be ignored. This was the most obvious change that I believe, resulted in the biggest difference in responses. Sure it may have kept away several who may have only been slightly higher, but it kept away a ton of freelancers just tire-kicking (while also keeping my budget intact).
- I further refined the candidate’s requirements by including what I believe are the necessary skills to construct this app. The easiest way to outline these requirements is to look at the key service or functionalities of you product and rephrase them as a work-based skills.
- I removed the need for a “Hello, World!” app. The intent of this little test was to show that they can build something quick and easy, and more importantly observe how this is delivered to you, before getting into the heavy programming. But the response I was receiving verged on insulted. This may have been important several years ago, but now there are enough skilled developers out there, with decent portfolios. And the methods of delivering draft apps for you to test on your device have likely improved. You’re looking for the professional, experienced candidates, so no need to insult them if they’ve already produced handfuls of apps for other people that are selling on the App Store. They can do it.
- And the final change that I made was to emphasize my “secret code” instructions. With every outsourcing job posted, I always include a little test (usually at the end) for two reasons:
- To make sure they read the job description all the way through, and didn’t just send out a template proposal; and
- To ensure they have the ability to pay attention to minor details and follow instructions.
- I had this test in the first take, but only a couple caught it. You’re not trying to trick anyone here – you want to make it easy for them not to miss it. If you make it obvious, and they STILL don’t include your “secret” in their response, then it’s a good sign to move on to the next candidate.
Take what you can from the above noted details of changes made to the job description. There is a ton of value in those details, some that were done correctly the first time, and others that were revised the second time around.
Notwithstanding the specific revisions made the posting, the following themes sum up the larger lessons learned from going through the same process twice:
- Not receiving enough [qualified] candidates? Invite some.
- Although I initially searched for like-descriptions when first writing my job description, there were none to compare to at that time. But after having some difficulty with my pool of candidates, and before re-posting, I did another couple searches. Sure enough, I found a similar job posting on Elance, and although more of an advanced job, it had received 46 proposals. Bingo!
- I went through this group and reviewed their ratings and invited 19 specifically to bid on my new posting (7 took me up on it).
- The additional benefit of reviewing other postings, and seeing their response level, confirmed that I had under-priced my job, which likely negatively affected the quantity and quality of responses I received.
- By the time the posting closed, I had 31 qualified candidates (7 of which I personally invited), a 620% increase in candidates over the first job posting.
- Always set your budgets based on a flat-fee project, not on a per hour basis.
- Place your job within a reasonable price range (this may require some research/Google searches first). This will give you a better, more realistic understanding of your actual costs, and will in turn entice more candidates, because you’re not trying to low ball them (which many good freelancers won’t even respond to).
- Optional: Be upfront about your own budget. I felt compelled to do this for two reasons: 1. So that candidates would actually list their quoted price (not “to be determined”); and, 2. To be explicit that anything more (or wildly outside of this estimate) would not be considered. Expectations are now set.
- Even though I adjusted the budget range upward, the final bid price was still 50% LESS than the final price quoted to me during the first job posting (by less qualified candidates).
- Sometimes we get so hung up on not wanting to reveal details about a project to strangers (being wary that everyone’s out to steal our precious ideas… they’re not!), that we fail to give enough information upfront to help inform their proposal. I was guilty of this.
- Although I revealed everything after a NDA was signed & returned, I needed to provide more details around the expected functionality.
- You can do this without giving away the full details of your product and whatever makes it proprietary (e.g. your “secret sauce”) – it just takes a greater understanding of what it takes to build your product and some finesse in your writing. As with everything, this takes practice (I’m still working on it).
There is no success without failure. And although this isn’t a “failure” per se, it is a misstep that could’ve led to a much more expensive and time-consuming project than I bargained for.
One of the biggest benefits of working on your own projects is also one of the scariest – there is often no one to blame but yourself. When I’m at my day job, I try my damn hardest to do the best job that I can for my employer. If something goes awry, under my control or outside of my control, I still have a hierarchy of people who are required to take the brunt of the blame. When you’re employed by someone else, you’re somewhat insulated.
When you’re on your own, or working towards being an entrepreneur: You’re the Boss. Again, this is a terrifying realization, yet it’s also one of the most liberating aspects of taking on entrepreneurial pursuits.
Hopefully you can benefit from some of my own personal lessons learned, so that you can put those corrections into practice sooner – saving you time, money and headaches.
Quick App Update
Even though I corrected many of those missteps, there were still hiccups even with the next round, which meant additional delays. But this is normal in the hiring process.
Short-list the most qualified candidates that match your criteria and begin the negotiations.
I had four freelancers targeted, and ended up with my fourth choice (by my own ranking). And you know what? I friggin love them. The work they’ve produced to-date, their ability to communicate, and bring my vision to life, has been impressive.
Admittedly, this is a bit like counting chickens before they’ve hatched. The project is not 100% complete, so I won’t be satisfied until the final product is in the App Store and in the hands of customers. However, the draft looks and operates fantastic, and things are progressing smooth and steady.
My next to-do:
- Get that app completed, in the App Store, and Celebrate! Oh, crap – and then the REAL work begins… marketing and promotions!
- In 2015, expect to hear another update on the app (once complete).
- Depending on the end result, which is still to be determined, it may also make a great Testing the Muse case study – to detail the concept, from beginning to end: idea to testing to development to sales. To be continued…
Action you can take:
- Thinking of outsourcing a job or task? Use Elance and don’t forget to use my lessons learned above.
- Have any friends or colleagues who could use outsourcing tips? Share this blog post with them!
- And if you haven’t already, sign-up as a newsletter subscriber and automatically receive our blueprint, The Architecture of Testing the Muse, and much more! Sign-up below.