“Probably the most important lesson I learned working at Apple”
Saw an awesome little nugget of wisdom on Hacker News. DHH, from 37 signals, was explaining why the new version of Basecamp doesn’t have some features of the previous/alternate version:
“We weren’t happy with the time tracking integration in Classic. It was usable, but it wasn’t great. We want to take our time to either come up with a better built-in solution or an integration with another tool or something else.
This is a big part of why we’re keeping Basecamp Classic around for a very long time. Basecamp Next was not going to launch with all the features that Classic already has. So it’s OK that it’s not a perfect fit for all existing customers on Day 1.
The iPhone didn’t have copy’n'paste for a while, either. There’s just so much you can do for launch, if you want to ship.”
jballanc chimed in with this:
“The iPhone anecdote is such an important one. Probably the most important lesson I learned working at Apple was: people don’t remember that a feature was missing once you implement it, but they remember broken features long after you’ve fixed them.”
This is the kind of thing I have a ton of sympathy for. DHH is creating a new product the correct way: releasing a minimal (but useful) version 1.0 and beginning the iteration cycle.
To do iterative development you have to build up a thick skin for exactly this type of negative feedback.
Users will suggest obviously-good features, like time tracking or copy/paste(!), but for whatever reason it’s not going to be your highest priority. Either there are simply too many more important things to do or there’s no good way to implement the feature yet.
One impulse to this kind of legitimate feedback is to let it control you. Users are complaining! And you agree with their complaints! Quick — whip something up!
If you do that though, you’ve probably made mistake: by implementing something that’s less important than other things, or by doing a half-assed job.
There are definitely times when you have to do things like that. Sometimes your judgement is wrong and users are shouting until you listen. But most of the time you have the clearer picture — you can see what decisions will have the biggest pay off for the most users.
Apple seems to have the toughest skin of just about any company. Sometimes they even take it too far, straight into denial. “The antenna is fine — stop acting crazy!”
It’s tough to develop software in public with real users. Sometimes their feedback can be negative and correct, but you can’t do anything about it yet other than accept it gracefully.
You have to be responsive to feedback and able to stick to your guns — and know when to do which one.
