Small teams on big things (Jason Fried)

Jason is the head of 37 signals (which I’m sure will tell you has no head guy but he’s the one getting all the public exposure), this american web agency behind some super-hyped products like basecamp and backpack. These guys make ok applications but manage to create a totally insane buzz around their work. The presentation was called “Making great things with small teams” as 37 signals consists of 4 guys (2 in chicago, one in Utah and one in Denmark) serving more than 200’000 users (“People that have used our service”, so it seems we’re not talking active users…). Summary: these guys make some ordinary things using ordinary methods in a very smart, elegant and optimized way. A very common approach very well applied.

The presentation started with some unusually empty advices (at least for the averagely educated person):

  • hire the right people, you’ll do well (did I just NOT learn something here?)
  • hire happy people, they are better than unhappy people
  • hire people that you can trust, it’s better than to try to work with crooks
  • with the internet, the customer is closer. Hum, really?
  • you don’t have a problem until you have a problem. …

    Then we moved in semi-interesting territory:

  • act your size, “let the big guys be confusing”, be yourself. Eh why not
  • cut features, not release dates or budget. Not really client/contract friendly but I’m sure more educated client could function this way in the future
  • do less software. I could have put this one above. Usually you don’t do software for fun, and it’s hard to start a task saying “this time we’ll try to do less software”. I get the idea, but it’s a weird way of saying it. “Choose your development platform wisely” is what he probably meant.
  • iterate, don’t create a 12 week project but 12 one week projects
  • start with the UI, listen to the user. Seems obvious to me but you guys should LISTEN (Steve I know you’re with me on this). Design and development should happen simultaneously because both are iterative processes

    Then the better part:

  • Feel the hurt of your clients, expose yourself to their critics so you’ll feel more pressure to react. Natural in a tiny structure by the way, but people in large organizations probably lost that as the tech support guy is a buffer for clients complaints.
  • You have 3 moving parts in a project: time, money, features. Usually clients will require that the three are freezed, but that’s an aberration. You can not effectively define features at the beginning of a project. So Jason suggest you fix Time + Money and make your adjustments on the features list.

    The the nirvana part: these guys are incredible at promoting their product, and here is how they do (here you should really learn some things)

  • Feature food
    They single out features that they promote in communities that will be reactive. Jason talked about how a tiny feature (ability to export to iCal from basecamp) won them communities of mac faithfuls. Identify what people will react to (in a positive way) then feed them with the news. The community will chew your news, then spill it further creating a free and effective buzz.

  • Promote through education
    Exactly what he was doing in front of us. Get recognition for your expertise, this will eventually draw people to your products. He gave the example of the “yellow fade technique” that they invented and that people refer to. This makes their brand stronger.

  • 30 days major upgrade
    After you launch a product, launch a major update quickly. Show people you are not done, make them feel like they get extended services for the same price.

  • Be transparent
    Be honest with people. Admit when you fuck up, when you’re down.

    This entry was posted on Tuesday, June 14th, 2005 at 11:26 am and is filed under reboot. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

    • 6 Responses to “Small teams on big things (Jason Fried)”

    1. nchenga Says:
      June 14th, 2005 at 3:20 pm

      thanks for the reboot coverage

    2. nchenga Says:
      June 14th, 2005 at 3:20 pm

      thanks for the reboot coverage

    3. Andrew Says:
      June 14th, 2005 at 3:20 pm

      “do less software…. ‘Choose your development platform wisely’ is what he probably meant.”

      No, that’s not what he meant. He meant: build software that does less. Build software with four or five features, not ten or fifteen. Build software that eliminates options and flexibility, but gets the main features perfectly right.

    4. Andrew Says:
      June 14th, 2005 at 3:20 pm

      “do less software…. ‘Choose your development platform wisely’ is what he probably meant.”

      No, that’s not what he meant. He meant: build software that does less. Build software with four or five features, not ten or fifteen. Build software that eliminates options and flexibility, but gets the main features perfectly right.

    5. Laurent Says:
      June 14th, 2005 at 3:21 pm

      hum, so what’s the point here? good software has five features or less, software with more than five features is bad software? What if options and flexibility are what get “the main features perfectly right”? I don’t really get it.
      What kind of effect can an advice like “do less software” have on people? Would it actually help you on your projects Andrew?

    6. Laurent Says:
      June 14th, 2005 at 3:21 pm

      hum, so what’s the point here? good software has five features or less, software with more than five features is bad software? What if options and flexibility are what get “the main features perfectly right”? I don’t really get it.
      What kind of effect can an advice like “do less software” have on people? Would it actually help you on your projects Andrew?

    Leave a Reply