In the old days, execs would decide what to build. They would decide amongst themselves, perhaps talking to the customer a bit (if there was one).
Next, the analysts would begin the requirements analysis. They would talk to their customers to ask things like "What would you like to see feature X do?", write up ERDs and DFDs, flowcharts and such, and then come up with a huge document listing all of the requirements of the software. At no point in this phase would an engineer or even the prospective user of the software be consulted.
As an aside, UML wasn't really a thing yet, and mock-ups were rare. Information would just be crammed into an available space on the screen or perforated printout.
Next, the architects come together to decide upon technologies and the overall shape of the software. This was done in a vacuum, with no input other than the requirements document.
Next, the systems guys would decide how the rubber hits the road, injecting their requirements for the system this will run on.
Next, the programmers would implement what the previous guys had output in their documents.
Once all that was done, the testers would come in, use the software and compare to the requirements.
Then the software would be shipped to the customer.
Note that nobody lower would communicate directly with anyone higher in the waterfall.
If at any point in this process something was found to be horribly off, you would decide whether to conceal it to stay on target, or to raise an issue. Once an issue is raised, you go back up the waterfall until it reaches the person responsible for that thing, and then the documentation process adjusts as it trickles down the waterfall (this usually takes a couple of weeks) before you continue where you left off.
The main issue is the lack of communication. Those higher up rarely have any interaction with those lower down. The company has very little contact with the customer, other than to ask questions and then write requirements full of biases and assumptions. There's high pressure to stay the course and not change when the product doesn't satisfy because that would lose money. This is why the customer was asked to sign off on each phase of the waterfall (containing thousands of pages he didn't understand).
And the thing is, this worked (in the sense that software houses made money, not that customers got anything wonderful) because everybody did it.
The changes since then are not only agility (although those are huge wins). There's also MUCH better communication - keeping everyone in the loop (including the customer), observation-based analysis (watching the user actually do things in their day-to-day as an input to requirements, and a discussion springboard for innovation), a/b testing, automated testing, continuous deployment, ticketing systems, UX, etc. All the good stuff that we just take for granted now.
The "agile" manifesto was a good catalyst to modernize software engineering, but it's not an endpoint, and rigid adherence to an ideology is what caused all the mess in the first place.