Hacker News Reader

Comment by fgonzag | Hacker News Reader

One thing I've learned is that the user's complaint is always valid, the user's proposals seldom are.

That is to say, users know when they don't like something, but they are often wrong about why they dislike it or what is interrupting their workflow. Our job is to find and fix the root cause starting from user feedback, and fix the product in accordance to what the user is actually trying to accomplish.

This is often very hard

View on HN

What's interesting about this, is that user complaints can be suspect too. I read an anecdote recently about the American auto industry. They'd ask people about what they didn't like about the cars they bought. And they'd get all these complaints, then try to build cars based on those complaints. The problem was, many of the complaints were for things that took them out of the market for the car they bought. For instance, people who bought sports cars would complain about lack of doors, or lack of back seat, and so GM or Ford would build a car that wasn't quite a sports car, because it was too big, and it wasn't quite a sedan (for whatever reason, too sporty? whatever that means?), and so no one bought it.

I honestly don't know what the solution to this problem is, since feedback is invaluable. I guess, always be careful?

I'm suddenly reminded of the car that Homer built:

http://simpsons.wikia.com/wiki/The_Homer

I suspect there is a lesson there about using aggregate feedback, rather than listening to single individuals.

Exactly this. What I used to do is listen to the user's proposal and go build that. 80% of the time it's not the correct thing to work on. I know spend much more time talking with users about their problems/pains, and then use metrics to figure out what they are trying to do. The combination of these two + a good set of eyes will point you in the right direction. Very very hard to do, but it's at least a leap better from my previous approach.

Reply on news.ycombinator.com