2010: The year of the products

2009 was definitely the year of infrastructure at 37signals. We put in a lot of work behind the scenes to improve our hardware, software, and security setup. We also launched our biggest infrastructure project to date: 37signals ID. Infrastructure improvements are never over — we’ve got at least one big one brewing right now — but 2009 saw big progress on that front.

2010 is going to be the year of our products. With some of the big infrastructure projects behind us, we can focus more of our energy on improving our products. We’ve got some great ideas for new features, integrations, UI design/redesigns, streamlining common flows, etc. We have some new product ideas we may explore as well.

A new way of working

At the heart of the product renaissance is a new way of working. In the past each person at 37s has been pretty isolated. Everyone pretty much worked on their own own project. There was some overlap in a few spots, and occasionally a small team might come together to tackle something big, but most of the time it was every man for themselves.

We also had a tendency to pull people in different directions. We might ask someone to work on A, but then a few days later ask them to pitch in on project B, and then also ask them to help fix bug C. That makes settling into a focused zone really difficult.

In 2010 we’re going to change that. Here’s how:


We’re going to start working in teams.

A team is made of three people: One designer and two programmers. A system administrator will also assist the team when necessary.

To start, we will have two dedicated teams plus one slack team. The slack team is available to help either team, or take on other stuff that inevitably comes up. In March we expect to have a third team dedicated to the products.

We will also have one programmer dedicated to working with the customer support team on bug fixes and optimizations. This person will change every time teams reset (more on this below).


Each team will stay together for two months (a “term”). When two months are up, the teams split up and form again with different people. This way everyone gets to work with everyone else.

During the two month term, there will be four iterations. An iteration lasts for two weeks. An iteration can tackle one feature, a variety of smaller features, or part of a bigger feature that will require multiple iterations to complete.

Each team will be asked to work on the same product for the full iteration. So, if Team A chooses to work on Basecamp for an iteration, they’ll stay on Basecamp for those two weeks. Two teams can’t work on the same product at the same time.

If something isn’t done in two weeks, then it goes back into the pot. Another team can choose to pick it up as a future iteration, or it may just die. This encourages team to make sure they have something launchable at the end of an iteration. The goal is to push new stuff out to our customers every two weeks all year long.


Teams can pitch their own projects or choose a project from a living list we’re constantly massaging. We keep the list in Backpack. Some of the items on the list come from customer requests, others our own ideas. Some of the projects are just half-baked ideas (“Custom fields in Highrise“), while others are fully fleshed out projects complete with basic UI ready to implement. We use Backpack’s comment feature to discuss the ideas and attach files to the list items.

Projects are selected one iteration at a time. They are chosen on day one of an iteration. When the iteration over, the team will choose the project(s) for the next iteration. Once the two month term is up, the teams split, reform, and choose a new project for the next iteration. And on and on.

Projects are managed in Basecamp. We’ve set up one project per team. Each iteration gets its own to-do lists and milestones. Each team only worries about their current iteration, so when it’s done, and they pick a new one, they create new lists and milestones. At the end of the two month term we’ll have all the iterations for that team in a single Basecamp project.

An experiment

We’re excited to see how this method of working works out for us. We’re about one week in on the first team iteration, and we like what we see. Team Alpha is working on a series of improvements for Highrise, while Team Bravo is working on an entirely new project. The slack team is working on a variety of things – some for Highrise, some for the 37signals ID Launchpad – and thinking about some new stuff for Basecamp and Campfire.

Once we have a few terms behind us, we’ll report back on how it’s all working. We wish you success in 2010.

(The original inspiration for this idea came from Scott Heiferman at Meetup)