If you want to keep your customers happy, one foundation that your product
process needs is a shared understanding across your entire organization around
at what stage of development can you commit to a release date.

When sales is involved, this also translates to: at what point can the sales
team start selling a feature.

This should be something the entire organization knows and consents to, and
should be built in to the process.

It might be okay to be fuzzy with ship dates on aspirational projects, but when
people are betting revenue on a delivery date, we need to
be really confident we can deliver.

If you pick a release date before you have even understood what you are going
to deliver, you are setting yourself up for a high likelihood of failure and
disappointed customers.

Classifying Deadlines

Some deadlines are nice-to-have. They represent goals chosen
for some more or less arbitrary reason.

Some deadlines are do-or-die for external reasons.

I've seen situations where engineers don't know which are
which until rather late in the game, because there was no established way to
communicate that information.

That is, the process and tools used did not provide a canonical way to
communicate that a task had external deadline pressure, so that knowledge
existed only in out-of-band discussions. This leads to the people who know
assuming that everybody knows. The problem comes when the people who don't
know have no way to see that anything about this task is unusual.

Two bad tastes that taste worse together

Combining the previous two points: We should strive to avoid do-or-die
deadlines caused by promises made prematurely or with insufficient information.

This is partly a matter of communication between business and product teams.
This is why I get very nervous when quarterly features get announced at
all-hands meetings - I'm afraid some sales or support staff members will tell a
client or prospect that they can have something that might not even be
possible. Ultimately the solution here is a culture that discourages this from
the top down. I don't know of any shortcuts to maturity of that sort.

Tools

Tools can make things easier. If your project management tools provide you a
good way to distinguish hard deadlines from soft deadlines, use it. If
workflow is customizable, it's worth a little thinking about what's different
between tasks that have external deadlines and tasks that do not. Perhaps you
can configure slightly different workflow for the two.