306. Launches and announcements¶
“Numerous improvements” leaves the reader with some arithmetic to do. How many, of what kind, and which of them changes the work? The announcement may have a perfectly good answer. It should bring that answer closer to the opening.
A launch selects from the release, explains the useful change and gives readers a way to investigate or act. A small fix can lead when it matters to this audience. A substantial feature may need a demonstration before its value becomes clear. The number of items shipped does not decide the order by itself.
Write with the confidence that comes from knowing the change well. There is room for curiosity, a concrete scene and a little pleasure in showing what the team has made. Give that pleasure an object: the comment that now carries its page number, the setting a reader no longer has to repeat, the result they can inspect.
Choose the reader's entry¶
Four questions help establish the announcement's content:
- What changed?
- What does that change let this reader do?
- What costs, conditions or disruptions affect the decision?
- What can the reader do next?
Their order depends on the task. An upgrade offer may need eligibility first. A notice about a broken workflow may need the consequence and remedy first. A feature introduction may begin with a small observation that its explanation will resolve. No fixed first-paragraph formula serves them all.
Use this fictional release packet for the examples in this chapter:
| Fact | Supplied detail |
|---|---|
| Product | A proof-review app |
| Release | Version 2.1 is available |
| New capability | Export recorded comments to a text file |
| Exported content | Each comment includes its text, proof name and page number |
| Scope | The export does not include the PDF proofs themselves |
| License | Comment export requires a paid license; the demo cannot export comments |
| Existing version 2 owners | The 2.1 update has no additional license charge |
| Version 1 owners | Upgrade price: EUR 40 |
| New buyers | New-license price: EUR 100 |
| Evidence destination | The release page includes a supplied sample comment file |
| Unknowns | Tax policy, platform requirements, installation details and downgrade behavior are not supplied |
These are invented facts for a writing exercise, not a real offer. The unknowns must be resolved wherever a finished launch artifact needs them. Do not fill them with plausible terms from another product.
Find the detail that carries the news¶
A factual opening can say:
Version 2.1 adds comment export. The text file includes each recorded comment's proof name and page number; the PDF proofs themselves are not included.
A more discursive opening can follow the exported comment:
A comment has left the app. Its location has come with it: version 2.1 exports the recorded text with the proof name and page number. The PDF proofs remain separate from the comment file.
Both explain the same change. The second begins with an ordinary object in a new setting and resolves the small question it raises. Its brief opening creates room for the longer explanation. It would lose that movement if every later sentence also arrived as a miniature announcement.
Choose for the audience. Existing users looking for release details may prefer the first version. A feature article can use the second and then show the sample file. Neither should promise that the recipient can open the proofs from a link, reply inside the text file or approve a version automatically.
The opening does not have to carry every fact. It should establish the right subject and scope, with material conditions in place before the action they govern. A short invitation to read release notes needs different detail from a button asking the reader to buy an upgrade.
Build a brief that can guide the draft¶
Record the audience, leading change, relevant consequence, evidence, material conditions and intended next action. Add known gaps while they are still visible. For the fictional version 2 audience:
Reader: A current version 2 owner who needs comments outside the app.
Lead: Version 2.1 exports comments with proof names and page numbers.
Evidence: A sample text file on the release page.
Terms: No additional license charge for version 2 owners; the PDFs are not included in the comment export.
Next action: Inspect the sample file and release details.
Unresolved: Installation and platform requirements need confirmation before a direct update instruction is published.
The brief should make a draft easier to write, not demand a separate strategy for every sentence. One well-chosen detail can connect the headline, demonstration and explanation. The sample file is especially useful here: readers can inspect the thing the announcement describes.
Keep a claim record for facts that appear on several surfaces. A source, scope, required condition and responsible reviewer are usually enough. The responsible person or role should be able to establish the fact; a name in a table is not itself evidence.
Select without concealing¶
The release notes record the changes within their stated scope. The announcement chooses the changes relevant to its audience. Link to the fuller account, and retain any limitation that affects the advertised action.
For the fictional release, the main announcement can lead with comment export. It need not list unrelated minor fixes before explaining the file. But it cannot leave “paid license required” solely in the release notes while inviting demo users to export their comments.
Choose supporting details for the questions they answer. A screenshot may show where the feature belongs; the sample file may show what leaves the app; a short note may establish eligibility. There is no compulsory three-item display.
Read the selected account beside the documentation. The order and emphasis may differ. The behavior, names, release status and conditions must agree. A feature introduced in an earlier version can help explain the current product, but it must not quietly become new in this release.
See release notes for the full technical account and web pages for the decision a launch page supports.
Write the upgrade for the actual owner¶
Version 2 and version 1 owners face different offers in the fictional packet. Their messages can begin differently without changing the release facts.
Version 2 owner: Version 2.1 adds comment export at no additional license charge for version 2 owners. Inspect the sample text file to see how each comment retains its proof name and page number.
Version 1 owner: Version 2.1 can export recorded comments with their proof names and page numbers. The upgrade from version 1 costs EUR 40. The sample file shows the result; the demo cannot export comments.
The second message gives someone a way to inspect the output without pretending that the demo can produce it. Before it becomes a purchase invitation, supply whatever further terms the actual offer requires.
Avoid treating a working older version as evidence of poor judgment. Give a reason to consider the change and an honest way to evaluate it. Equally, do not promise that the old version will keep working, that files will remain backward compatible or that a rollback is available unless those facts are established.
Disruption deserves direct language. State the changed behavior, affected version and supported remedy. If the remedy is not known, identify that gap; a reassuring sentence is not a substitute for one.
Keep improvement counts interpretable¶
A count needs a unit and a comparison. Are these distinct fixes, public release entries, affected commands or all changes since a named version? Establish the counting method before using the result.
One fix described under two headings is not automatically two improvements. Adding published totals can also double-count overlapping periods. Reconcile the underlying items and explain the baseline.
A release with a large count still needs a useful selection. The count tells readers about the scope of the work; a particular change tells them why they might care. Let each do its own job.
When a figure changes, update the relevant current surfaces together. Preserve dated historical claims as history, with their original comparison clear. Two different counts may both be valid if their baselines differ; make that difference visible rather than forcing every number to match.
Give each channel a task¶
Start from established facts and write for the surface. The artifacts may be drafted together, but their public claims need a resolved source before release.
| Surface | Useful job for the fictional release |
|---|---|
| Release notes | Define the new export, scope and limitations |
| Feature article | Follow a comment from the app into the supplied text file |
| Upgrade page | Explain the applicable price and eligibility |
| Give a relevant owner one clear route into the release | |
| Social post | Show the sample's proof name and page number with a concise explanation |
| Forum reply | Answer the reader's particular export or eligibility question |
A follow-up message should add a reason to read. It might inspect the sample, answer a recurring question or show a verified use. A calendar does not require a daily post, and a release does not become more useful through repeated “out now” messages.
A detail can recur with a changed purpose. The page number first identifies the feature, then becomes something to inspect in the sample, then answers a question about locating a comment. This gives a sequence continuity without repeating the same paragraph.
Write an email that keeps its promise¶
For the fictional version 2 audience:
Subject: Version 2.1: take comments out with their page numbers
Preheader: Comment export is included for version 2 owners; PDF proofs stay separate.
Version 2.1 exports recorded comments to a text file, with the proof name and page number beside each comment. You can inspect the supplied sample before deciding how it fits your review work.
The update has no additional license charge for version 2 owners. Comment export requires a paid license and is unavailable in the demo.
See the sample and release details
The subject identifies the change; the preheader adds scope; the body explains it and the link offers evidence. The destination must contain both things named in the label. This example does not supply a purchase or installation procedure.
Use a recognizable sender and an accurate reply route. A named person can be appropriate, as can a clearly identified team. Do not invent a personal sender or imply that replies are read where they are not.
Check subject, preheader and body in the intended clients. Truncation depends on their layout and the recipient's settings, so a fixed character limit cannot prove success. Put the identifying words where they are likely to survive and test the actual message.
Make a press release easy to use¶
Give editors a clear product identity, release status, relevant date, concrete change and route to evidence. Put the central news early. Keep conditions close to the claims they qualify so that a likely excerpt remains accurate.
A press release can use a quote when a real speaker adds a relevant view. Obtain or approve the actual words and attribution. A proposed quotation must remain marked as a proposal until that happens. Do not invent a chief executive's voice because the layout has a quote slot.
A useful quote might explain a design choice, a documented customer need or a trade-off. There is no universal twenty-word limit. Read it aloud, remove generic praise and preserve the speaker's meaning. A concise factual release without a quote is preferable to one with fabricated testimony.
End with a brief company description, contact route and relevant links. Use current approved names. Do not turn the boilerplate into a ranking the evidence cannot support.
Separate planned facts from released facts¶
Drafts may contain unresolved prices, dates, names and screenshots. Mark these where reviewers can see them. Before publication, resolve each marker, narrow the sentence or remove it.
Check the public build and live offer against the final copy. A candidate-build screenshot may be useful for an announced preview if identified correctly; it must not silently represent a different released interface.
A review can have different owners for behavior, licensing, documentation, customer permission and prose. Ask for a finding tied to a sentence or artifact: what is established, what needs correction and what remains unknown. A reviewer need not manufacture certainty to give a binary answer.
Read the channel set horizontally as well as page by page. Does the email turn an optional step into a requirement? Does the social caption lose the license condition? Does a cropped screenshot hide the version? Fix the relation, not just the isolated sentence.
Correct the claim where it reached people¶
A launch continues through replies and corrections. Investigate confusion, contradictions and unexpected interpretations rather than assuming one cause for each kind of report.
For the fictional release, a correction could say:
We wrote that the demo exports comments. That was incorrect: comment export requires a paid license. The release page provides a sample text file you can inspect without using the export feature.
Add what was corrected only after making that correction. Do not claim to have changed an email archive or notified customers while those actions are pending. An apology may be appropriate when the error caused inconvenience; it should not obscure the corrected fact.
Choose a correction route that can reach affected readers and keep the current source consistent. The remedy for a wrong purchase condition may require more than editing the current page. Record what was sent, changed and left unresolved.
Preserve the useful record¶
Archive the final artifacts with their source facts, versions, approval state and publication dates. Mark claims that will age: price, availability, support, trial terms, counts and the word new. This gives the next writer a starting point and a reason to check it.
The archive should distinguish a final draft from a sent message, and a planned correction from a completed one. Evidence of the words is not evidence of their delivery.
Practice the announcement twice¶
Use this fresh fictional packet:
- Version 3.2 of a layout app adds a view of three chosen color variants together.
- Changing a color in one variant leaves the other two unchanged.
- The update is included for version 3 owners.
- No new-license price, trial, export change or time saving is supplied.
First write a factual notice for existing version 3 owners. Then write a short feature introduction that follows one layout through the comparison. Keep the same capability and entitlement in both.
Compare two possible drafts:
Notice: Version 3.2 adds a view of three chosen color variants together. The update is included for version 3 owners. Changing a color in one variant leaves the other two unchanged.
Feature introduction: Keep the layout in view while its colors vary. Version 3.2 places three chosen variants together, so you can inspect them and change a color in one without changing the other two. The update is included for version 3 owners.
The notice leads with the change and entitlement. The introduction follows the layout into an action, giving its middle sentence room to connect the comparison and the independent edit. Neither adds a trial or a claim about the quality of the chosen colors.
On the second pass, choose the detail that deserves attention. Let the introduction move from the visible arrangement to a useful action, then stop when the change is clear. Vary the sentence shape with the thought rather than adding fragments to make it sound like a launch.
Finally, test likely excerpts: subject line, first paragraph, caption and link. Each must keep the scope of its claim. A short version may offer less information; it must not offer a different product.