[Galxeagle]

We moved to a somewhat set release cadence and then instead of discussing timeline estimates with clients, we discussed release scoping and what was in the next release(s).

It had a helpful effect of abstracting the development team and helped shift the conversation away from button clicking towards a ‘product increment’ and all the extras it entails, but also from the customers perspective it helped engage them on a more meaningful level - prioritization of features vs the technical steps the dev team would be performing.

Then we avoided justifying timeline in favour of ‘if you wanted it for next release, we’d need to drop a/b/c or add resources x/y/z’ beyond a cursory ‘it adds some complexity with the other module’ etc.

[kqr]

Whenever this is possible, I really like this approach. It emphasises what the most immediate constraint is (capacity to perform development) and forces prioritization within that constraint, rather than trying to ignore the constraint and see what happens.

[Arubis]

This sounds closer to Shape Up/appetite over estimates. It's probably too late for OP to respond and adopt right this moment, but is a great approach going forward. I wrote up a tl;dr on this at https://dylanfitzgerald.net/blog/appetite_not_estimate/ if you're so inclined.