It's all of them. They all contribute to a system, and the system is what produces the output. You cannot lay the blame on any single part of the system without understanding the interrelationship between each part.

A developer produces some quick and dirty prototype and it ships but is a bitch to maintain. Blame the dev? Maybe. Blame the PM? Maybe. Blame sales? Maybe. There was a deadline and the dev hit it, you can't blame them for shipping when the deadline wasn't relaxed (by the PM or sales). But maybe you can blame them for giving bad estimates.

Why are the estimates bad? Do they know how to estimate? Have they collected metrics on how long problems of various size take to be completed? Has the PM? Has the head of the software division set that as a goal to understand? If not, then some teams will estimate better than others because they took the initiative. But they probably weren't given the money or time to do it, they stole that time from their customers (which isn't wrong, but it's hardly scaleable).

Is the team junior? Have you trained them? Do you have a training program in your company? Mentorship? Do you send them to conferences? Don't blame the junior devs for the failure of the business to understand and convey the importance of training to PMs and devs.

A dev who feels they have no authority to say no will always say yes, even if it's outrageous. They saw a peer get fired or demoted for saying no too many times and don't want to risk it themselves. It's the system that creates this. So create an environment where the devs can say no to requirements. Help them to understand how to present their case when saying no. Or, better, teach them to say, "Yes, but...". "Yes we can deliver that feature, but you will have to delay delivery by a month." "Yes we can deliver that feature, but you will have to pay for database training or a DBA because we don't have that competency in our group." "Yes we can deliver that feature, and hit that deadline, but only if you descope these other features." Don't make it optional, make it clear what the tradeoffs are. Sure, devs can do this now. But many feel disempowered to do so. Create the culture within the business that empowers them to make these meaningful contributions.

A company that lets sales to scope all features and decide deadlines is setting itself up for failure (failure to deliver stable, reliable products on time and in budget). A company with a too conservative dev group that says no to everything will fail in the market place (failure to deliver what customers want). It continues from there. Don't look to one group and play the blame game unless that group is overly strong/weak within the organization. At which point you need to distribute authority/responsibility better and empower people to make meaningful contributions and decisions.

Examine the system and culture, then shift it towards one that can achieve the desired goal, or change the goal if you're unwilling to change the system, or fail.