Where I've seen this problem to be the most acute, it's not because of organizational disconnect -- it's the lack of domain knowledge on the part of the programmers.
Medical software, for example, is ripe with examples of how programmers are completely clueless about clinical applications and implications of whatever they are doing. There's probably no other field where programming was misapplied as often and failed in such hilarious (and devastating) ways. For example, there's a lot of programming happening around various imaging modalities. Often you'd hear about programs that do X better than a radiologist. Only to discover that the programmers who wrote the program had no idea what radiologist was even doing.
Just at the start of COVID pandemic there were countless programs written to identify the virus in chest X-rays. A lot claimed success... while the clinical truth is that X-rays on their own cannot tell you if a patient has COVID, it's indistinguishable form pneumonia or a bunch of other things. The diagnosis must be made using labwork. Sometimes it's possible to be moderately confident relying on both X-ray and presentation, but not judging by X-ray alone.
Similarly, I had a chance to work on complicated budgeting and banking software. It was a joke how nobody knew what the hell the program was supposed to do and how the QA were driven up the wall by not being able to get reliable information from the partners about how certain aspects of the program should perform. Forget the developers, who'd at best got a written spec for their tiny fraction of the product and had no idea how it fits into the larger picture or what exactly it's supposed to do.
Sadly, a lot of programmers have this unwarranted confidence that they just need to read the problem description and they'll be able to program a solution for it. For complex problems that require a lot of expertise this, at best, results in solutions that are extremely convoluted and painful to use for the end user.