launch-a-product

name	launch-a-product
category	start
description	Plan and run a small product launch with a defined audience, readiness checks, support ownership, measurement, and a reversible rollout. Use when someone says "launch this," is preparing a beta or public release, or needs to coordinate product, content, operations, and follow-up.

launch-a-product

Treat launch as a controlled learning window, not a single announcement. Make the product usable, the promise accurate, the support path staffed, and the first signals visible before inviting traffic.

Inputs

• Name the audience, launch owner, release owner, support owner, and final decision maker.
• Record the product promise, critical journey, availability limits, known risks, and rollback path.
• Define the launch window, channel permissions, communication budget, and success measures.

Procedure

1. Write a one-sentence launch promise that the current product can demonstrate without qualification.
2. Choose the smallest audience that can supply useful feedback at acceptable risk: internal, invited pilot, limited beta, staged region, or public.
3. Build a readiness checklist covering the critical journey, account or payment handling, privacy, accessibility, performance, analytics, support, legal approvals, monitoring, and rollback.
4. Test the journey from the audience's environment using a new account or clean state. Save screenshots, logs, or transaction records as launch evidence.
5. Prepare accurate launch materials: audience, problem, result, eligibility, limitations, next action, support contact, and privacy expectations.
6. Instrument a small scorecard for activation, successful outcome, failure, support demand, and retention signal. Verify each event before launch.
7. Write stop, pause, and rollback thresholds. Assign the person authorized to act on each one.
8. Rehearse the launch sequence and one failure: announcement, traffic arrival, user journey, support response, status update, and disable or rollback.
9. Release to the chosen audience. Keep a timestamped log of changes, messages, incidents, and decisions.
10. Review signals at pre-set intervals. Fix severe journey failures before increasing reach.
11. Close the window with a launch report comparing expectations with observed behavior and naming the next decision.

Boundaries

Do not announce unavailable capabilities, hide material limitations, enroll people without consent, or send unsolicited bulk messages. Do not expand traffic while rollback is untested or critical user data is at risk.

Done

• A clean-state launch check proves the critical user journey and records the exact released version
• Launch materials state the real promise, limits, next action, privacy terms, and support path
• The scorecard and launch log show activation, outcome, failures, support demand, and decisions
• A closeout report records audience reached, observed results, incidents, rollback status, and next step

Then use add-analytics to improve the scorecard or debug-a-production-incident if users are actively blocked.