Write the launch email first
If the announcement can't be drafted on day one, the problem isn't the copywriting. The project doesn't know what it is yet.
There’s an exercise we like to run before a project gets moving, and it costs nothing, and it fails in the most useful way an exercise can fail.
Write the launch email. The real one: the message that goes to customers, or staff, or the whole list, on the day this thing ships. Subject line included. Draft it before the wireframes, before the timeline, before anyone opens a design tool.
Most teams can’t. Not because they can’t write, but because the email demands answers the project hasn’t produced yet, and it demands them in a format that refuses vagueness: sentences a stranger has to care about. That’s the point of the whole exercise.
The skeleton
The email is maybe a hundred and fifty words, and every one of them is load-bearing. Here’s the skeleton:
Subject: You can now ____.
Starting today, ____ can ____ without ____. We built this because ____. To try it, ____.
Each blank is a decision the project has supposedly already made. Watch what happens when you try to fill them in during week one.
The subject line stalls first. “Announcing our new website” is not a subject line, it’s an admission: an announcement about the announcer, describing effort instead of change. If the honest version is “we redesigned some pages,” the project doesn’t have a point yet. It has a budget.
Then “____ can ____” exposes the audience question everyone’s been talking around. Can who, exactly? The whole customer base? A segment nobody has actually named out loud? Projects routinely reach development with three stakeholders holding three different silent answers, and the disagreement surfaces months later wearing a costume: an argument about the homepage that was never really about the homepage. The email would have surfaced that fight in week one, when it cost a conversation instead of a rebuild.
And “without ____” is the sharpest blank of all, because it forces the project to name the pain it removes. A launch email that can’t say what got easier is describing a renovation, not a release, and recipients can smell the difference in the first sentence.
No pain named, no reason to ship.
Bigger companies run a grander version of this, writing the full press release before a product gets approved. We prefer the email because it’s humbler and harder to fake. A press release can hide behind executive quotes. An email to real customers has nowhere to hide at all; it either announces a change in their life or it doesn’t.
The tuning fork
Once it exists, the draft becomes the project’s tuning fork. When a feature request shows up in week five, we hold it against the email: does it make the announcement stronger, or just longer? If two directions split the room, the one that improves the subject line wins. Scope conversations get shorter when everyone can read the hundred and fifty words the entire effort exists to make true.
The obvious objection is that it’s premature, that the project will evolve and the email will end up wrong. Sure. It’ll be wrong the way a compass heading is wrong, correctably, in plain view. We revise it when the project genuinely changes shape, and the revision is itself useful, because rewriting one paragraph forces the same clarity the original did. What the draft won’t allow is drift, the slow untracked kind, where a project mutates for months and nobody can say when it stopped being the thing everyone agreed to build.
And on launch day, the email takes ten minutes. Delete the brackets, fix the date, send. It was finished months ago. The project was just the long process of making it honest.
