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.
I'm working on b2b software and when working with the designers at http://fairpixels.pro I've learned many things from their approach as to why (a lot of) software sucks. Personal example: I've been measuring qualitative feedback users have been giving us and passing it to them to make design updates. They (design team) would come back with me with questions about data & metrics. They were more interested in what the users DID vs what they told me. This sounds small, but has made a huge difference in the way I look at product design & development. The things users told us in a few cases, didn't match the way they were acting in the product. After some research, we found out why and managed to redesign those features and solve the problems.
The thing with most software, just like ours, is that many of us engineers don't have the deeper design knowledge to really understand how a product needs to be build from a user's perspective.