The optimization rule for systems
One of the rules of optimizing program performance is that there is no point in optimizing code that is not run very often; you optimize the performance critical code, and then move on to other work. There is a similar principle in system design and system administration: improving an area that is not a concern to people does not really excite them. To significantly improve people's lives, you have to work on something that they care about, something that is hurting them now.
An important consequence of people not caring is that they aren't willing to put up with pain to get your improvement. Since your improvement has to make their lives better (or at least no worse), dealing with your improvement has to be less of a pain than what they're feeling now.
(In fact, this crops up all over in various forms.)
One problem that bedevils boosters of new technologies is that they over-estimate the degree of pain people are feeling from the area that they're improving. Put crudely, they're so close to their area that they wind up thinking that everyone cares about it as much as they do. (A common side effect is for such people to also underestimate how much of a pain their new technology is in practice.)
Note that sysadmins are as much at risk of this as boosters of new technology; when we create bright shining solutions to some issue, it's always important to find out if the users actually care about it. Similarly, finding out what things are pains for the users is the first step in figuring out what's important to work on.