A pre-launch product safety checklist: the gates a product must pass before its first sale

A checklist that advises but does not block will be overridden at the first launch deadline, because deadlines are vivid while safety gaps are abstract until they fail. Blocking gates change that balance: the product cannot be listed, shipped, or advertised until each gate is signed, by a person who has seen the evidence. That friction is deliberate, because it forces the safety conversation before buyers are involved, when it is still cheap.

Blocking should be practical, not bureaucratic. The gate should be a simple sign off, recorded with the evidence reference, not a committee meeting. A launch manager who can sign a gate in minutes, because the evidence is ready, will not resent it. A launch manager who must hunt for evidence the team never prepared will resent the gate, but that resentment points at the preparation failure, not at the gate itself.

The assessment gate requires a risk assessment for the product as it will be sold, covering its hazards, its users including vulnerable users, its foreseeable uses and misuses, and its controls, with the assessment dated and owned. An assessment written for a prototype, a similar product, or a generic category does not pass this gate, because it does not describe the product buyers will receive. The gate checker should read the assessment for product specificity, not merely for existence.

The assessment should also name any residual risk that warnings or instructions must address, so the labelling gate can verify those warnings exist. An assessment that identifies a risk but never connects it to a warning or a design control has identified a problem without solving it, and the gate should catch that disconnect before launch.

The evidence gate requires test or inspection evidence that matches the assessment's controls, with scope matching the product version and batch to be launched. Supplier assurances alone do not pass this gate where testing is the control, and a test report for a different version does not pass it either. The gate checker should verify model, version, scope, and date for each evidence document, because a file of mismatched evidence is worse than an empty file, as it creates false confidence.

Where evidence is genuinely unavailable before launch, the gate should not be waived silently. The launch should pause, or the product's claims and markets should be narrowed to what the evidence supports, with the gap recorded and a date for closing it. A launch that proceeds on a waived gate, without a record, will be remembered as a launch that skipped safety, whatever the team intended.

The labelling gate requires production labels and listing drafts checked against the assessment and the file: identification complete, warnings present and legible, instructions accurate, languages correct for each launch market, and listing information consistent with the physical product. The check should use a production sample and a live listing preview, not artwork and draft text alone, because production and preview reveal errors that drafts hide.

Labelling gate failure is common and cheap to fix before launch, expensive to fix after, because relabelling shipped stock or correcting live listings under buyer scrutiny costs far more than correcting a proof. Illustration: a seller of outdoor lanterns catches a missing warning language at the labelling gate, adds it to the production label, and avoids a market specific relabelling exercise after launch.

The traceability gate requires batch or unit identification assigned, a picking and sales recording routine that preserves it, a responsible person arrangement that functions, and a complaint log ready to receive post launch reports. A product launched without traceability cannot be recalled precisely, cannot be investigated by batch, and cannot be monitored by pattern, so its launch creates a blind spot that will persist for the product's whole life.

The gate should be tested, not merely asserted. A mock trace, from a sample unit through the picking record to a hypothetical buyer, should complete before launch, proving the routine works. A routine that works on paper but fails a mock trace will fail a real trace, and the launch gate is the last cheap moment to discover that.

Post launch ownership should be named before launch: a person who reviews complaints, watches alerts for the product type, updates the file when the product changes, and triggers a reassessment when a pattern appears. Without a named owner, post launch monitoring becomes nobody's job, and the product drifts unmonitored until an incident forces attention. Naming the owner at launch, with a deputy, prevents that drift.

The owner should also have a first review date, set at launch, for checking early complaints and sales experience. Early review catches launch problems, such as a misunderstood instruction or a packaging failure, while they are still small. A product launched with an owner and a review date is a product whose safety story continues after sale, which is where most of its story actually happens.