This depends entirely on who the users are. If a fellow developer tells you something, listen to him! If someone who doesn't know what a CPU is tells you something, try to figure out what he really wants. But even then, if he tells you something simply doesn't work well for him, don't dismiss it as him not understanding your vision.
The problem with some projects (e.g. GNOME) is that they consider all feedback to be equally invalid, and the self-appointed "designers" are always right. This is the result of the Apple-inspired worship of almighty "design," and is contrary to the very idea of personal computing empowering people.
"Listen to fellow developers" can be very dangerous too. It's how you end up with programs that have menus nested 4 levels deep and thousands of options that will only be used by the developer who recommended/implemented it and a few other people (at huge cost to the other 99% of users).
Let me clarify my statement: you should of course ALSO listen to them (but you should take what is said with grain of salt and try to understand the real motives; once you understand that, you can propose other - often better - solutions).
However the real feedback comes from what is not said out loud. Users might dismiss the problems they have as their incompetence, but only you can be the judge of that. If 3 people in a row make the same mistakes, I can guarantee you it is not their incompetence you are seeing... ;) That is why observing the users is so important, much more than just listening to them.
But again it was skewed towards the people ready to take time to answser so the answser were mainly very enthusiastic which I know now doesn't represent the majority of the users
This seems like the Innovator's Dilemma as it relates to any product or service that can be used casually but also has "power users".
Power users are a mixed blessing.
Pros: they give you many ideas what to do. Often they're your best word-of-mouth evangelists.
Cons: If you take their requests too literally, they can drive the product/service into becoming something with too-narrow appeal and poor learnability. (However, if you don't listen to them, enough, they get mad and maybe you lose their evangelism, or worse it turns into anti-evangelism.)
That's the great thing about software: it can be configured to meet different needs at the same time. So tired of the "it can appeal to new users or power users" false dichotomy that drives all software toward the lowest common denominator. It's like the mindless, constant-growth dogma has spread from the stock market to software developers who care more about "market share" and mass appeal than craftsmanship and usefulness.
Although I agree it's possible (and so "dilemma" is hyperbole), in my own experience it's quite challenging to pile on the features while retaining a simpler experience for more casual users.
Realistically: The early-adopter power-users will want their new features relatively quickly. It takes significant discipline and foresight to add them in a way that won't complicate and compromise the simpler experience. Yes you can hide options, etc., but eventually the complexity can start poking through.
Of course that's just my experience as a developer and user of many programs; you may be smarter and/or luckier than me.
- not what the user wants at all
- what the user thinks they want, but so poorly described as to be impossible to implement
- what the user thinks they want, but actually doesn't
- what the user wants, but also a terrible idea that will make your thing worse for everyone else
There are ways to get useful feedback from your users, but asking them to tell you what they want is probably the worst one.