

When do you ignore your users? - tel

Quoted in Getting Real is a passage by Jef Raskin about avoiding "feature blight" (<a href="http://jef.raskincenter.org/unpublished/widgets_of_the_week.html#anchor1152335" rel="nofollow">http://jef.raskincenter.org/unpublished/widgets_of_the_week....</a>). The passage suggests too many features is a bad thing and that the best way to avoid that pitfall is a very real and constricting deadline. My question is that once you've launched and you're able to afford a more liberal deadline, how do you keep feature blight from creeping in?<p>37 Signals was noted here recently for refusing to implement suggestions until there's a critical mass of users looking for them, but is that the "best" way to combat this issue?
======
altay
I forget who said this (Paul Buchheit, maybe?), but it made a lot of sense to
me: don't listen to your users, _watch_ your users. Figure out what they're
trying to accomplish -- via usability testing and analytics -- and use that to
inform product development.

Feature blight is a separate issue. It's good to try out lots of stuff, but
you can't just vomit out feature after feature -- you have to iterate. After
you release a feature, watch how people use it. If they're not using it, tweak
it or axe it. Features need to earn a permanent place in your app.

~~~
brlewis
It was Jakob Nielsen, but Paul Buchheit says things that apply the same
principle.

<http://www.useit.com/alertbox/20010805.html>

