At Ooga, where we’re building 5 separate products (with separate code bases, URL’s, business models, corporate entities, etc.) we develop in what we call Speed Teams.
A Speed Team is composed of two people: an engineer — who is responsible for programming the database, the application, and some of the front end — and a Designer — who is responsible for the look and feel of the site and most of the front end code. Each Speed Team works with me and Stan on a daily basis, and the project is held together with a simple document that lists the tasks and help us prioritize them. No Product Requirement Documents, no Marketing Requirements Documents, just talk and go. We find this gives us maximum freedom to iterate on a project as it moves along. Without a Board of Directors to hold us to a plan we might have come up with in the past, we are free to do what makes sense based on new information, new ideas, or feedback from the users without having to convince anyone, again adding flexibility.
By constantly adjusting to new information, we hope and expect that it will increase our odds of building something that works. Time will tell. In larger companies, they often have large groups of people on a project, each with a designated expertise. We don’t think this makes sense in the consumer Web space.
At our last company, Tickle, where we also were developing about 5 separate products, we got it down to 5 people per project: database, application layer, front end coder, visual designer, and product manager. This was pretty good and pretty fast, but still time consuming to manage everyone.
When you have good people, they all have an opinion, and it takes time to let everyone have a say. So at Ooga, we’ve taken it the next step, down to 2 people per project. Ideally, in the future, we will experiment with getting it down to 1 person, although finding someone who likes doing all layers is rare. (If you are one of these people, let us know.) As a website grows, we’ll add one or two more engineers, keeping the one designer. We’re not sure it gets much faster after 3 engineers + 1 designer, unless you have a business that can be easily modularized. That group of four will then tap into shared Ooga resources for customer service, IS, and revenue.
We’re confident we can grow a business to a significant size with that configuration given the right people. Some of the challenges with this Speed Team approach so far: 1) Having only two people on a team means each person must be learning constantly in several skill areas to be good enough to execute. 2) It’s pretty intense because the whole product rests on each person’s shoulders. There is no hiding. 3) Our one simple document let’s us know what to do on a weekly basis, but doesn’t yet let us break down tasks into sufficiently small chunks where we know what to do on an hourly basis, so we’re changing that.We’ll talk more about this in the future.
And right now we’re looking for people who think this sounds like their cup of tea.
2 thoughts on “Speed Teams”
i like the concept, espec during pre-launch development. however, after you roll out to users, are you also looking at any dashboard or metrics to make product decisions?
seems like at some point customer activity should overtake gut calls on what kind of decisions you’re making.
anyway, i like the emphasis on tight communication / quick iteration / less docs.
As a native Bay Arean, we don’t NEED any more advertisements for this area. Let those East Coasters start their own start-ups out there please. You folks obviously weren’t around these parts in the late 90s.
Comments are closed.