A launch evidence sweep turns the product’s changelog, screenshots, documentation, and customer language into a source pack before anyone drafts content. Done at 9 p.m. the night before launch week, it gives every post, article, email, and video a defensible claim to build on.
In April 1970, carbon dioxide was rising inside Apollo 13’s lunar module while the damaged spacecraft was still far from Earth. The command module carried square lithium hydroxide canisters, but the lunar module’s system used round ones. NASA’s team in Houston needed an adapter the astronauts could assemble from materials already aboard.
Engineer Ed Smylie and his colleagues worked with the same limited set of items available to the crew. They developed a procedure using materials that included plastic bags, cardboard, a hose, and duct tape. Mission Control then relayed the instructions to astronauts Jim Lovell, Jack Swigert, and Fred Haise. The improvised system reduced the carbon dioxide level. Jim Lovell and Jeffrey Kluger document the episode in Lost Moon.
The useful lesson for a product launch concerns evidence. The Houston team could only design a workable procedure because it knew what the crew actually had. Your launch content faces a quieter version of the same constraint. Claims become credible when writers know which product changes, screens, documents, and customer words are genuinely available.
Build the source pack before opening a draft
At 9 p.m., resist the blank document. Start with the product.
Pull the changelog entries tied to this release. Separate shipped behavior from planned work, experiments, and features still behind approval or provider limits. A line such as “publishes to connected channels” needs the boundary beside it: supported destinations, configured access, and any review setting that controls publication.
Next, collect current screenshots and recordings. Give each file a short note explaining what it proves. “Calendar with three scheduled posts” is more useful than “dashboard-final-2.png.” Record the product version, account state, and whether the screen contains sample or real customer data. Remove anything that should not appear publicly.
Gather the documentation that explains setup, permissions, limits, and expected behavior. Marketing claims often become weaker as they get shorter. The source pack protects the caveats that keep a strong sentence honest.
Finally, copy customer language exactly from approved sources. Save the surrounding context too. “I hate posting every day” means something different from “I hate approving posts every day.” One supports an automation angle. The other points toward better review controls.
Turn each artifact into a claim boundary
Evidence does more than support a claim. It tells you where the claim must stop.
A screenshot of one generated vertical video can support “create a vertical launch video from approved product material.” It cannot support a claim about daily publication, every social platform, or performance. Those require separate product evidence.
Create a simple evidence ledger with five fields:
- Record the proposed claim in plain language.
- Link the artifact that supports it.
- Note the product state or configuration shown.
- List the caveat that must remain attached.
- Mark which formats can use it.
The final field matters. A detailed documentation page may support a technical article, while a clean product recording can carry a short video. One customer phrase might open a founder post but feel forced in a product tutorial.
This ledger also exposes gaps while there is still time to fix them. If the launch angle depends on a feature nobody has captured, record the screen before drafting. If a customer quote lacks permission, replace it with verified product evidence. Do not polish an unsupported claim and hope the evidence appears later.
Assign one evidence job to every launch asset
A week of launch content should not repeat the same announcement seven times. Give each asset a different job and bind it to the evidence best suited to that job.
The launch article can explain the problem, the shipped change, and the operating boundaries. A short product video can show the workflow. A developer-focused post can unpack the implementation decision. A newsletter can connect the release to a customer’s stated pain. Social posts can isolate one concrete proof point at a time.
This is where an editorial calendar earns its place. Put the evidence link beside each scheduled item. If Tuesday’s screenshot changes, you can see which Wednesday and Thursday drafts need review.
The same discipline prevents unproven angles from consuming the week. When an idea sounds promising but lacks support, hold it for research instead of dressing it up as a launch claim. Amara’s unproven angle shows the cost of letting a deadline turn an assumption into a campaign.
Leave the desk with tomorrow’s first move decided
Before ending the sweep, choose the first asset to draft and place its evidence in order. Open with the customer problem, show the product change, demonstrate it with the strongest artifact, then state the relevant boundary. The writer should not need to search Slack, inspect an old build, or ask which screenshot is current.
Apollo 13’s adapter worked because Smylie’s team designed from the inventory aboard the spacecraft. Your launch week follows the same rule at lower stakes: work from what the product has shipped and what the record can prove.
At 9 p.m., collect the materials. At 9 a.m., write from evidence.
Comments
No comments yet.