I think everyone can agree that happy users are the goal (if you're a service provider, or a goal if you sell software), and that we sometimes need to remind ourselves of that. But it's usually a little more complicated than having a can-do attitude (although that's probably going to be a non-trivial part of any successful relationship). I liked Frank's analysis, particulary this bit:

I've worked on that project as a developer, and it limped along for almost two years with three or four developers before finally being killed off. Not fun.

So my approach is more like this: Don't ask users what they want, figure out what they're trying to do and then tell them what they want. It's not as glib as it sounds, because if you really make an effort to learn their processes and make their goals your goals, it builds a level of trust that makes it a lot easier for you to make sound technical reccomendations and have them listened to. Of course that's hard, and it gets a lot harder if the customer is not sufficiently engaged in the project, but it ultimately takes two to Tango.