The Square Canisters Apollo 13 Needed, and What They Almost Cost the Crew

A 30-minute launch-note sort can turn a week of scattered product evidence into a useful article brief before you publish. Start with what changed, who it helps, and the proof you can show, then leave every unsupported claim out.

In April 1970, Apollo 13’s crew faced a CO2 problem inside the Lunar Module. The available square command-module canisters did not fit the Lunar Module’s round receptacles, and the crew needed a workable adapter before conditions became more dangerous. NASA’s Apollo 13 history documents how engineers on the ground developed a solution from materials already aboard the spacecraft, then relayed the procedure to Jim Lovell, Jack Swigert, and Fred Haise.

Sunday launch notes have lower stakes. The shape of the work is familiar: useful pieces exist, but they do not arrive preassembled.

Gather evidence before writing a sentence

Open three windows: this week’s commit messages, support notes, and the folder where you saved screenshots or recordings.

Give yourself ten minutes to pull only material that earns a place in the article:

• A shipped change a customer can notice.
• A support question that explains the old friction.
• A screenshot that proves the new behavior.
• A caveat, rollout limit, or provider dependency that keeps the claim honest.

A commit called “refactor publishing state” may matter deeply to the codebase and say little to a reader. A support note saying, “Can I republish a missed LinkedIn post without posting twice?” points toward a customer-facing release note. The screenshot confirms whether the answer belongs in the article now.

This is how you avoid turning internal work into a vague “we improved publishing” paragraph. You have the raw material to say what changed, why it matters, and where the boundary is.

Sort every note into one of four buckets

Spend the next ten minutes labeling each useful item: change, customer consequence, proof, or follow-up.

A change is the capability that shipped. “Republish content to a connected destination that missed the original post” is a change.

Customer consequence states the practical outcome. “Recover a missed channel without creating another copy on the existing social page” explains why someone should care.

Proof might be a screenshot, a before-and-after state, a real support request, or a product workflow you can demonstrate. Keep it close to the claim it supports.

Follow-up includes anything that needs checking before publication: documentation that still needs updating, a provider limitation, an approval rule, or a feature that is visible only to a subset of users. These notes do not belong in the launch article until they are confirmed.

The Apollo 13 adapter worked because the team focused on the constraint in front of them. Your brief needs the same discipline. A pile of true product facts can still fail to answer the reader’s immediate question.

Build the brief around one customer job

Use the final ten minutes to write five lines:

1. The release in plain language.
2. The customer problem it addresses.
3. The evidence you will include.
4. The limitation or condition that must appear.
5. The next related topic the reader may need.

For Marketing Agent, a brief might begin: “Marketing Agent can republish previously published content to destinations that missed it, without duplicating the existing social-page publication.” Then it can explain who needs it: a solo founder who scheduled a launch update across several channels and later finds one connected destination did not receive it.

That is enough to guide a search-ready article. The rest of the draft should expand the same promise with a screenshot, a short walkthrough, and exact language about connected destinations and provider access.

A launch note becomes easier to find when its title and opening use the words a customer would search. “How to republish a missed social post without duplicating it” has a clearer job than “Publishing improvements.” The internal name can stay in the changelog.

For a related example of keeping launch material grounded in one product strategy, see Product strategy for launch content: How Nina Kept Three Drafts Consistent.

Keep the brief small enough to finish

At 11:50 p.m., resist the urge to include every merged pull request. One article should carry one release story.

Put the leftover material into next week’s idea list: the onboarding change, the performance fix, the new setting, the technical explanation. That protects the article from becoming a release dump and gives you a starting point when the next quiet Sunday arrives.

Apollo 13 did not require a perfect spacecraft redesign in the moment. It required an adapter that fit the equipment available and helped the crew get home. Your launch note needs the equivalent: a clear connection between the evidence you have and the customer problem you can honestly solve.

Save the five-line brief beside the screenshots. Monday’s draft will have a claim, proof, a boundary, and a reason to exist.