> A lot of developers really hate committing to any kind of estimate

In development (as opposed to production) I personally fight against any commitment if it comprises the "what" as well as the "when".

You fix the date of the next release and provide me with a prioritized list of bug fixes and features to work on? Nice, let me start to work!

You think that a specific new feature could improve our sales and you let me drop anything else and call you back as soon as I have any news? Wonderful, I'm already analysing the issue in my head!

Anything else, and I'll let you know that your dreams are not likely to come true.

The iron triangle[1] is a well known model. If the "business" side insists on "engineering" breaking it, they are not serving their function.

[1]: https://en.wikipedia.org/wiki/Project_management_triangle

> lose a customer because the feature they wanted is taking too long to finish

That's sales guy talking.

From my point of view, he is not a customer! A customer is someone who buys the product we currently have ready to sell, or someone who pays for customization.

1) Have you ever worked on the business side? And no, business =/= sales.

2) Except I have seen multiple times when customers paid for customization, then jumped ship (and demanded a refund) because that same customization took too long.

Customization for a customer is an area that needs extreme care. It's very easy to accept that "one little change" to get ink on that sales contract. And at times is a reasonable thing to do. But it can lead to a number of very bad situations. Scenario A, promise too many customizations at the same time you're going to have a bad time trying to deliver on them all. This is frustrating for everyone and is often the result of poor leadership. Pushing sales and revenue targets on one side while ignoring the very real resource constraints on the other. Scenario B, customizations that are customer specific, meaning a customization that isn't likely to be used by other customers due to a quirk in that single customer's workflow to get them to sign. This leads to feature bloat and increases the maintenance burden of the product over time.

There is a reason that product owners need to be able to say, "No" and be good at managing expectations. Otherwise they end up with an unmanageable backlog, broken promises, and sometimes will scapegoat the engineering team. That isn't too say over promising doesn't happen on the engineering side of the equation. But the product owner is the individual ultimately responsible for all feature work promised.

You shouldn't take money for what you can't deliver. If enough customers ask for a customization, add that to your pipeline and you'll have some good news to share when it's ready.

> push back multiple expensive dependent non-engineering projects

If those projects have to be pushed back, the only explanation is that they were started too early.

That's nice in theory only. In the real world, dependent projects often have long lead times, which often means foregone revenue for the business because of holdups.