Or why is usability and user experience so important for softwere developers and engineers, and how do you convince them it’s so bloody important?
This reads like a business-book, which is what it aims at. It does give a good feeling for what’s important when you develop software for people that aren’t you, especially when it comes to working through specifications (no matter who the specs are given by). Features of your software are not what is important, rather that users are able to reach their goal. So one should work goal-oriented and put in features that help users reach their goal, not put in features just because somebody thinks it’s interesting (think pointy-haired boss).
Engineering methods don’t work to solve engineering problems, because you’re blind to your own problems. A different method will probably work better. Also, it’s difficult to do both back-end and front-end design so separate both but they still have to work together. There is a conflict of interest between what the programmer wants, and what the user wants. So you don’t let a programmer referee whether a program is doing what the user wants (unless it’s something she designed for herself to use, obviously).
Bribery can work to find out what programmers are doing, but you shouldn’t have to resolve to it. On the other hand, maybe you can train some sense into them that way. Or present it together with a rational, defensible reason. In terms an engineer can understand.
Bottom line: you can listen to your users, but it’s even better to observe them. If you only listen, you’ll end up trying to sell them a 12-headed dragon.