Loose notes from SXSW 2006 presentation: Jim Coudal / Jason Fried Opening Remarks (keynote).
37 Signals has rocketed into the spotlight this year both with Ruby on Rails and with the tremendously popular Basecamp, Backpack, and TaDa Lists. But Fried sounds like a heretic, defying common web startup practices. He’s against functional specs, against VC money, against lots of features, for time and money constraints.
“Less” can be a big advantage.
Do not have functional specs before you go into a project. You don’t have enough data in advance to make intelligent specs.
Don’t take VC money. The more you have, the more you think you need.
Don’t try to get big fast. Work in obscurity. If you take the VC money, you’ll never have enough. If you don’t take it, you’ve got a constraint that will work for you. Constraints are good. Less time means you’ll waste less time. Less money means you’ll find out how to do more with less. Work cheap, work off the cuff. Work from inspiration, not against the competition. You don’t need money to learn how to do anything… though you do need time. If you immerse yourself and have a real project to apply to, you’ll learn so much more so much faster than you will from any book.
You don’t have to launch tomorrow – you can launch in a year. Nothing wrong with that.
The side business is the perfect model. Don’t quit your job and get a bunch of money and a team together — do what you can in your spare time, with time and money constraints. If it grows to the point of being viable, then you can quit your job.
Make decisions when you have enough information to make them, not before. Projections are bullshit.
If you don’t waste time on shit that doesn’t matter, you’ll have a lot more time for stuff that does matter.
When hiring, don’t put out a bullet list of requirements. Don’t worry about what school they went to, or even whether they graduated. If they can do the work, what they did in the past doesn’t matter. You need motivated, passionate, and curious.
Don’t count on giving your product away, with no revenue model, thinking you may be bought out someday. That’s a lottery ticket, you can’t bank on it. If your web app is good and useful, people actually will pay a monthly fee for it.
Whenever you make a change to a product, you’re going to piss people off, even if it’s the better decision. But the vocal minority is awfully vocal. Trust your judgement, not theirs. The biggest complainers are the people using the cheapest version of the product. If you make a change in your product, let it simmer for a few days, don’t change it back immediately. Just explain your reasons and don’t freak out. If you turn features on and off, you’ll look like you don’t know what you’re doing. It’s OK to not know what you’re doing, but take care not to give that impression.
More on disdain for functional specs: They’re #1 political documents, about covering your ass, rather than about making a good product. They are illusions of agreement. Instead, 37signals builds the interface for the product first — in HTML, not Photoshop — and use that as the basis for the agreement. Words are too vague, too subject to interpretation. Adding features causes pain/cost. But adding them to the functional spec is just words, too easy to agree to. Read: “There’s nothing functional about a functional spec.”
Coudal: We have a rule: If the RFP is longer than two pages, we won’t take the project. If the company has invested that much time/energy in the proposal, they’re going to be a pain in the ass to deal with.
Coudal: “We’re making it up as we go along.” Sounds like a bad thing, but it’s the whole deal. Without that it wouldn’t be fun/interesting. We won’t take on a project from which we can’t learn.
Both acknowledge that these utopian ideas might not work for a larger company — works for 37signals, might not work for Yahoo. But at the same time, Yahoo! is probably wasting a lot of money writing RFPs.
You’re better off with more generalists than specialists.
Sometimes they write stories rather than functional specs. The story could be a scenario, which explains what the feature does.
Have you ever launched a product that actually matched the functional spec? No. There’s always modification in the process, always an FS 1.1, FS1.2… scope creep happens. Throw the spec away and build cool tools. Do it in agreement with the client of course, but on the basis of working ideas, not ideas on paper.