I love it. Nothing I'm in conflict with, however, I really want to expand on one or two points to really tease out the cause and effects you are raising awareness of.
Software development SD vs. Product Development PD. (for want of better terms). There are significant differences that few really understand.
Two different pursuits.
SD is what we commonly find going on in Enterprises (and solution provider businesses) all over the world, particularly in outsourcers. I estimate more than x50 times more developers are doing this kind of work in the world than working in PD in the world. This means that most developers (working in software) are not directly involved in decision making about what to build. That is done for them by someone else (usually somewhere else in the same business who does not understand the nuances of building software in a sustainable way long term). This is not the case in most PD in the world (although there are sickeningly plenty of exceptions), but here the developers/engineers are directly involved in what is built (i.e. involved in discovery and market testing work).
SD is driven by "requirements" that are (as you say) assumptions made by stakeholders. Stakeholders keep changing their minds every time something is built and delivered because it is only then that they get to see and learn from the mistakes made in that process. The feedback loop is simply too slow and too wasteful to begin with. They never test their ideas before dictating them to the developers.
No such thing as requirements in PD. The things that must be done are learned from customers in market, and they come in the form of opportunities, not requirements.
Since any stakeholder dictating what to build probably does not understand the actual process of managing complexity in software, they don't respect the disciplines and practices required to be applied diligently to avoid the inevitable big-ball-of-mud monster created from the mounting technical debt that accumulates irrespective of how you build software. Only highly experienced and seasoned engineers understand the causes and effects of that, but they are seriously rare and far outnumbered by hoards of enthusiastic, highly resilient, younger and more naive rookies who could never fully appreciate cause and effect years from "their" now timeframe. To them, it's a game of attrition and stamina where they build as much as they can as fast as they can and hope something eventually sticks to the wall - that is prowess to them. They are on the program (of work) to enjoy the ride themselves - which they can exit any time and do many times until it becomes monotonous over the course of their formative years. The seasoned ones don't want to play that game anymore. It is exhausting (literally - after several burnouts and reckonings) because it rarely ever actually works, and it rarely ever pays off in the long run - no return on investment. They are into creating better and more fruitful programs (of work) that create better rides for everyone - including their customers. That is prowess to them.
Nobody wants to design something that is not appreciated by other humans that it was designed for. This is the ultimate motivation of all makers/creatives.
Technical teams led (from the front) must be led by seasoned engineers. Technical teams can be led from the back by people leaders, as long as there are technical leaders at the front (at some points in time). Some stronger technical leaders do both, as needed, at different times.
