Web 2.0 Day 2: Less is a competitive advantage

One of the High Order Bits presentations today resonated with me and appealed strongly to the KISS (keep it simple stupid) believer in me. Jason Fried's presentation on how to do more with less (let's set aside the old UNIX jokes about less being more for a second) perfectly stated my feelings on the benefits of being, staying and thinking small.

Jason points out that today competitors are constantly one upping each other. True enough -- take a look at how Google and Yahoo constantly try to out perform each other as an example. This cold war like mentality is painful, expensive and yields bloated software. Companies should stop outdoing each other and instead attempt to underdo each other -- beat your competition with less.

He outlines his thoughts in five points:

1. Less money: Don't write a business plan and then attempt to raise money to cover the business plan. You'll never be able to attain the goals in your business plan anyway. And raising money only gets you into debt and more people. Since hardware is cheap, and software mostly free, people tend to be the major cost for companies.
2. Less people: You need three people, no more. Don't scale the headcount to match your features -- instead scale your features down to meet your headcount of three. Have one designer, one programmer and a sweeper person who can go back and forth between the two people to provide a bridge.
3. Less time: More people also waste more time. Instead, if you work less, you will be more conscientious of how you spend your time and therefore use your little time more wisely. Overall, work less -- don't work 50 hours a week. Only work 30 hours and get everything done in that time.
4. Less abstractions: Build things, don't talk about building them. Don't write specs that will be outdated and totally unrelated to your final product. Don't create the technology and then slap a UI on it -- instead build the UI first, iterate and learn from your mistakes. Then, once the UI is done, put the actual technology behind it. Let the UI screens be the specification for your technology.
5. Less software: Create fewer features that require less documentation and therefore less support. Google is a good example here: Before they rolled out their minimalistic search page, most pages were cluttered with tons of crap. And most software is bloated with features that no one ever uses, so why create them in the first place? Solve the everyday problems first, then work on solving the harder problems later.
6. More constraints: With everything being less, you need to care about what it is you do. Putting more constraints in place will keep you focused on the most important features of your project.

Of course, Jason presented these points in rapid fire succession, therefore making more of less time. A lot of these points are pretty radical, I have to admit. But, having been part of a three person team that out engineered a 35 person team, I fully see the value of what Jason points out. His philosophy on less and therefore needing less money also makes sense for start-ups. If you need less money, chances are that you can bootstrap the company yourself without requiring VC funds. Taking on VC money gives you less control and in this one exception, less is no good.

I'll have continue pondering these points to see how I can apply them to my life.

Can you make do with less?