Code To Riches

Do you need a programming background to hire a good developer? The short answer is “no”. First, I do have a programming background and it helps. However, it’s certainly not required. 

I used to interview developers at Lockheed Martin. Before a candidate ever got a second interview, they had to pass our technical questions. It was pretty pointless. Asking conceptual programming questions didn’t tell us if he/she could actually code. Having him/her white-board pseudo-code wasn’t practical because he/she could only pseudo-code so much in an hour-long interview. The only good way determine if a developer is any good was to see him in action. 

You won’t get a feel for their quality until they actually start working on the project. But isn’t it too late by then? No, not really. As a start-up, I’ve been forced to do things differently. I’ve come to the conclusion that you gotta hire fast and fire fast. The idea is to setup one-week long milestones in your project that your developer must complete. At the end of those milestones you can re-evaluate if you want to stick with the developer. I’ll post more on how to setup these milestones later. This post is all about hiring.

So I’ve put together this post to go over the steps I took to hire my first superstar developer.

It’s all about LEVERAGE

Before I even started to hire I wanted to “leverage” as much as I could. Leverage is a short-cut. Like a lever that allows you to exert more force with less effort, the same applies to developing apps. I didn’t want to hire just any developer. I wanted to hire a developer that had already done something similar to what I needed. In this case, I wanted to leverage their previous experience and code.

If you’re developing something like Instagram, a developer who has built a photo sharing site will do a better job in a shorter period of time than a developer who is starting from scratch.  The goal is to find a developer that has already built something similar to what you need. So keep this in mind when reviewing applicants.

Step 1. - Create an account on http://oDesk.com
I use a website called oDesk.com, which is basically a listing of developers and freelancers looking for work. There is another site called elance.com which does the same thing. Signing up is free, and they got a ton of developers that are ready to build.

Step 2. - Post your job on oDesk
oDesk makes it very easy to post a job online. Once posted, candidates will begin applying for your job. Most of the info you need to fill out is basic, so I’ll just go over what isn’t as obvious.

Job Title - The easiest way to find leveraged developers is by using an example in the Job Title. For instance, let’s say we’re building a video sharing app. Your title should say something like “Need mobile app developer to build Instagram clone for videos”. A title like this will attract candidates that are familiar with how Instagram works. It should also attract candidates that are familiar with manipulating videos. 

Job Description - At this point, you don’t need to be too detailed. Just add a few more details to support your title. It’s also a good idea to prepare some pre-interview questions using Google Forms. Create a questionnaire and paste the link to the form in the description field. Candidates should be required to answer these questions. Here are some some sample questions:

• Have you ever built a video sharing site?
• If so, where can I see it?
• Are you working on any projects now?
• Are you available to chat by skype?
• How many years experience do you have as a developer?

Estimated Duration - You don’t know how long it’s going to take, so just put “More than 6 months”.

Estimated Workload - At this stage, you are just looking to build a prototype. Plan on hiring for at least 10-30 hours per week.

Feedback Score - I’ve never used this option only because I just found it. But you can set this to “At least 4.5 stars”. I personally will not hire any developer that doesn’t maintain at least 4.5 out of 5 stars.

Hours Billed on oDesk - Again, I’ve never used this option but I personally will not hire any developer that doesn’t have at least 1000 hours billed on past oDesk projects.

Step 3. - Elimination Round
Within a few hours you should start receiving applications. Review their answers on the questionnaire. Here’s what I look for:

5 Star Rating - Again, I look for developers with a 4.5 to 5 star rating. Developers are reviewed by people that have hired them in the past. Quickly eliminate anyone with less than 4.5 stars.

1000+ Hours Worked - I also look for developers that have logged at least 1000 hours with oDesk. The more hours the better. I’m not saying developers with anything less are bad. They are just unproven and I don’t want to waste time with unproven developers.

3+ Years Experience - Your first developer should have a minimum of 3 years experiencing. Building an app isn’t just throwing code together. It is about organizing the project properly, building a strong foundation, and using best practices. What your developer builds today is going to affect everything in the future. You want someone who can build a solid foundation. My opinion is that 3 years is the minimum needed to build these skills.

