The idea of less as a competitive advantage

The idea of less as a competitive advantage

Summary: Jason Fried, founder of lightweight, Web-based applications maker 37signals,  offered his five-point formula for software development success to the audience at the Web 2.0 conference.

TOPICS: Tech Industry

jasonfried2.jpgJason Fried, founder of lightweight, Web-based applications maker 37signals,  offered his five-point formula for software development success to the audience at the Web 2.0 conference. Traditional software development is expensive, resource-intensive, and born of a Cold War mentality, Fried said. His advice is to "think about one downing, instead of one upping, and underdoing competitors"--beating them with less. 

According to Fried, in the era of lightweight apps and simple products you need less money, people, time, abstractions and software.

Fried believes that money mostly buys salaries and you only need three people--a designer, programmer and utility player, which he calls a "sweeper." The feature set should be scaled for the headcount. Having less time is also an advantage. "You spend time in unproductive meetings and overanalyzing the product. Less time forces you to spend less time on better things," Fried said.

He suggested 30 hours per week per person, which "forces you into building better products and being creative with your time." And, if you have less time, you have less time to think about abstractions, such as functional specification documents, which Fried characterized as a waste of time. "Instead, build the product and start from the user interface customer experience first; then wrap with the technology," Fried said. "The interface screens are the functional specification."

Finally, building less software means fewer features, less documentation, minimal support and less confusion in selling the product. "Less software is key to building very specific tools. There are a million simple problems to solve with less. Competitors solving complicated ones are most likely to fail," Fried said. "For Web-based software there are plenty of simple problems to pick from and you can nail."

So far, Fried has shown that the basic less is more model (although he probably puts in at least 60 hours a week) is working with his set of subscription-based products, but just wait until users or customers start requesting more features, faster time to market and competiton peaks. Small and nimble teams, and software, right-sized for the Web, can be highly efficient, but having the discipline to stay that way is really hard...

Photo Gallery: Web 2.0 Conference 2005

