First Hand Advice

Managing Your Startup With a Two-Person Team

elephant Managing Your Startup With a Two Person Team

Even I need help sometimes.

This is a guest post from Will Cole, co-founder of the social discovery service, KnowAbout.It

You’ve made the leap and are doing a startup. It’s just you and your co-founder, and you’re pushing out code on a daily basis. Fast, fast, fast. You’re well versed in the rules of agile development, have tried out 10 different feature and bug tracking tools, but you’re still falling back on email as a primary way to communicate changes to your product. And remember that bug you talked about over the phone three days ago? Yeah, that never got fixed. Here are five tips on how to organize your project without compromising too much on speed.

1- For new features, new layouts, new anything, read and memorize Ryan Singer’s Introduction to Using Patterns in Web Design. More importantly, you have to buy into why this is important. After a long conversation about a new feature immediately sketch out a design following these steps. If you’re an amazing developer (or are as lucky as I am and work with an amazing developer) sometimes you’ll get out of a meeting and the feature is ready in 20 minutes. It’s still worth going back and documenting this with design patterns after the fact. More on this in #2.

2- With only two people, feature and bug tracking software can feel like more trouble than it’s worth. There is one important reason to continue doing it: keeping good records. I like Pivotal Tracker, but there are plenty of good options that are free or affordable on almost any budget. Even if a bug was fixed 10 minutes after an email exchange, go back and write the bug up and mark it as cleared. There will come a day when that bug creeps up again and you’ll be able to flip the switch that it needs attention again. There will come a day when you want a new hire, contractor, or potential investor to see the evolution of your product. You can continue with emails and note cards, but keep these records even if it feels like a hassle now.

3 – Take testing seriously. If you don’t have a QA environment set up, you need to pick out low traffic times and test like your reputation depends on it. It does. Set up a check list for major changes to your product. With every major bug fix and enhancement, run through those same critical actions first, and then obsess over the specific change made. Don’t wing it and don’t ignore potential collateral damage. The only thing more impressive than two people pumping out an impossibly hard project, is two people pumping out an impossibly hard project that works the first time you use it.

4- If Google Analytics doesn’t include your key performance indicators, build those analytics systems in house. We couldn’t afford the email analytics packages on the market, so we built them. This initial investment of your time will pay for itself 10x over the lifespan of a project, and will be a pivotal part of your prioritization process for steps 1 and 2.

5- If a live bug is continuously being pushed down the prioritization list, consider nuking the feature all together. If it’s not important enough to get fixed after a few release cycles or weeks, just get rid of it. This is true regardless of your team size, but it matters even more when it’s just the two of you. There is no one else to pull off a project to give this attention. Your analytics and user feedback will serve as confirmation of this decision.

You’re moving so fast with two people that you’ll often feel burdened by process. Make sure you’re balancing light weight process with good documentation and some semblance of routine. This works for me. How does your two person team pull it off?