Come for the Ride…

Having outsourced a variety of projects on sites like GetaFreelancer, eLance and Guru, I would say we’ve gotten pretty good at picking the diamond in the ruff. Below are the top ten things that either make me laugh or make me mad when filtering pitches.

1. Blanket pitches - Copying and pasting your blanket pitch that you’ve reused for weeks is the most obvious reason why you would not get my business. For the same reason why I hang up on telemarketers, you’re filtering yourself out like SPAM. Would you expect to win a large client using a blanket pitch? Guess what, they don’t work on small businesses either. If you don’t show me the respect of reviewing my needs, don’t expect me to take more than a second reviewing your pitch.

2. Bad spelling/grammar - In this day and age where every browser and tool bar offers spell check capabilities, bad spelling and grammar really lowers your proposal by a whole notch. This isn’t necessarily a bias against off shore developers but for me, bad spelling = lack of attention to details. Do I want a freelancer who doesn’t pay attention to details? Do you?

3. Quoting w/o the details - We get a lot of project quotes and best guesstimates based on very little information. Sorry guys, but this is a curve ball. I purposely throw out the small blurb to see who would be smart enough to ask for more details and surprisingly, most don’t. I only trust programmers who asks A TON of questions because those programmers know how to work with people and more importantly, clients. Programmers that take a crumb and fabricate their own solutions without asking for additional client input will ultimately develop something that neither parties will be happy with.

4. Really REALLY long proposals - The ones who provide really REALLY long proposals are usually the ones that are violating the blanket pitch rule. With my project, I’ve specifically asked for the skills of php and mySQL. Instead of reading and replying to my needs, many of the pitches we’ve received included paragraphs of information about ASP.net and MS SQL and clients projects that used .net technologies, Java, Ruby and FLASH. Seriously? Am I talking to someone whose trying to win my business or some crazy lunatic on the street?

5. Ignoring questions - My time is pretty valuable… if I spend my time drafting questions obviously I need the answers. If I want to see 2 examples or your best work, I don’t want a list of 25 sites that are average; I want two of your best work. If I want to know if you’ve done similar projects before, ignoring those questions automatically puts you in the delete bucket. Paying attention to details is crucial! Answering questions specific to the project is even more important!

6. Talking like a robot - This is an interesting one and it’s one I’ve only seen with really technical pitches. First of all, I am a human being. I understand you guys spend a better part of your day trying to communicate with machines, but I and your other clients are humans. In your pitches, I need to know how you can satisfy my needs. I don’t need to know if you are an ISO 9001:2000 company and I certainly don’t need to know if your company was the first to get the ISO 27001 certification. First off, I don’t even know what that means or why that’s important. If anything, I assume someone at the ISO company ripped you off and told you that particular certificate was important when it’s not. Guess what, if you tell me your SSL certificate is from Verisign vs. GoDaddy I also would not care. Again, just answer my questions using laymen terms and prove to me you can communicate with humans too.

7. Changing the scope of the project - I need my website coded in old school php/mysql because that’s what I understand. If I need to make changes on the fly, I am who I want to depend on. For developers who want to come in and restart the project on a different platform, I’m sorry but you just don’t get it. Frankly, I don’t understand why you even made the bid. This isn’t me being stubborn; the same can be said for huge corporations who have existing infrastructures that can’t be changed. If you’re not good enough to work under certain guidelines, then you probably shouldn’t bid.

8. Provide bad links in the portfolio - Assuming you did everything right up to this point, having broken URL’s in the portfolio when the client wants to review you is just bad… In this case, it’s really better to have quality over quantity. Many of the portfolio links we’ve seen were unfinished projects, ugly websites or URL’s that go no where. Take a few moments every month to make sure you pick the best of the best and make sure those sites are still up. We (the clients) don’t have time to review all of your links anyway.

9. Unrated freelancers - Most of the sites that offer freelancer services have feedback ratings. If nothing else, that’s the only scale we have to go on when we use these sites. Even if you are the best freelancer in the world, if you are unrated it leaves little to be desired. Find it in your schedule to take on a couple of small projects for cheap and get yourself rated. Things will only get better for you from there.

10. Don’t follow up - I must admit, getting private messages from bidders asking for more information is the one thing that separates them from the noise. If you’re not putting your best foot forward demanding more attention, you may just never hear from me.

11. BONUS Non-U.S. numbers - Alright guys, I’m not one of those guys that think the U.S. is the center of the universe but if you want clients from the U.S., you really need to get a U.S. based number. If we don’t have an easy way to reach you, we just won’t even try. It’s great that you have skype, yahoo and gtalk but not all of us do and sometimes we do need to communicate vocally and/or send faxes. It makes sense right?

This web project has officially been in the works for over 4 months now.  It’s been my experience that whether you have a team of 1 or a team of 60, whether you have a budget of millions or zero, programming always needs padding time; and then some.

Fortunately for us, in the grand scheme of things, we are only about two weeks off from where I wanted to be.  In theory, I guess that means we still have a lot of padding time though it would be my preference not to use it.

The current plan is to be ready for testing within the next 4-6 weeks and to outsource what’s left of the tasks so we can hit that target.  Some have suggested this is a dangerous route and while I don’t disagree, I do have a clear vision and an optimistic view.  Again, programming will require some padding but hopefully with three people interviewing various teams, we will pick the right one to back us.

