In almost 30 years of software engineering, I came to the conclusion years ago that most deadlines were entirely arbitrary. The business isn't going to fail if you slip a week, or frequently even six months and if it does its probably not the fault of engineering unless its so dysfunctional as to repeatably blow through its own delivery estimates. Sure there are regulatory deadlines, customer POC or delivery deadlines. But, truly hard deadlines won't pop up as "we need this done next week" unless there is something fundamentally wrong with the business/sales side. A good functioning engineering/business unit will know far in advance of those kinds of deadlines and it becomes a question of whether the existing engineering org is capable of delivering the functionality within a heavily padded schedule.

Put another way, I don't think i've ever seen a customer walk from a product because it wasn't released on a cadence, in fact many aren't actually happy about upgrades unless they are fixing a problem they have requested. And sales/POC cycles are such that frequently the customer may not actually have an alternative solution, or if they do, the chances they will switch to your product simply because you have X this year instead of next year isn't something that hinges on small factors that can be done by the engineering team in short cycles. You win because the product is better/etc and that doesn't happen overnight.

So, stressing and working endless 80 hour weeks likely is going to have the opposite effect and creates a low quality product that people are trying to get rid of because it keeps breaking.