[mason55]

Yeah, from the product management side this is the way to approach it. Make priorities clear and make it clear whether the important part is the date or some set of features.

If the date is what's important then start the conversation with "here's the date, can we get this all done by then? If not then what can we get done? If we can't do it all, here's the stuff that I think is important." And make sure to allow some time for people to think about things and give an honest estimate.

If the features are what's important then don't even put a real estimate on it because then that just turns into features + date which never works well. SWAG it by weeks or months and refine as you get further along.

It's basically a law that we always want t do more than we have time for, so it's important for the decision maker to be clear about which parts really matter.

[chii]

> the decision maker to be clear about which parts really matter

which is good and all, but the reason software projects have such a high failure rate is _because_ these decision makers aren't clear about which part really matter! And not to blame them solely, because it's a hard problem to know.

[jbverschoor]

100% agree. They aren’t clear because they don’t know. They might not be able to think in abstracts, or simply don’t have their priorities straight.

The same would happen with ANY other type of project.. marketing, home renovation, building an aircraft, or even baking a cake

[setr]

> And make sure to allow some time for people to think about things and give an honest estimate.

I like to tell people to give an estimate for when they can provide an estimate.. and estimate for that, if needed :)

Eventually someone knows something