It's all about what you say no to. For example, if it is something that will cause a lot of technical debt, as a developer, I push back until I get a concessio

It's all about what you say no to. For example, if it is something that will cause a lot of technical debt, as a developer, I push back until I get a concession where I have the opportunity to undo the damage afterwards. Otherwise the debt will increase stress, lower developer happiness, and potentially prevent the business from growing in the long term as developer retention becomes more difficult the longer it lasts. If you're going to ask for something unreasonable from someone with domain expertise, expect to make a concession if you want it done since that person has a high likelihood of understanding the true costs of the request. It is all too common to see developers experience burnout from 60+ hour weeks in order to attempt to meet a deadline because managers were awful at planning. I often take a more neutral stance through explaining that it would take [X] amount of time to build solid & tested pieces of functionality as designed, and then let the product managers assess the information to come to a decision to either scale back or if it is still pushed for, then push back for a concession. It doesn't have to be a Yes or No proposition, it is like bartering - you want to get to a mutual agreement so all parties are satisfied.