You can always do less
37signals.com
37signals.com
I wonder if this was the reasoning behind 37s' storing passwords in plaintext instead of taking an extra 10 minutes to write the code to encrypt them?
Goes to show even good advice can be taken too far.
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...
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 ).
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.
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-...
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.
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 :-)
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.
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.
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.
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.
"Don’t be such a suck up Dan."
As if Carl here was just so damn annoyed that Dan beat him to "first DHH! First! Pick me for kickball!" I just picture Jan Brady as Carl: "Marsha Marsha Marsha!"
Ok enough semi entertainment by poking fun at the followers of David (since when did he start going by one name like Prince or Madonna or Quasimoto?)
I suddenly feel all fanboyish though...ech.
I couldn't have been more wrong.
I think most people do more because they figure (right or wrong) that it's a good way to compete. Not everyone wrote Rails and has a huge 'following', so they need other barriers to entry for their products.