Web 2.0: Jason Fried on Less as Competitive Advantage
I've heard a lot of of Jason Fried's (from 37 Signals) stuff before at ETech and at a Building of Basecamp seminar. But some new ideas here, and, in typical Fried style, expressed concisely, clearly, and emphatically.
Talking about "less as competitive advantage".
Traditionally, people think more is better. More may work, but it's painful, expensive, very cold-war.
Think about one-downing people, underdoing your competitors. Beating them with less is the way to beat them in this age of lightweight apps and lightweight business models. Nobody wants to use bloated, complex software but we all build in [assuming he's not including 37 signals in "we"].
Five Things You Need Less Of
1. Less money. Money used to get you hardware, which is virtually free. Used to buy software, which is essentially free. Could never buy you time or passion. Passion is what you need to build a great product. Money buys you salaries and people.
2. Less people. Scale down your product to match your team, instead of scaling team to match your product vision. Only need three people: 1 designer, 1 programmer, 1 sweeper (moves back and forth between the two roles, has business knowledge, marketing ideas, etc).
3. Less time. Force you to spend more time on the most important things. Instead of looking for more hours in the day, work less. Work 30 hours a week per person. You'll spend less time wasting more time... the more time you have, the more time you waste. You'll be forced to build better products and be more creative with your time. How do i manage that time, what do i need to cut out to manage the time i've lost?
4. Less abstractions. Building the things, learning as you go, very iterative approach. Biggest abstraction that you have in building a product is a functional spec. They are political documents, "yes documents". Build the customer experience first, have the technology fill in the back-end first. Have the interface screens be the functional spec. Nothing functional about paragraphs of text in a thick doc. Specs lead to illusions of agreement. Build, learn, and make mistakes as you go--you'll know more about what you're doing as you're doing it, instead of before you do it.
5. Less software. Less features, documentation, support, code, having to sell to people. Less stuff to explain. There are a million simple problems to solve, don't spend time figuring those problems out. Many simple problems you can cherry pick and nail and make many many people very happy.
Only thing you want more of are constraints. All of the above are constraints. With constraints, everything you do needs to matter, needs to be real.