Sounds like you saying that the wrong thing has indeed been built in a project where you where doing the building, but you are in a great position to blame some

Sounds like you saying that the wrong thing has indeed been built in a project where you where doing the building, but you are in a great position to blame someone else for any bad products that resulted since they asked for the wrong thing or where vague. Personally I’d say that I don’t care who’s fault it is if the product ends out bad, no one wins anything from playing the blame game, either you fix the process or you repeat the mistakes. This is why I want fast release cycles validating assumptions with end-users. Of cause there’s going to be problems in specs, don’t sit back and claim that you never had any bugs in your code ever! But the question is how do you push forwards knowing for sure that some assumptions are wrong, and that some are unneeded. Well it’s not a huge surprise, you test! Release feature incrementally with minimal work put in. Then you iterate on that. Your reviews are unit-tests for stakeholders and releases are integration tests into end-users. Doing a big waterfall product only to then stand back from a huge tire fire saying “yea, but the root problem was that the users asked for the wrong thing in the requirements”. That’s just not me.