/product-launch

Product launch

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. 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 conditional references

• Read launch strategy for positioning, channel selection, asset planning, operations, and postmortems.
• Read waitlist implementation only when implementing or auditing signup capture.

References do not determine interaction or output; this file is authoritative.

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.

Launch strategy patterns

Use this reference after the main skill selects strategy, audit, implementation, or postmortem mode. Platform behavior is time-sensitive; verify current rules from official platform documentation and date the evidence.

Contents

• Positioning
• Audience access
• Launch loops
• Channel selection
• Assets and operations
• Measurement
• Postmortem

Positioning

Create a compact claim stack:

1. audience and triggering situation;
2. costly or frustrating current approach;
3. changed outcome;
4. product mechanism;
5. proof and limitation;
6. why the timing is relevant.

Test the claim against current alternatives and actual audience language. Distinguish customer words, observed behavior, and team hypotheses.

Audience access

Map real paths to the first users:

Prefer channels where the team can participate credibly. “Developers,” “founders,” or a platform name alone is not an access strategy.

Launch loops

Describe each loop as:

trigger → artifact/message → channel → landing/context → target action → follow-up → learning

Examples of artifacts include a working demo, benchmark, template, integration, technical explanation, customer story, event, or shareable product output. Build an artifact only when it strengthens the chosen loop.

Channel selection

Evaluate channels by:

• audience concentration and team credibility;
• format fit and proof required;
• preparation lead time;
• platform and community rules;
• conversion path and follow-up capability;
• measurement quality;
• downside from low relevance or excessive promotion.

Do not claim to know ranking weights, vote thresholds, “best” launch days, or premium-account boosts unless a current official source documents them. Do not coordinate votes, fake engagement, or evade community rules.

Useful channel-specific questions:

• Community/forum: What contribution is welcome? Is self-promotion limited to specific threads?
• Directory/launch platform: What assets and listing fields are required? What solicitation is prohibited?
• Social: Which existing audience relationship and artifact make the post native?
• Email/newsletter: Is the list consented and relevant? What is the sender's follow-up capacity?
• Partners/integrations: Is the listing approved and the integration reliable enough to support demand?
• Press/analyst: Is there a genuinely newsworthy, verifiable claim and an available spokesperson?

Assets and operations

Create a dependency table:

Plan day-of operations proportionally:

• publishing/access credentials;
• response ownership and service level;
• issue intake and severity routing;
• status communication and rollback;
• customer/support handoff;
• decision checkpoints.

Measurement

For each metric define event, population, window, source, owner, baseline/target if evidence exists, and decision. Separate directional source attribution from causal lift.

Common layers:

• reach or qualified visits;
• target action;
• activation/value event;
• retention or revenue after maturity;
• operational quality and support burden.

Use tagged links consistently, preserve referrer where possible, and test event capture before launch.

Postmortem

Compare observed results with the launch hypotheses:

• what shipped and where;
• funnel counts with denominators and maturity;
• qualitative themes with examples;
• channel and message evidence;
• failures, incidents, and attribution gaps;
• positioning/product/distribution decisions;
• follow-up experiments and owners;
• reusable assets and relationships.

Do not treat a single launch-day rank or traffic spike as product-market fit.

Safe waitlist implementation

Adapt this design to the detected stack. It defines invariants and failure handling rather than paste-ready framework code.

Contents

• Decisions
• Data model
• Signup transaction
• Confirmation and consent
• Referrals
• Admin access
• Abuse and privacy
• Verification

Decisions

Infer from the product and ask only unresolved choices:

• fields strictly required for launch;
• single or double opt-in and jurisdiction/product rationale;
• confirmation email and sender setup;
• referral program and fraud tolerance;
• queue position semantics, if positions are shown at all;
• admin/export users and retention/deletion policy.

Email-only is often lower friction, but it is not a universal requirement.

Data model

Preserve these logical fields as required by the chosen design:

id: random opaque identifier
normalized_email: unique under an explicit normalization policy
display fields: optional, length-limited, safely encoded on output
status: pending | confirmed | unsubscribed | deleted
consent_source / consent_version / consent_at: when required
confirmation_token_hash / expiry: for double opt-in
referral_code: cryptographically random and unique
referred_by_id: validated foreign key
created_at / confirmed_at / unsubscribed_at
source and campaign fields: allowlisted, length-limited

Do not expose sequential IDs or derive public referral codes from email. Avoid mutable queue positions unless the product has a clear, concurrency-safe ordering policy.

Use database constraints for uniqueness and referential integrity. Treat the database as the authority under concurrent requests.

Signup transaction

The handler should:

1. enforce request size/content type and parse safely;
2. validate and normalize the email under a documented policy;
3. validate/limit optional text and attribution fields;
4. apply rate limiting and bot/abuse controls appropriate to exposure;
5. insert with an atomic upsert or catch the unique constraint;
6. validate referral code and record attribution transactionally;
7. return a generic success response that does not reveal whether an arbitrary address is registered;
8. enqueue confirmation delivery after durable storage;
9. emit privacy-minimized success/failure events.

Do not perform “check then insert” as the uniqueness mechanism. Do not increment referral counters separately from the referral record; derive or update them transactionally.

Confirmation and consent

• Use a cryptographically random, single-use, expiring token; store only its hash.
• Encode user-supplied content in HTML and provide a text version.
• Use a verified sending domain and current provider guidance.
• Handle provider failure asynchronously with retries and idempotency.
• Include required sender identity and preference/opt-out controls.
• Do not activate referrals, queue movement, or campaigns until the chosen confirmation rule is satisfied.
• Keep consent evidence separate from marketing assumptions. Joining a product waitlist does not automatically authorize unrelated messages.

Referrals

Model each accepted referral as an idempotent relationship. Prevent:

• self-referral;
• repeated credit for the same confirmed signup;
• credit before confirmation when confirmation is required;
• arbitrary client-supplied referrer IDs;
• easily enumerable or guessable codes;
• unbounded rewards without fraud review.

Define what happens when a referrer unsubscribes or a referred user is deleted.

Admin access

Use the application's real authorization system with a least-privilege admin role. A static secret header is not a substitute for an admin surface.

Admin/export behavior should include:

• server-side authorization on every request;
• pagination and field minimization;
• audit logging for view/export/delete;
• CSV/formula-injection protection on export;
• rate limits and short-lived download links where applicable;
• retention, deletion, unsubscribe, and data-subject workflows;
• no raw PII in application logs or analytics.

Abuse and privacy

Document data purpose, fields, processors, retention, access, deletion, consent basis, and incident path. Add CSRF protection when cookie-authenticated state changes require it. Review spam traps, disposable addresses, automated signups, and referral gaming in proportion to risk.

Verification

Test locally and in the deployed environment:

• valid, invalid, Unicode, case, whitespace, and maximum-length addresses;
• concurrent duplicate submissions;
• generic response for existing and new addresses;
• rate-limit and bot-control behavior;
• confirmation token expiry, reuse, and wrong-token cases;
• email HTML/text encoding and deliverability;
• referral validation, idempotency, self-referral, and confirmation gate;
• admin authorization, pagination, export safety, audit log, and deletion;
• analytics events without PII;
• provider outage, retry, and recovery;
• accessibility, loading, error, success, and offline states.