Errm, that's exactly what waterfall is. You have a big upfront specification phase (essentially your user manual from your example) followed by a design phase followed by development etc.
The problem is that users truly don't know exactly what they need, and even if they did, those requirements will change over time in response to the market changing. So by the time that you've spent months writing a spec, 50% of what you specified will not be what is actually required. Worse you've now spent months writing out of date documentation and have NO software to show for it and opportunity to start getting back any of your investment - paper specifications are not a business asset. Then you spend still more months writing code against that spec, meanwhile another 50% of the remaining correct spec is now out of date meaning that by the end of development you've actually only delivered 25% of what the customer really wants and 75% of what you've developed is wrong. And you've still not got any software into production to be returning on the investment you've made.
That's why people looked at other ways of developing software and why agile gained traction.
It's not a perfect approach, but IMHO it's the least bad approach that we've tried so far.