10+ Completed Projects - I also look for developers that have completed several projects. Their first project will be the worst. Each successive project gets better as they learn about best practices. I’d rather a developer make all the noob mistakes on previous projects than on mine. 

Step 4. - Interview
At this point you’ll need to contact each potential candidate. I generally prefer candidates that are quick to respond. You can follow-up with the pre-interview questions and have them elaborate to get a feel for them. 

At this point, I also have my mind map ready. I export it to PDF and have them review it. I use this to gauge how well they understand what I’m asking for. If they get it quickly and are on the same page then I bookmark them. Your mind-map should be the bare-minimum requirements. It should only reflect what you absolutely need for a prototype. Remove as much as you can until you can no longer remove anything else. 

Step 5. - Hire

Coming Soon!

If you got your website template ready, then it’s time to launch a 99Design contest. First, you’ll need to update your template with your own text. Take some time out to craft a message that explains why people should be interested in your project.

Next, register for a 99Designs contest. The type of contest you’ll want to start is an “Illustration”. Since you’ve already done most of the heavy lifting, a designer just needs to update all your graphics. The designer should be able to read your updated message on the template, and figure out the rest.

Include your updated template in the “design brief”. This is the part of the contest registration that asks you to upload your design documents. Zip up your files and upload it.

Once you launch your contest, don’t forget to invite designers. Go through previous contests and find the designs you like. Then visit the designer’s profile page and send him an invite to your contest. I’d send out at least 20 invites. The more the merrier.

In about 48 hours you should start seeing designs. I believe the contest will run for a few days before you need to pick a winner. You don’t need to micromanage things, but it’s a good idea to check in to 99designs once a day to see if you have any messages.

My email alerts weren’t coming to me.

So pick your winner and get that sucker hosted! Just hit me up when you cross that bridget and we’ll go over it.

Being in a room full of like-minded people can be awe inspiring. 

I just got back from the Tech Cocktail Mixer (Tech.co). The Mixer showcases a handful of startups in the DC metro area. It’s a little bit of both networking and spotlighting. Traditionally, the startup scene was more of a west coast thing. But Tech.co is spreading the action across the nation. DC tech startups like me have a lot to be thankful for because of these guys. I love what they are doing, and will make a conscious effort to support their cause.

Full disclosure: I didn’t always feel this way about networking events. I appalled the idea of networking and felt social-networking was all I needed. Old-school networking was inefficient and boring. Truth be told, I was simply reluctant to get out of my comfort zone.

But NOT any more.  And here is why they are so important

Reason #1 - It Refines Your Startup: I love how I can walk up to a complete stranger and bounce ideas off them. They critique me, I critique them, and meaningful conversation ensues. What I got in 90 minutes last night equated to about six months of gathering feedback on my own. You’ll learn about competing products that you never knew existed. You’ll see flaws. You’ll even get new ideas on how to improve. Use the crowd to refine what you’re already doing.

Reason #2 - It Exposes New Opportunities: Networking isn’t solely about gathering leads or making a sale. It’s about exploring new opportunities. There are so many different types of people in the crowd all looking to make something big happen. There are people with ideas that don’t know how to build. There are people that know how to build, but don’t have the idea. And there are people that don’t have either, but want to invest in people that do. Figure out who you can connect with to expose new opportunities.

Reason #3 - It Can Change Your Perspective: For me, this is the most important reason of them all. I walked out of the last two Tech.co events with a whole new perspective on what I want for my startup. Up until a few weeks ago, I always thought that a successful startup meant:

1. Build something
2. Make it run on its own
3. Generate predictable recurring revenue
4. Chillax on a beach 

I’ll say it again, Being in a room full of like-minded people is awe inspiring. The 90 minutes I spent at the Tech.co Mixer has forever changed the way I look at my business. If you believe you are onto something big with your startup, an event like the Mixer can help you take things to the next level. So don’t miss the next one.

In a previous post I discussed getting your app out of your head and into something more tangible like a mind map. This not only let’s you clearly see what direction you’re going in, but will also help your developer and designer understand what you need.

