Instead of asking your developers "how long would this take to do?", ask the business people, "how long can we spend on this without losing money on it?"
This changes discussions to become much more productive and informative for all parties. Often easier too!
For example, nearly every startup is losing money until they become a unicorn (and often, well after) - this doesn't imply that what their developers/ops people do all day is worth either "nothing" or "billions".
And that's just the immediate benefit. It goes beyond that to organisational learning and being able to calibrate past estimates and get better at picking high value fruit rather than just the low-hanging ones or the ones someone has a good gut feeling about.
But in my experience from organisations both small and large, new and old, is that it's actually a huge mental shift required to go from "this sounds neat let's do this" to
- How exactly do we actually think doing this will help us in the long run?
- How would we express that in dollars to be able to compare it with other things?
- How soon will we be able to tell that we were wrong?
If a precise estimation (which is what it seems like you think of) adds too much friction and internal transaction costs, make it at a different confidence level.
So in your specific example, you might go, "I can't give you the exact tipping point right now, but I'm 98 % certain it's worth more than five days. So if you end up spending four days on it and it's still not done, come back to me for a more precise estimate."
Estimations and prioritization systems are entire complex fields we could debate. I'm not trying to do that; I'm saying that asking "how long can we spend on this without losing money on it?" will not be a productive addition to most (all?) discussions with developers/product owners/executives/clients.
And note that I'm not saying you'll always know down to the cent, or even closest hundred dollar bill. Sometimes your best estimation is going to be "between zero and 999999" and that's fine. If you've determined that, you also know which of your inputs have the most uncertainly, and that might represent a blind spot of yours at an important aspect of the business.
Or it represents a fundamentally unknowable thing. But then at least you know you're staking this part of the development on a fundamentally unknowable thing. That's more than many other know.
They probably don't know. They're waiting for the dev to throw a number out so they can gut feel whether it'll work or not.
Presumably you'd want the developers "How much value can you create in time `t`", v(t), and the business people "how much money will we lose in time `t`", l(t).
And then you'll find the maximum of `v(t)-l(t)`.
The problem of course is how much communication it takes between the two groups to optimize this. And how well they can actually estimate.
"But isn't that obvious and the case for all developer time?" Try running the numbers some time in your organisation. You'll be surprised at how often things are produced at a loss.
This is not necessarily a problem, unless the management (and shareholders) only understands costs as an impediment to be pressured and reduced (which is sadly also quite common - and not necessarily false either).