I understand the sentiment trying to be conveyed here, and I do agree that by speaking up a developer can help prevent a bad feature from being released while learning more about their product offering. However in the type of company described, where the 'natural set of responsibilities' places the developers as merely implementers of the vision created by the managment and product teams, the developers are not in a position of power at all and cannot be held responsible if a poor feature makes it to production.<p>Only in a company where developers ARE the product team and are a part of the decision making process can they trully be considered the last line of defense. In the scenario painted in the OP, the developer has not been empowered to play defense, and if they do so by not coding the feature they risk becoming unemployed.<p>I don't think you'll find a soul here that wouldn't sympathize with a developer in that position, and I definitely would not want to be placed in that kind of a situation, but it does exist and is quite the norm outside of the startup world.
"One of the main reasons all of development isn't outsourced is that it's hard to replace an in-house developer's personal investment in the business, cultural understanding, and market understanding. Additionally, communication is typically orders of magnitude more efficient."<p>That is exactly why many development jobs should be outsourced. Many developers understand little beyond writing code.
I always smile when someone tries to simulate people flow diagrams. I like the underlying notion that developers are more insightful than everyone else, but I think it is "everyone's fault" if the product turns out bad.