When do you ignore your users?

[tel]

Quoted in Getting Real is a passage by Jef Raskin about avoiding "feature blight" (http://jef.raskincenter.org/unpublished/widgets_of_the_week....). 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?

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 → altay]

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

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

[mpc → altay]

Since most startups build server applications, this is a lot easier than it was in the days of shrink-wrap.