The majority of developers don't work in that type of environment. The "for developers, by developers" type company is where this is true, but for the rest of us, we're engaging with non-technical stakeholders who are experts in their own domain, while we are not experts in that same domain.
Yeah, my point was more about that even if you have that kind of environment, it is not as helpful as you might think.
IMO this kinda of dogfooding is a replacement for good QA and good prioritization. Things only get fixed because a developer that is also a user is annoyed is not a recipe for quality.
The software I work on is not even "for developers", it is more consumer-grade software that many within the company happen to use.
The users aren't necessarily non-technical. They just might not be software developers. E.g. if you work for a test equipment manufacturer like Keysight or Rhode & Schwarz your users are absolutely technical, usually some sort of electronics or RF engineers, but they're not software developers. There are similar sorts of technical-but-not-programmer users in quite a few domains.
