You’d think the hardest part of shipping late is the shipping part. It’s not. It’s telling people.
That feeling, the one in your stomach when you know the deadline’s slipping but you haven’t written the update yet, is the real deadline.
Delays happen. Features balloon. Dependencies crack. Engineers quit. Legal “takes a look.” Whatever the reason, the damage isn’t just the time you lose—it’s the trust you risk. And weirdly, that can be easier to preserve than most people think.
The trick? Say something. Say it early. And say it well.
Resist the urge to ghost
When things go off-track, many PMs instinctively go quiet. It’s human. You want more clarity before you speak. You want to fix it before it’s noticed. Or maybe you’re just hoping someone else brings it up first.
That hesitation is normal, but dangerous.
Silence doesn’t calm people down. It invites worst-case assumptions. Stakeholders start whispering, “Are they hiding something?” or “Do they even have a plan?”
Equally tempting is the other extreme: the over-detailed novella that includes every Jira ticket, Slack thread, and “funny thing that happened in dev.” Not helpful. Nobody needs your internal monologue—they need your message.
So what do they actually want?
- To know what changed
- Why it changed
- How it affects them
- What’s being done about it
- And when to expect the next checkpoint
That’s it. Do that, and you’re already ahead of 80% of PMs.
How a good delay update actually sounds
It’s confident. Not defensive.
It’s short. But not vague.
It owns the problem. But doesn’t over-apologise.
And—this matters—it sounds like someone is still driving the car.
You’re not just announcing a delay. You’re demonstrating that the product is still in good hands. That you’re still steering. Even if you’re steering through fog.
A 5-part structure that won’t let you down
If you’re staring at a blank doc, here’s a simple structure that works in almost any situation:
1. Situation: state where things stood
2. Impact: what’s changed and who’s affected
3. Why: share the cause (briefly, honestly)
4. Response: what you’re doing about it
5. Next step: what’s coming and when
Here’s how that might sound in real life:
Hi everyone,
We’d originally planned to release the new pricing settings by next Thursday, but we’ve run into a couple of issues that are pushing that date.
Specifically, our dependency on the internal billing API hit a snag—some undocumented behavior caused edge case failures in the sandbox environment.
Rather than ship a workaround, we’re working with the infra team to get a fix in place. That’s already underway, but it pushes our ETA back by roughly a week.
I’ll share an exact date by Friday. Thanks for bearing with us—this one caught us off guard, but we’re making sure it’s solid before launch.
Short. Clear. Human. Still in control.
A different flavour for execs
With execs, you don’t want to look reactive. You want to show you’ve thought it through.
Here’s a sharper version:
Subject: Change to release timeline – Pricing controls
Hi [Exec name],
Quick heads-up: we’re moving the release date for pricing settings by 5 business days. The root issue came from a bug in the billing API that caused integrity checks to fail in testing. Rather than ship with a risk flag, we’ve opted to hold until we have a clean fix from Infra (in progress now).
There’s no change to the customer-facing comms calendar yet. We’ll confirm final launch timing by end of week. Let me know if you’d like the root cause doc once we close this out.
Notice the tone. It’s calm. It preempts questions. It doesn’t overshare—but also doesn’t dodge.
Whatever you do, don’t pass the blame (out loud)
Here’s the thing about delay updates: the easiest way to sound insecure is to start finger-pointing. Even if it’s true. Even if it was Infra. Or Legal. Or QA. Doesn’t matter.
You can share context without sounding like you’re lobbying a complaint.
Try:
- “We’re coordinating with the X team to address it”
- “This dependency hit an unexpected issue—we’re partnering to fix it”
- “We hit a blocker in Y; we’re working through it together”
You’re telling the truth. You’re not throwing anyone under the bus. That builds trust on both sides—upward and laterally.
Timing, tone, and tact
Don’t wait for a stakeholder to ask what’s going on. If you’re close enough to suspect a delay, you’re close enough to signal it.
Early beats perfect. Especially with execs.
And about tone—sound like a person, not a bot. This isn’t a press release. You can say “snag” or “a bit of a curveball” if that’s how you talk. Just don’t bury bad news in passive voice or jargon. They’ll spot that a mile away.
One last thing
Delays suck. But handled well, they don’t have to suck trust.
Every late feature is a moment to either hide—or show your team what responsible, mature product leadership looks like. Most people don’t expect you to be perfect. But they do expect you to be clear, accountable, and calm under pressure.
That’s what this kind of communication earns you.
Not perfection. Just credibility that lasts longer than a shipping date ever will.