As with Wei, I too am reflecting more so this year than in past about how I have been changing and growing in my professional development. Personally, 2007 has been a breakout year. I’ve bought a house, a second dog and gotten engaged. All pretty big stuff. For 2008, one of my main goals is going to be a movement away from being the average grunt, trying to take on all tasks myself (and not getting them all done) to putting my efforts into finding others to help with the work and use my own expertise to ensure they are doing the job right.

In my current 9-5 job, I’m still a bit of a grunt, but in the past 4 years I’ve come across the proper development environments, the proper people at work are trained on software I’ve written and I’m moving much of my responsibilities to others who it is more appropriate to do daily tasks such as logging in shipments, reporting results and creating invoices. However, as the company grows, I’ll be put in a more managerial position and others will be in charge of what I am currently. I’ll need to delegate better. I’ll need to learn to allow people to do things their own way, yet still be able to keep track of what they do ad ensure it’s done properly with my own experiance.

So, it will take time and help from Wei and Bryan, but I know moving from doing work myself to overseeing others do it will move the site along at a more rapid pace. In the end, we’ll end up with a great product and an excellent management team.

10 years ago if you had asked, “If you could only use one word to describe yourself, what would it be?” I would have said, “perfectionist.” Granted, whether I was one or not was debatable. However, if I only had one word and I was trying to sell myself, why not be perfect?

Perfection was fine great in the old world. Press releases had to be perfect. Products have to be perfect. Corporations had to be perfect. Websites had to be perfect… everything around us apparently had one chance for a first impression and it had to be perfect.

However, things have changed…

In a society where very few people use spell checkers and everyone can publish themselves on the web, things are hardly ever perfect. In fact, people seem to find things more newsworthy and are more sympathetic when imperfection is shared with the public.

Which one do you remember more?

1. Martha Stewart day-to-day or Martha Stewart in jail?

2. What Tom’s doing with MySpace right now or how Mark Zuckerberg is f-in up yet another new Facebook feature launch?

Which one do you sympathize or care more about?

1. Superman or Clark Kent?

2. Batman or Spider-man?

The public’s fascination with screw ups and seeing how they fix themselves can itself be a marketing gimmick. There’s a reason why Facebook is always in the news and it’s not because they’re the perfect company out there. Google on the other hand… that’s questionable.

For startups, waiting for perfection can lead to its doom. This happened with my first website that was centered around college nightlife. We had a great domain name, great design and an unbelievable product for its time. I teamed up with a couple of friends and like most dorm startups, we got cranking on the code like we had dropped all our classes.

We had coded image galleries from the ground up (a year before any major image gallery platforms), message forums from the ground up (emulating vBulletin and more) and an online bartender as a cool to have feature. I remember doing data entry for the online bar, taking pictures of various shots (and drinking them); THAT was fun.

While all these neat features were great and would have made an amazing website, in my eyes they were never ready for launch because some features were always missing from my master plan or some bugs were out there waiting to crash my system. Imperfection came with the territory for self written code and for the most part, the site was simply not ready for the public.

During the development and debugging time, my technical knowledge excelled, however my business sense or lack thereof completely failed me. My team of developers and QA found bugs left and right and we were hacking the site in ways most normal users would not have done. Because we were such geeks, we were busy fixing errors or bugs that probably wouldn’t have made a big difference in the overall scheme of things. As a result, we never really launched and we were passed by other entrepreneurs at the school who simply bought a prefabricated community software, change some colors and focused on marketing the site instead of writing code. I believe they launched in a week what took us over 5 months to write up.

Waiting for perfection can be deadly and that was a rude awakening.

Now-a-days, I no longer seek the perfect launch when doing web startups and I actually cringe when I hear others looking to repeat my mistakes. Delaying the launch for a few months to get a more perfect site out there will not necessarily make your business better. A good business is a good business — a good website does not make a good business.

Perfectionists really have no place in a web startup, at least not in the early stages.  If you have one on your team, make sure you all get on the same page focusing on the launch; the tweaks can come later.

Changing languages in mid project is one of those things that’s uncomfortable to do and very uncomfortable to talk about; especially for startups. When things like this change in big organizations, something must have failed or someone must’ve gotten fired. However, neither of that has happened here.

Although ultimately it doesn’t matter what a site is coded in (unless it’s Cold Fusion), I felt our team’s grasp of the Django/Python platform wasn’t up to par with what it should be for the team to crank out the code in a reasonable speedy time. From a business perspective, our goal is to build this site using a familiar platform and to build it in the cheapest, fastest and easiest way possible. What we don’t have… is the luxury to learn as we go.

I can say from experience that intimately understanding your technical platform is key in being agile. In my last startup, we used a language I had no idea how to edit and that ultimately killed it. It wasn’t necessarily bad programming or a bad language, but the lack of personal knowledge kept the business website stale and eventually out-of-date. (Of course, everything can be fixed with more resources, but that wasn’t available.) On the flip side, this is why so many CMS systems exist today to help larger organizations manage their content; even if their team aren’t all techies.

After evaluating our team’s strengths and technical prowess, I think for us, php is a better bet. With more overall support on the php side, I feel safer knowing that help can be more easily found if needed. Also when we are ready to pull off more complicated targeting abilities, php will be the easiest to manipulate and update.