[tekomino]

The problem is that this looks good when written but bad when you have to follow it. If you look at 37 Signals products over the years they relentlessly add more and more and more while preaching less and less and less.

See disconnect? The truth is that you must always add more otherwise product goes stale. They know it but "do less" as a story sells better...

[teej]

You're missing the forest for the trees.

The heart of "do less" and "minimum viable product" isn't to do a crappy job or to have a minimalist product. The point is to relentlessly prune your feature set and relentlessly prune your features so that you're solving real problems and offering the most value per feature.

Prune your feature. If you cut two less use-cases from your feature's spec, is it still meeting user's -real- needs? Is it easier to use now because it's less complex?

Prune your featureset. Is that feature something that meets real users needs? Even an HN hero (patio11) had this issue recently when he launched a feature and had all of 2 customers use it.

Get validation. Don't answer these questions by intuition alone. Get customer feedback, hear what they are saying, and do root cause analysis on why they have those complaints. Make sure after you've launched a feature that it's actually solving customer's problems.

Tighten your feedback loop. Living in a black hole for weeks at a time lowers the chance that your feature will actually solve people's problems. Have a feature that will take weeks to build? What's the smallest subset of that feature you can launch that will tell you if it is actually solving real issues? Even if you have to launch that feature internally or to a small set of users, you need to figure out if you're on the right track as soon and as often as possible.

Do less isn't really about having less features. It's a strategy for satisfying the most customer needs for dollar. You do this by seeing a problem, proposing a solution, and building the least you can to verify that your solution is correct.

[patio11]

Teej has an excellent memory for offhand remarks on my blog, and that incident was a great example of what not to do.

Issue: Many customers email me to ask "Can I access the cards I create at home from school?", "Can I print the cards I create at home from school?", etc etc. The cards exist as files on their hard disk but a significant portion of my customers cannot reliably locate files they have saved, as evidenced by email.

Solution: I'll let them save files to the clooooooooooooud (technically, just my server, via a simple web service) and then all they have to do is open up their copy of BCC at school and, boom, there are the cards they were working on.

Why This Belly Flopped: I launched the online version of my software prior to launching this feature and my customers who had previously had problems with distributed file management took to it like ducks to something ducks like a whole lot. Additionally, the feature was an abstraction customers were not used to -- it doesn't work by hitting the Save button like every other piece of Windows/Mac software they have ever used. (By comparison, saving in the online version is so easy customers don't even realize it is happening.)

What It Cost Me: Probably 12 hours of development time to marginally increase satisfaction of 20 paying customers and add 0 sales. By way of comparison, the next major pair of features added to the software took 4.5 hours and have been used by thousands of people, and an A/B test I wrote Monday night in 15 minutes has already done more for my business.

[dhh]

This point wasn't about accumulation of features, although that's a worthy topic in itself. This is about what you need to ship this iteration, this version, that product.

Once you have something out there you'll iterate. And yes, you'll likely add more than you started with. But that's a side point.

[tekomino]

You do less, you make less. You do more, you make more (money). The only reason 37 Signals adds more, like every other successful company, is to make more. Less is just a story, more makes money.

In my company no other event generates more cash than adding and doing more in the product. No other event. It is true for any other company...

I am just getting tired of all "less" parroting :-)

[dhh]

We've found that nothing makes us more money than being drastically simpler than the competition. No single feature is mentioned more often than "simple", "no need for training", and "easy to use" as the reason for why people use our products.

We live and die by renewals. There is nothing to be gained for us by just keeping to add a bunch of stuff left and right that'll rock the foundation of simplicity. Whatever we'll pick up from the initial excitement will be wiped out by raising the barrier and getting too complex.

So less is indeed how we made a name and continue to make money.

[tekomino]

"simple", "no need for training", and "easy to use" is not the same as less. You added plenty over the years. You continue to add developers to your team. You are doing more and more. You are making it easy to use, but you are not doing less. You are not removing, you are constantly adding.

You guys are brilliant at marketing. No doubt about it. You know how to make things easy to use. No doubt about it. But you have to add more and more features just like any other successful company to stay relevant. If you do not do that you would not be growing and people would not be renewing.

[access_denied]

Do you really think people renew an 37signal-product account because they got that nice little present of cute-new-feature each month? (Hint: Maybe they use software to solve an ongoing business-problem, not to play 'diskbox.)

[megamark16]

My take on it is that they didn't wait until all of those features were completed to release a product, they hacked through the core functionality within the smallest time frame that they could. You can always "do more" later, if more is a nice to have.

[bonsaitree]

Agreed. This is a nice doctrine to follow for an alpha release or a prototype/demo to shop around for investors, but ALL software used daily in the "real-world" grows in complexity over time.

This axiom holds true in everything from cardiac pacemaker micro-code ( http://www.freepatentsonline.com/5843138.html ), space shuttle avionics ( http://tinyurl.com/475kyv ), or my favorite current example of real-world purposeful constraint, SQLite ( http://www.sqlite.org/version3.html ).

[kevinholesh]

Their products have definitely grown, but I think they've improved rather than falling victim to feature creep.

Look at what Basecamp could've become without their constant "you can always do less" mentality: http://www.microsoft.com/project/en/us/project-professional-...

[grinich]

Doing less is not about letting a product go stale. It's about focus. It's true that all of their products have evolved, but they haven't simply been piling on the features.

The value of a product is not in the number of things it can do. Products stand out by doing one thing very well.

You don't need twenty features. You only need one.