Hacker News new | past | comments | ask | show | jobs | submit login
You can always do less (37signals.com)
68 points by _giu on Jan 14, 2010 | hide | past | web | favorite | 28 comments



"For every 1 day estimates of a task, there’s a simpler version of that you can do in 3 hours, and an even simpler still you can do in 30 minutes. Back yourself into a corner and these versions will vividly appear before your eye. You can always do less."

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?


Ouch That's going to leave a mark!


Touché.


Evidence?



This is from May, and 37signals just made a fairly large change to their authentication system (I think its called Launchpad). Their password recovery system now works differently than described in this post, so I doubt they're still storing them plaintext (thank goodness).


Yeah, it may work differently now, but I think the point still holds. I understand that engineering's all about tradeoffs and being practical with your time, but things like plaintext passwords are unacceptable (IMHO) in even the first cut of a production system, let alone an established one with a large userbase.


Yeah, however the point stands that it proves they are willing to act this way about things that are too important to treat said way.

Goes to show even good advice can be taken too far.


As I understand it they changed how they did things in response to the linked blog post.


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...


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.


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.


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.


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 :-)


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.


"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.


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.)


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.


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 ).


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-...


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.


This was the best part of the referenced page:

"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 read "The Rails Way" and apparently he hates the moniker DHH. He prefers Heinemeier Hansson, if he's being referred to by his last name like Dawkins or Lessig or Obama, but if it's more casual or frequent, especially if it's on his blog, David works.

I suddenly feel all fanboyish though...ech.


Heh, I actually don't mind DHH in written form (let's face it, it's a long name and plenty of people can't get the spelling right). It's when people start calling me that in-person where things get a little weird.


I had heard you didn't like DHH before as well. I thought it was DHH being DHH.

I couldn't have been more wrong.


> What stops most people from doing less is the fear of failure.

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.


Old truth, but it never hurts to remind ourselves.


They're great at taking the same thing, changing a few minor things, then turning around and selling it.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: