I disagree. The problem started when people doing the flows and storyboards weren't informed or didn't understand the tech side. When waterfall was detailed plans written by people in the know, it was great, but only as long as the engineers (programmers) actually read the design doc. But they stopped doing that and insisted on making it up themselves as they went instead. Good product developers can establish proper blueprints, but a good product developer needs to understand both what the user does AND what the programmer does. Then they can articulate a vision and proper information architecture and functional specifications that make doing the work as simple as following a blueprint/design document. Meanwhile, Agile has become this bloated mess with dedicated roles for everything that a producer or project manager used to do, and the project manager has been reduced to someone just tracking progress instead of informed architects beholden to programmers who refuse to read the well thought out and planned design doc.

Before there was agile, there was managing complex design projects by Dubberly. https://www.dubberly.com/articles/managing-complex-design-pr...

Such a process made sure all the appropriate questions were answered up front most important, what's the actual problem you're trying to solve, not what do you THINK the problem is you're trying to solve. In part I think programmers wanted to be more than just programmers. It's like a construction worker deciding the architect doesn't know what they're doing so they have to be the ones designing the house as they build it. Which may be true if the architect is an artist and not an engineer.