One question I have when I see articles like this is: what are the downsides of this sort of person on a team? What kind of projects should they not be involved in? When are they the wrong person for the situation?
They want to deliver a feature, and sure they want to make sure it's being used well, but they won't want to stick around to endlessly tweak it.
There are projects where there are multiple sets of 'users' who don't necessarily overlap, and you'll find someone like this championing one set to the detriment of others.
This can be awkward to imagine in the context of internet apps where there's a 'product' and people use it, but in the context of business or government applications where the customer-facing product is not merely the frontend it can be very relevant.
If you're producing software which runs on each customer's own servers, as an independent system instance, the user-stakeholders include:
* The people using it in day-to-day tasks. These are the 'Users' an internet-based application usually considers.
* The ops guys looking after those servers, who have no other power over the software system itself (but will lose their weekends when eg. the vendor-documented backup procedure turns out to be incomplete).
* Other vendors, who probably have to integrate with the system (and will curse the documentation or lack thereof).
* The customer's internal helpdesk fielding end-user queries about the system (frantically hunting through a content-free manual, if they're new to the job, or escalating without comment, if they're burned out).
* The Administration, who want reports on the behaviour and performance of the Users mentioned above (and often don't care about usability as long as the reports are pretty).
* And many other groups, with entirely different concerns.
A great many of these articles seem to either champion only the 'User' and/or refer only to systems where all other parties are internal to the company building the software.
The world still relies heavily on a lot of systems which do not conform to the Cloud ideal. It is important for any 'product-minded software engineer' to remember that, sometimes, making eg. the Ops guys' job easier will make life better for All Of The Above, even more than chasing after that shiny report Admin wants.
Of course, if you are building in the Cloud, The Above are largely your coworkers and should make all of this known to you :P
Now, as an engineer I gotta say, we need MOAR speed! :)
Also consider if you are an off-shore provider of software engineers to customers who value having remote engineers who will "just do what they are told" This sort of person is likely not going to be actualized in that kind of a situation.