I think we are seeing the difference between software development and software engineering laid bare.
The distinction is similar to a property developer and a civil engineer. Both create buildings, but one does it at scale by offloading functions to known entities and prepackaged solutions, while the other understands one domain in depth.
Both are needed in any team or organization, because not every solution needs to be "engineered" (a Dockerized Redis instance without SSL or auth behind a corporate firewall may survive untouched for a decade), but sometimes you have to engineer something that withstands gale-force winds at 1000 ft height.
"250M printers compromised by Google Cloud Print" is an ugly look. It won't matter at that time that Google rescued a beloved product from being Deep-Sixed.
Public transit exposes everyone's full routes, anyway.
Metrocards can lead back to the payment card used for the purchase, and buses (which also record passenger ingress/egress) can remember all swiped Metrocards.
There are many industries where the workflow espoused in the manual IS the secret sauce, and, once replicated, can be replaced by a much cheaper product.
I agree completely. Just observing users stumbling through what you had thought was a blindingly-obvious, low-friction workflow is an eye-opener.
Sometimes, you have used your own code way too much to judge effectiveness.
Having a no-agenda meeting with users is also a great idea, but it is important to set scope on feature requests before it snowballs into a request for the moon.