product-launch ยท diff
git:20260807.975fe85 to git:20260807.fac9f85
45 added, 15 removed. Audit A to A.
---
name: product-launch
- description: Plan and implement a product launch with positioning, assets, distribution, measurement, waitlist capture, and follow-up. Use when preparing or reviewing a launch.
+ description: Plan, implement, audit, or review launches with positioning, assets, distribution, conversion, measurement, waitlists, and follow-up. Use when preparing or learning from a product launch.
license: MIT
---
# Product launch
- Build a launch around a specific audience, credible claim, working conversion path, and follow-up loop. Support strategy-only work and repository implementation without pretending they are the same task.
+ Build a launch around a specific audience, credible claim, working conversion path, and learning loop.
+ ## Choose a mode
+
+ - **Strategy:** positioning, audience access, channel choices, timeline, and risks.
+ - **Implementation:** build only the required site, waitlist, tracking, or launch assets.
+ - **Audit/dry run:** test readiness, claims, links, conversion, instrumentation, and operations.
+ - **Postmortem:** explain results, update positioning, and define follow-up experiments.
+
+ Scale the artifact to the launch. A small beta does not need a multiweek war room or a large GTM document.
+
## Workflow
- 1. Establish the product, launch stage, audience, problem, proof, constraints, date, owner, and target action. Inspect existing product briefs, site copy, analytics, waitlist, and prior launches before asking questions.
- 2. Research the category, current alternatives, audience language, communities, launch calendars, and platform rules using current sources.
- 3. Write the positioning in plain language: who it is for, what changes, how it works, why now, and why this product is credible. Remove claims the project cannot support.
- 4. Choose a launch type and a small set of channels based on actual audience access. Assign each channel a format, owner, publish time, response plan, and success metric.
- 5. Inventory required assets: landing page, demo, screenshots, announcement, founder post, email, directory listings, press material, support docs, and tracking links. Build only what the launch needs.
- 6. Confirm the conversion path works end to end. If pre-launch demand capture is needed, implement the waitlist with validated email storage, duplicate handling, confirmation, consent, admin access, and optional referrals.
- 7. Instrument source attribution, activation, conversion, and follow-up. Define the decision each metric will support.
- 8. Prepare day-of operations, replies, issue triage, follow-up touches, and a 24-hour/7-day review.
+ 1. Inspect product briefs, site/repository, analytics, waitlist, audience evidence, assets, platform accounts, and prior launches before asking questions.
+ 2. Establish stage, audience, problem, proof, target action, launch date/window, owner, budget, constraints, existing reach, and decision metrics. Ask only for missing inputs that change the plan.
+ 3. Research current alternatives, audience language, communities, channel rules, and relevant calendars from primary or first-party sources where possible. Date platform-sensitive findings. Do not claim knowledge of opaque ranking algorithms.
+ 4. Write plain-language positioning: for whom, what changes, mechanism, why now, and why credible. Remove unsupported claims.
+ 5. Choose a launch type and few channels based on audience access and product fit. For each, state format, owner, timing rationale, response plan, policy constraints, conversion path, and metric.
+ 6. Inventory the smallest asset set needed. Treat landing pages, demos, screenshots, support docs, share artifacts, tracking links, and product changes as dependencies only when the chosen plan requires them.
+ 7. Test the conversion path end to end. If demand capture is required, follow the safe waitlist guidance.
+ 8. Instrument source attribution, activation, conversion, follow-up, and failure states. Define what decision each metric supports and distinguish directional attribution from causal proof.
+ 9. Run a dry launch: links, forms, email delivery, mobile, accessibility, analytics, support, rollback, incident ownership, and platform-policy checks.
+ 10. Operate the launch, then review at an appropriate early window and after enough time for the target behavior to mature.
- ## Load deeper guidance
+ ## Load conditional references
- - Read [launch strategy](references/launch-strategy.md) for research, channel planning, assets, timelines, and reporting.
- - Read [waitlist implementation](references/waitlist-implementation.md) only when the project needs a real signup flow.
+ - Read [launch strategy](references/launch-strategy.md) for positioning, channel selection, asset planning, operations, and postmortems.
+ - Read [waitlist implementation](references/waitlist-implementation.md) only when implementing or auditing signup capture.
- ## Output
+ References do not determine interaction or output; this file is authoritative.
- Return the positioning, launch brief, channel plan, asset checklist, implementation changes, measurement plan, and follow-up schedule. Distinguish verified audience evidence from assumptions.
+ ## Output contract
+
+ Return only mode-relevant sections:
+
+ - launch context and evidence/assumption ledger;
+ - positioning and target action;
+ - channel plan and asset dependencies;
+ - implementation changes and conversion-path notes;
+ - measurement and attribution plan;
+ - dry-run findings, operations, rollback, and owners;
+ - follow-up schedule or postmortem with decisions.
+
+ ## Verify
+
+ - Audience and channel choices are supported by evidence or labeled assumptions.
+ - Material claims have proof and current platform rules are sourced/date-stamped.
+ - Every public link and primary conversion path works in the deployed environment.
+ - Signup, confirmation, attribution, activation, and failure events are observed.
+ - Privacy, consent, security, accessibility, and suppression/retention requirements are addressed.
+ - Owners, incident path, rollback, and follow-up decisions are explicit.