I recently received a mind map from a friend of mine (Hans), who wants to build an app using the CodeToRiches methodology. He’s a proud parent of 3 young athletes, and struggles to keep mom and kids on the same page when it comes to soccer schedules. He wants to build an app to solve this dilemma. Here is a draft of his mind map.

The above is a good start, and it’s enough for a designer to come up with a logo, illustration, and even web page. But it lacks the details that a developer will need to begin coding. So we’ll revisit how to add the necessary details for development in a later post.

I believe that before you have a product to sell, it’s a good idea to start marketing it. Fake it till you make it. I’m not saying you should be deceptive. What I am saying is that you should figure out if anyone is actually going to buy your app before you blow a ton of time and effort on it.

At the very least, you’ll want a web page. You don’t need the whole shebang. All you need is a single web page called a Landing Page that does 2 important things.

Elevator Pitch: First, you want to explain what your app does. This is your elevator pitch. In 2-3 sentences what problem are you solving?

Get Pre-Sales: Second, you want to start collecting potential customers. Obviously, you don’t have anything to sell yet, but that doesn’t mean you can’t start collecting their email addresses. Setup a sign-up form where visitors can leave their email address so you can update them when your app is ready. If people start signing up, you know you are onto something.

Here is an example taken from Meemstream.com.

My buddy is not a designer, and more importantly he doesn’t know the first thing about building web pages. So here is my ultra-secret tip on how to get the above done for super-cheap.

1. Register your domain name at Godaddy.com for about $10
2. Register for a free MailChimp account. This is what you’ll use to collect emails.
3. Visit ThemeForest and go to the search box and type “Landing Page”.  For about $10 you can get a landing page template. This is a template that you will customize with your own content. Purchase one that fits your app.
4. Download the template and unzip it.
5. Find the file called “index.html” or something similar and drag into a browser. This will let you preview it. 
6. Make notes on the images you want to replace
7. Replace the text using a free editor like Notepad++
8. Visit 99Designs and launch a contest for an Illustration ($199). In the design brief, upload your template and the notes you made about the images you want to replace. The designers will create images to replace what came with the template.
9. Wait a couple days to see what designers come up with
10. Pick your winner
11. Publish the revised template to a web host like Godaddy (free with your domain purchase). We’ll go over this later in more detail.

So the idea is to build awareness and gather feedback about your app before you actually build it. And you want to do this without breaking the bank. When Hans goes to the next soccer game, he can pitch his idea and back it up with a Landing Page that makes things crystal clear for his target audience.

Keep in mind that your Landing Page isn’t set in stone. You can always change it later or go with something more customized. But for now, you just want to get your idea out there to see if anyone will actually buy it.

I learned this lesson from the School of Hard Knocks. I’m fortunate that I recognized the problem early, which has forever changed the way I make decisions regarding business.

Some guys don’t realize this until it’s too late (60+ years old etc). Some justify it by having a passion for what they do. In my case, I just don’t want to work forever. I have an extreme passion for everything I do. But it’s not practical to think you can do it forever.

How I made the transition from “Working In My Business” to “Working On My Business”. (~5min)

If you are past the start-up phase and can’t imagine getting out of it, download the E-Myth audiobook by Michael Gerber. I’d tell you to read it, but we all know entrepreneurs are never idle enough to read :)

Last night I attended Tech Cocktail’s Sessions July 2012 event. I met several entrepreneurs. Most were in their start-up phase, and were looking for ways to go from idea to product. So naturally, the first thing we each did during our intros was give our elevator pitches.

I had a hard time understanding what exactly these people did. The elevator pitches were raw and I found my attention wandering elsewhere after the first minute or so. Here are the problems I observed.

• People were too eager to show me how their “thing” worked, without first telling me what problem they were trying to solve.
• Pitches were too long. I clocked about 5 minutes with one gentleman and still didn’t quite get it.
• Pitches didn’t make sense.

I’m personally guilty of all of the above. But I have tightened up my own pitch, and still revise it all the time. Here are some things I’ve done to improve my own pitch. Maybe it will help you.

