Have you ever been sitting in an early project meeting when someone says, "Do we really need _______ ?" Fill in the blank here with nearly anything: two servers, a UX person on this project, user acceptance testing, an SSL certificate, etc. The point of these questions is to find ways to cut corners. Someone in the room is aiming for something like an earlier deadline or a smaller budget. Probably they're thinking about burnishing their resume or performance review.
Push back! Don't say, "well, if we really have to, we can go without this, but it introduces all these risks." The only thing the other party is going to hear is "we can go without this." And don't say, "Gee, I guess we could do X instead of Y." I get it, you're an engineer, and solving hard problems and making tradeoffs is your specialty, but let me tell you why that's the wrong reply.
In my ten years in software, I've learned that the problem with these questions is that they always lead to a bad experience for the customer. The usual things on the chopping block are quality attributes like usability, performance, testability, or security. These are also called "non-functional" requirements, which is a bad label for something so important.
You will almost never hear someone question a functional requirement. Can you imagine the looks on peoples' faces if you asked a question like, "Do we really need the new budget software to display the amount spent so far in a month?"
Therein lies the problem. Hidden beneath most of these questions is the idea that quality attributes are not customer requirements. But they totally are. Just because they can't be verified in one step ("Does the system do this? Yep. OK on to the next thing.") doesn't mean that customers don't expect them to be there. If you think about any of these things as though you were the customer, you will certainly find that not having them is a non-starter. If the system is down for the third time this month when I want to log in, I'm at least looking into your competitors' software, and, at most, you just lost my business! Goodbye!
Most software projects I've been involved with would, in fact, be better off to expand the budget and the timeframe for quality attributes. By better off, I mean that doing so would have made the project more successful. More money, more happy customers, better reviews. The reason is that quality attributes are the number one way to contribute to a great customer experience. The functional requirements are vital. They are a foregone conclusion because your products' competitors are going to be doing all of them and you need to also, but where great software companies like Apple differentiate themselves in the marketplace is in quality attributes.
So next time you're asked to consider cutting a quality attribute, don't just talk through the risks with your team. Literally say, "no." Say, "We can't go without this. Our customers expect better. They will migrate to our competitor's product if they don't have a good experience. And cutting this is exactly the kind of thing that will guarantee a bad experience. This is a non-starter."
And you'll be glad you did.