Building a Side Project Team
The toughest thing about a side project is finding the time to give it the attention your future customers deserve. That’s tricky enough when it’s just you, but when forming a team, the time constraint issue is amplified. How will we find time to meet? What if certain people can contribute more time than others? In the end, all of these concerns melt away if the goals of the project are made clear at the outset.
Here, I’ll quickly walk you through our team building and how it all turned out as we near build completion on MediaBox.
Before we Started. Here are the ground rules that we set in the initial email that went out to prospective team members. Something of a project charter, if you will:
- Absolutely no formal time commitment.
- Favour building something that’s fun for us, or does some societal good, over marketability.
- Keep it simple. Avoid the analysis paralysis that can accompany trying to come up with the “next big thing”.
- Something we can build a v1 of fairly quickly, but has potential for additional iterations/features.
- Majority rules on product decisions.
App/Team Fundamentals. As we set out to build the team, the first thing we thought about was who we wanted to work with and who would be most responsive to the idea of building a new app. We knew we wanted it to be an iPhone app, but didn’t really care if the team had deep iOS development talent. Our goal was to learn something new, so it didn’t matter how good we were at the craft. We were there to get better.
Team Size. We wanted more than 2 and less than 10; anything in between would work. The goal was to have a team large enough to have a flow of creative ideas and be able to withstand having a few people drop off (more on that later). More than 10 would have been too difficult to coordinate and tough to fit on a small iOS project. Our goal was to have a team that could work closely together and share in all aspects of design, build, test and market. We settled on 5 people.
Collaboration Tools. Right away, we started collaborating on the Google apps suite: Calendar, Docs, Drive, Spreadsheet and Hangouts for some remote sessions. Product meetings were scheduled in Calendar and conducted in-person or over Hangouts. During the build phase, Github was great for source control, and also for issue tracking (private repository, of course). We also used the issue tracker to manage the product features/scope that would define the various beta releases that we tested with prospective customers.
Initial Steps. After assembling the team, the first thing we did was select a product idea. We’ll talk about product selection in a future post, but essentially we selected something we knew we could build successfully and something we felt would at least be useful to us – this meant we’d have at least 5 customers! After selecting the product idea, we completed a document that defined our product. What’s really cool is that this document still describes our product accurately some 7 months later.
Team Size Now? As we round out development on MediaBox, 7 months have passed. We find ourselves down to two active team members. Although it would have been great to have everyone along for the ride, it just wasn’t possible for everyone to commit enough time to feel that they’re helping the effort. Despite our app’s simple scope, there is still a lot of work that goes into a shipping product: design, customer testing, communication, development, testing, marketing, and landing site construction. It’s not easy to balance perfectly against professional and personal life, which is important to us. Though the team has slimmed over time, we do still feel great that our original product definition document still defines the product we’ll soon be shipping (in 4 weeks!).
Next Tuesday: “Customer-Driven Development”