A launch video should describe what the product can complete today, under conditions you can reproduce. If the voiceover promises an autonomous workflow that still needs a person to rescue it, stop the export and change the claim.
In January 1986, Morton Thiokol engineer Roger Boisjoly was among those warning that the Space Shuttle Challenger’s O-rings could perform poorly in unusually cold conditions. The night before the scheduled launch at Kennedy Space Center, Thiokol engineers recommended against launching at the temperatures forecast for Florida.
NASA challenged the recommendation. Thiokol managers reconsidered and approved the launch.
Challenger lifted off on January 28. Seventy-three seconds later, the shuttle broke apart, killing all seven crew members. The Rogers Commission later documented the warnings, the disputed launch recommendation and the failures in decision-making that preceded the disaster.
The scale is incomparable to a product video. The decision pattern is still useful: evidence raised a clear limit, pressure favoured proceeding, and the final approval communicated more confidence than the system deserved.
The sentence that changed the launch
The generated voiceover sounded good.
It described the product receiving a customer request, selecting the right action, updating the necessary records and notifying the team. One continuous workflow. No manual step mentioned.
The interface shown in the video supported the story. A request entered on the left, status indicators moved, and a completed result appeared on the right. Anyone watching would reasonably conclude that the product handled the whole process.
But one transition still depended on a person.
The system could interpret the request and prepare the next action. It could not reliably complete that action when a required field was missing or the external service returned an unexpected response. Someone had to notice the stalled run, inspect it and restart part of the workflow.
That intervention did not appear in the script.
The question before export was therefore narrow: could we defend the word “autonomous” if a prospective customer asked us to run the same workflow using their data?
No. I stopped the export.
A demo can be accurate and still mislead
None of the screens had been fabricated. The product had performed each visible step during testing. The problem sat in the connection between those facts.
A demo becomes misleading when it turns several conditional capabilities into one unconditional promise.
“Creates the next action” becomes “completes the workflow.”
“Works with the expected input” becomes “handles incoming requests.”
“Can recover after intervention” becomes “runs without supervision.”
Each edit is small enough to survive a rushed review. Together, they describe a different product.
This matters most for founders selling AI products before the system has met enough awkward customer data. The polished path is easy to record because you control the prompt, account state and external services. A buyer in Accra, Berlin or San Francisco will introduce names, formats, permissions and exceptions your launch recording never encountered.
The safe claim is the one that remains true when those conditions change.
That does not require timid copy. It requires precise copy. “Prepares the action for approval” may sound less ambitious than “runs the workflow autonomously,” but it gives a buyer an accurate picture of where their team remains responsible. Accurate boundaries make the working capability easier to trust.
I use the same standard when reviewing any generated launch asset: can I defend every claim in the AI-generated launch video? If the answer depends on the perfect test account, the line needs another pass.
Review the verbs against the product
The fastest claim review starts with verbs.
Take the script and mark every word that assigns an action to the product: decides, sends, approves, reconciles, monitors, completes, recovers. Then run the corresponding workflow from beginning to end.
For each verb, record three things:
- What the product completes without intervention.
- Which conditions must be true for it to complete that action.
- What the user sees when it cannot continue.
This catches more than obvious falsehoods. It exposes claims that are technically defensible but commercially dangerous. A workflow may succeed most of the time in the founder’s test environment while failing silently when a customer’s API permission expires. “Monitors every request” becomes hard to defend if the user receives no clear failure state.
Recovery belongs in the claim review too. A Wi-Fi drop taught Lwazi that a demo needs a recovery path, because a successful happy path says little about what happens after the connection disappears.
If the product pauses and asks for approval, show that. If it drafts an action but does not execute it, say “drafts.” If a team member must resolve exceptions, put that person back into the workflow.
The launch may feel smaller. The product will feel more real.
Stop the export before the market does
The Rogers Commission did not treat the Challenger decision as a narrow component failure. Its report examined how technical concerns moved through an organisation and how the final launch decision came to contradict the evidence engineers had raised.
A founder faces a safer version of that decision whenever launch pressure meets an inconvenient limitation. The campaign is scheduled. The video has already taken days. A partner expects the announcement. Changing one sentence may require recording the voiceover again and shifting the edit.
Those costs are already incurred. Publishing transfers the unresolved cost to the customer.
Before approving the export, play the video once without admiring the production. Pause after every product claim and ask for the run, log or test that supports it. Where the evidence ends, narrow the sentence.
Then export the version your product can repeat.
Comments
No comments yet.