This has happened to me a lot. I was on a team that was on one of the "most important" projects to the company. We had the CTOs daily attention. You felt important and we had a large team who worked hard to ship it in one year. It was deemed a success by the CEO and myself and many of the team members got staffed on other teams (basically the next highest priority project for the company). Some other engineers got put on legacy duty for maintaining the project. After a year, I barely heard about the project (we had so many new projects) but we still maintained it and it was still on our website. 1.5 years later, I get a p2 bug that basically shows the whole product had stopped working for 3 months due to a front end bug. I got pulled to fix the bug and worked hard to find it and fix, but at the end I was demoralized because I realized my team had wasted a year on a feature no customer cared about enough to complain until 3 months after it stopped working.
Basically, it can be really demoralizing to be product minded engineer if your organization is not. This happened in an org that heavily talked the talk about product market fit and testing, but the truth was we were checkbox driven. We just wanted the widest feature set among competitors (even if they didn't always work).
Having been in a position where I was talking a lot to users, I can assure you that they do notice. But they won't report it, just shrug and have a slightly decreasing opinion of your software.
I find that the vast majority of people are not stupid: they have learnt that trying to get things fixed is usually a waste of time. As a developer I truly understand this from when I’ve tried to get others to fix their software, and I am very good at describing problems.
Regularly I am the one that created the software problem, and if I were a better developer I would have avoided making the problem in the first place (or had ways to detect it, or easy ways for my clients to tell me).
I think I'm sensing a bit of anger in your tone, looking how you move the subject on my person.
Sorry if I offended you in any way, it was not my intention to offend anyone.
Me and my career are ok so far, if that's of some relief to you.
We are surely not working in the same area then.
Mine is as a vendor of enterprise stuff, for Big Corps.
In my place, not relying in users' proactive and qualitative feedback is a pretty decent attitude in my eyes, it tends to deploying more reliable software, thus to invoices actually collected, which finally leads to having an actual paycheck.
1. There are many extremely important features that may only be needed once or twice a year. For example I work in developing cost estimating tools. The tools I build are extremely important, but some of them may not be used for 8+ months out of the year and new bugs could go unnoticed for quite a while. Unless you are familiar with the internal processes of customers this could easily be true for your product features as well for reasons that might not make immediate sense and you wouldn't even know.
2.I would argue that being a product focused engineer requires you to go the extra mile and learn about customers business processes. Product Owners should include engineers in some meetings for use case analysis and voice of customer interviews. I also find it extremely valuable to personally provide support directly to some of the highest value customers because you will learn what you need to know in order to implement features better and requiring fewer updates/changes down the road.
As an engineer, I try pushing back to reduce the scope of a product down to a MVP that can be released earlier with analytical data monitoring its usage.
As an engineer, you can identify the features that take the most time to implement and can see about pushing back to a version 2 release. If it is a critical feature, then try to find alternative solutions that can be implemented in less time.
That way if a product is a flop, you didn't waste all your time. Even if it is a success, the MVP is often good enough and they still deprioritized the extra bells and whistles.
PM would hold a monthly sprint planning/refinement, 'senior' engineers would participate in breaking each piece of work into tiny, tiny tasks, and then split them up into streams of designer, developer, tester.
Each tiny task would take an hour-half a day and you wouldn't even necessarily be working on the same code base across tasks, just continually turning out tiny 1-3 point tasks.
That was by far the most soulless job I ever had, weeding these companies out is my number one priority when interviewing.