• Tailor your pitch to the person you are speaking to. Whoever you are pitching to either has a little knowledge about your industry, or has absolutely no knowledge about it all. Find out which category the person fits in, then pitch from there.
• State the problem first. What are you trying to solve? Then explain your solution. It’s much easier to understand the “how-it-works” part once I understand your mission.
• Keep your pitch under a minute. 30 seconds is even better. It really felt like most of the pitches were free-styled. I started to lose interest if I don’t get it quickly. I figure most people are the same way.

I’m going to use my cousin’s app Prospectsnap.com as a case study for this. Last night, co-founder and CEO, Andrew found himself pitching his idea several times to several different people. His pitch goes a little like this this:

“Prospectsnap allows you to add email leads to your list while you are networking.”

Lets identify the problems:

Problem #1 - Depending on who you are, you might not know what an “email lead” is. This pitch is tailored for email marketers, and I’d continue using it for email marketers. But what if your pitching it to attendees at a start-up event? It’s a mistake to assume that they are all email marketers.

Problem #2 - You are telling people how it works without explaining what the problem is. If I didn’t know any better my reply to him would be “why do I need to do that?” The result is that I’m just going to start nodding my head up and down like I know what you’re talking about, but I really don’t.

Problem #3 - The pitch generally took 2-3 minutes before the audience went “Ah, I get it”. The guy being pitched usually had several follow on questions before understanding the big picture.

Solution - This alternative pitch addresses all three problems. “You ever say good-bye to someone, and cross your fingers that they’re ever going to call you back? Well, Prospectsnap makes it 7x more likely that they will.”

Bam. I get it, the email marketer gets it, the guy that’s never heard of email marketing get’s it. This set’s the stage for some more meaningful conversation. Now the audience doesn’t have to wonder what you do. They just want to know how you do it. And the “how” part is generally easier to explain.

I’ve received my 5th version of the app, and overall I’m very happy. However, within the first 10 minutes of testing I found 21 bugs. Most were minor. My initial reaction is that I’m super annoyed. I’m thinking “How could this guy not catch these obvious bugs on his own?”

Well, in the past I’ve been pretty mean about dealing with bugs and the developer responsible for them. I’d say to them “How could you have missed this?”. But this is the wrong way to deal with bugs. I realize that the developer is working hard. He hardly sleeps and is always responsive when I ask him questions. I’ve been guilty of these types of bugs as well. 

It’s not that the developer is careless or dumb. Instead, when you’re coding up a storm you start to see the app much differently than a first-time user. Typically, the developer is hitting the same sequence of buttons over and over again while he’s working on something. He/she could spend hours on this same sequence of button clicking. Eventually, that sequence of button clicks is polished and the assumption is that it works perfectly.

Well, as soon as someone else tries the app out, they go through an entirely different sequence of button clicking. The result is several bugs since the developer didn’t spend much time on that alternative series of button clicking.

In any event, this time around I didn’t lash out at the developer. I simply documented all the bugs I found and sent him an email.  Also, developers hate to test…at least I hate testing. To be honest, you don’t want your developer to be your tester either. The two should have completely different views on the app. It’s the only way you get good coverage over the quality of the app.

If you are on a budget, you should assume the role of the tester. Let the developer do his thing, anticipate bugs, and just document them without making assumptions if the bug should have trickled down to you or not.

I typically use a ticket tracking system to manage bugs. I personally use Mhelpdesk to manage all bugs and my team. But if you don’t have access to a ticket system, you can still track issues using Google Docs.

A simple list of bugs.

Provide screenshots when possible. To take a screenshot on your iPhone, press the top Power button and your Home button at the same time. Email it to yourself and write notes on top of it using something like SnagIt.

Sample of a bug I documented with screenshots

Your goal is to help the developer quickly reproduce the bug. If you are vague you are going to waste both time and money. Your developer can take 2 minutes to understand the bug, or he can take an hour. It’s your job to help him under how to reproduce it in 2 minutes.

Quick tips:

1. Explain what is wrong
2. Explain what the desired behavior should be
3. In step-by-step fashion, give him the exact steps to reproduce the bugs. Don’t just say “It doesn’t work when I press this.”