Outsourcing development for startups

"Should I outsource development?" is a question I get asked all the time by founders of startups, along with "when, in the growth of my company, is the right time to start outsourcing?" So I decided that over the next few weeks I'll talk to some of my colleagues and publish their advice here in my blog.

In the meantime, here are a few of my tips on outsourcing in an early-stage startup:

1. Have a CTO: If you're going to outsource some or all of the development of your product, you need to have a CTO. Or, someone on your team needs to have a technical background and play the role of an interim CTO. Someone needs to have an overall understanding of how the product is being architected, so that there is some long-term "memory" of the product inside the company. Someone also needs to be able to judge things like code quality and quality of the design. You may get lucky and work with a great firm, or you may get burned down the road because the product worked, but some bad design decisions were made because no-one had the long-view.
2. Have a product manager: It doesn't have to be a separate role - the product manager could be the same person as the CTO, or, it could be the CEO, but someone needs to play product manager. It should be someone with an aptitude for translating marketing requirements into product requirements, and an eye (and patience) for detail.
3. Have internal QA: When I was on a panel about ramping up R&D teams in startups, about half the panel disagreed. This idea came from a colleague of mine who was building a development team at a startup, and I tend to agree with him. Again, you might not have a budget for full-time QA yet, but QA should be one of the hires you make around the 10 person mark. You could have QA on the outsourced team as well, but even having one person on the team who understands how to read a test plan, and can attest to the fact that the outsourced team is doing the right things when it comes to testing will go a long way to making the project a success.
4. Spend the time (and money) reviewing contract terms: As a startup, your IP is what you're hanging your hat on, so you want to make sure that you're well protected if anything goes wrong, especially if your outsourcing partner is working partly for equity. You probably don't want your outsourcing partner owning the IP to your product should you miss a payment. There's a story around Silicon Valley about a savvy contractor who owns a good piece of a very successful product for that reason. Not that anyone had anything to complain about in that situation - everyone was made very wealthy, but no doubt the founders cringe at the percentage they've had to pay to the contractor who developed the product.
5. Work with a firm that has worked with companies your size: Maybe this sounds like a no-brainer, but I've spoken with many early stage companies who were disappointed with the results after working with a "brand-name" IT outsourcing company. As an early-stage company, you are pretty low on their priority list if you are competing for attention with customers who have multi-year contracts for 50, 100, or even 500 FTEs. Getting face-time with their CEO or executive team if there are issues with the project are slim to nil. Moreover, the larger companies tend to have established processes, which is good in most cases, but maybe not so good if you're startup with very few processes, and you're expecting your outsourcing partner to be able to turn on a dime.
6. Find a firm with Agile processes: Chances are, your product is groundbreaking or you probably wouldn't have taken the plunge to start your company in the first place. And if it's groundbreaking, chances are it's never been done before, and no-one has worked out all the details yet. Things will change. Details will be left out. Many outsourcing companies expect a BDUF (big design up front), which can be problematic if you're not sure if it will even work as you originally envision. Agile processes are better suited to next gen product development than waterfall, as they are inherently better at dealing with change and unknown.