Almost by definition, startups start small. It's a classic formula for success: a small team with a big idea and everyone working hard to make something great. But in practice, a small team has its limits. Deciding what to do, and who does what, is harder than it sounds.
The upside of a small team is that it creates a useful constraint. Limited manpower gives your team focus, forcing you to concentrate on must-haves rather than nice-to-haves. Amazon's Jeff Bezos calls this his two-pizza rule: Any team that needs more than two pizzas for dinner is too big. Bezos fears the groupthink inherent in large teams. Small teams not only avoid it but also make decisions more quickly, respond faster, and have tighter feedback loops.
But for startups, being small is not a choice. Even the most tireless entrepreneurs can work only so many hours in a week. Making do with what, and whom, you have is all about tradeoffs. This has been the case at my startup, Iodine, where we're building digital tools to help consumers make data-driven decisions about their health.
Here are the main choices we've wrestled with, and how we made our decisions:
1. Which projects go first? We've learned and relearned the lesson that, with a staff of nine, we can't do everything. The mobile version we were planning on launching at the same time as the website? Back-burnered. That feature that lets users compare how medications work? Not so fast. Instead, our first launch focuses on a couple of key features for our product, in particular, one tool that filters thousands of reviews about medications by satisfaction, demographics, and other variables. Fortunately, this one thing is a big deal; the tool has been a hit with consumers.
2. What should we outsource? In theory, we could have outsourced many things, including programming, design, or business development. We could have outsourced so many tasks that we would have little left to do ourselves. There's no shortage of startups trying to service the outsourcing needs of other startups. Early on, we brought on a team to develop some content for us. But when our product team tried to integrate it, we had to redo most of the work ourselves. In the end, we settled on contracting for back-office functions--HR, payroll, accounting--that are outside our skill set and that aren't product-critical.
3. What should we automate? As a tech company, it's tempting to think computers will do the work, and we can just write code that automates manual processes. We've had some luck with this, in terms of writing scripts that have taken over some routine engineering tasks (updating data sets and pushing those updates to our Web servers). But some things that we thought were going to be easy algorithms, such as extracting specific data from thousands of documents--well, in the end, we had to just bear down and use our brains and a spreadsheet.
4. How do we best use our people? We love our code. But it has limits. We want to use humans to do tasks that only humans can do, tasks that require creativity, interpretation, and person-to-person contact. For us, this means using our staff members to contact as many of our website's users as possible, to determine if our product is meeting their needs and to solicit their feedback.
As much as we depend on outsourcers, computers, and algorithms to make a slick product, our company will live or die by a very human yardstick: how much it helps people manage their health and live their lives. That's always going to require that we use our most important resource--our own talented, passionate people.