Topic: Tech Industry

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Minimalist

    There can surely be no doubt that minimalism has an important role to play in technology acquistion policy?

    If you are a 37 Signals customer and ask for more features, you didn't understand what you were buying in the first place.

    A minimalist ICT policy begins with the question: What do we need?

    An Office Productivity Suite purchase too often begins with the question: What's available?

    The first policy has a clear, business-based, objective. The second is actually not a policy at all, it is a way to avoid responsibility.

    Mr Fried is obviously a clear thinker.
    Stephen Wheeler
  • Agree with some of his design principles

    Fried says that design should start with the interface. I try to do that with all of my work. It's hard to do sometimes, but I try to stick with "What do you want it to do?" with my customers, and "What's the most appropriate work flow for you?".

    I agree that the functional specifications are a waste of time. I haven't seen one that got updated as a project progressed. They're a good starting point sometimes, but they're worthless once a group project gets going. There's no time to update them. The rest is just dynamic decisionmaking that hopefully is documented in some fashion as the project progresses. For example, when diagrams are produced during group meetings, I've heard that a digital camera is good. Just take a picture of the diagram before it's wiped off the whiteboard, print the picture, put it in a project scrapbook, date it, and if possible put a few notes around it to give it some context. Otherwise, get back to work.
    Mark Miller
  • And, never work for a company that has a guy to do charts & specifications.

    They generate mountains of papers that are autogenerated from programs that they don't understand how to use. They don't understand how to write programs and think some fancy software they don't understand will suddenly make them brilliant. Just walk away from this, even charging double, you will end up with a mess and spend all your time trying to convince a half witt that you met his specifications.

    So, I agree 100% with the author. Start with the user interface as a tool to get the customer to tell you how it works. Keep refining the user interface, and pretty soon you will have the design.
  • Technical Grade: A-; Marketing Grade: D

    Jason gets it right about the technical aspects of keeping it simple, but loses a lot of points on the marketing. Sure, people like simple products. But when their needs advance, they start to look for bigger and more integrated solutions, which is where marketing kicks in.

    Here are 2 rules in marketing:

    1. People like to feel they are buying something worthwhile, at a good price. That good price does not mean inexpensive, just a good value. So if they perceive the object as being simple, they will most likely associate it with smaller value.

    2. Many, many people (and organizations) like to buy the best. For these folks, simple is not enough. Why do people still buy so many technical things (operating systems, software, services) that are out there for free?

    Because they want what is perceived as the best. And read any marketing book: very few people will associate great products with inexpensive, no matter how good, because their instincts kick in and they wonder how can this be so inexpensive? Getting them over that hurdle takes a ton of effort.

    So, yes, simple is okay from a technical standpoint, but at some point your simple offerings, no matter how easy they can plug together, will simply look like a conglomerate of stuck-together things. The logical thinking required of how these simple items work together will exceed the capacity (and willingness) of the average business person.
    Paul C.
  • AJAX 2.0 is more competetive
  • Yes, Agree 100% with Article!!!

    I agree that its the small nimble web apps with "light-footprints" that will compete and survive in the future web-based business world thats coming.

    Microsoft, SAP, Oracle, PeopleSofte, IBM, and Sun could learn a thing or two about this concept, as they continue to build these monstrous, proprietary, complex, development-heavy apps that cost millions of dollars to support and customize and have huge training and dev cycles that destroy budgets and put business objectives constantly on hold.

    The problems solved with lite apps like this are exactly as the author says...small problems that are constantly growing and changing. They are also cheaper and more consumable, and thus serve the whole concept of web information anyway.

    One problem with the smaller app and SOA model is its a problem to manage, when you have hundreds of services running or exchanging data. Too much data and not enough people to service and manage. Then you have the issues of XML getting large because developers dont know how to build efficient xml. These make buying one large application better than the smaller model. Its a give and take.

    Still, the main problem is people wont adopt the technology thats already laid out to support this kind of smaller structure efficiently. All you need is a handful of small, efficient text files laid out in XML, XSLT and CSS and you have an app. You dont have to buy allot of junk from vendors to do this...just a text edior really. Thats on the simple side. It gets more involved from there. But the problem is vendors cannot make money from this scenario. They dont want to sell developers the idea that data exchange and web pages can be that simple. They want to load you down with THEIR way of doing markup and code, and thats where huge costs develop in building web apps that solve small business problems. I know, I see it everyday!

    Its the vendors that hold us back from this model today through ignorance as well. Im shocked at how few engineers know how important CSS and XHTML is to this whole idea and keep selling all this table-based html products!

    We also keep stacking all this AJAX and client-side junk for the sake of look and feel and postback circus tricks rather than for true functionality, and therefore exclude more and more people who have browsers and agents that cannot support that. XML and caching in agents and XHTML makes it so you dont need AJAX now. You just need to follow the new Web Standards.

    XML and XSLT and XHTML are the tools and specs to do this. Problem is we still have companies like Microsoft and IBM avoiding the W3C specs in their browsers and products and programs so that developers are stuck with tools like Visual Studio and .NET and JAVA tools that are still using table-based html markup and avoid correct CSS recommendations. This makes its HELL on the developers. I cannot tell you how many contractors we have hired to customize simple web portals, or how much trouble we go through gutting .NET's ASP.NET web forms because they put out such horrible html-tabled based markup and inline styles that make customizing web apps a huge timely expense and headache.

    Light web apps like this are something we all long for...with the ability to download some files to a server, install them free of prorietary database and ancient markup code and long licensing contracts. We want apps we can open up and tweak the markup or backend code and customize it the way we want using style sheets and xhtml. We want smaller databases and smaller logic sets that make changing or customizing these apps easy in the backend. We want coders to design smaller and simpler ways of accessing data so if we have to add or edit something, it takes one developer a day to do rather than 15 engineers weeks to figure out. We want code and interfaces that use style sheets rather than Microsoft's proprietary html, table-based layouts. CSS in these small web apps allows you to use a simple text editor on a handful of styles and control look-and-feel in a thousand web pages in a few seconds, rather than using tables and tables of code that has to be manually changed page by page by several designs over many days.

    Again, if these vendors will stop resisting the W3c's recommendation and get with the program and follow web standards and as well, stop designing these monstrously complex disporganized applications that take dozens of really smart people to manage, we can have a world that uses these simpler apps and have the same level of productivity.

    I bet we will see a new digital world online the next 100 years that is nothing but small consumable web apps and data packets that people pay pennies on the dollar to consume in their online exchanges of data. Vendors who continue to base their software models on these giant complicated web apps and desktop software are dinosaurs and dying on the vine. The survivors will be the guys that realize this first.

  • Less can be very competitve

    This man makes many good points. I think over the last 4 to 5 years the reality is that good consistent GUI's are not put together by a team of many but a team of few. With IDE and good design programmer productivity can be very high. Much more than even 5 years ago. This makes for a very small and productive team which becomes very competitive.