Skip to content
Back to skills

Product Launch

ASecurity

Creates go-to-market plans and launch checklists for features and side projects. Use when preparing a feature for public release, planning a Product Hunt launch, defining a rollout strategy, creating a post-launch review framework, or coordinating the technical, product, and marketing work for a launch. Triggers on: "prepare launch", "go-to-market", "Product Hunt", "launch checklist", "rollout plan", "launch this feature".

  • 3 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 1, 2026
documentationgoapifullstacksecurityperformancedocumentation

Works with

  • cli
  • api

Security analysis

A100/100

Scanned September 1, 2026

npx -y skills add alunadev/ald-skills --skill product-launch --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Product Launch?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Product Launch
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/alunadev-product-launch/badge)](https://www.skillsdirectory.com/skills/alunadev-product-launch)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: product-launch
description: Creates go-to-market plans and launch checklists for features and side projects. Use when preparing a feature for public release, planning a Product Hunt launch, defining a rollout strategy, creating a post-launch review framework, or coordinating the technical, product, and marketing work for a launch. Triggers on: "prepare launch", "go-to-market", "Product Hunt", "launch checklist", "rollout plan", "launch this feature".
---

# Planning Product Launch

## Core Philosophy

Launch is a process, not an event. Most launches fail not because the product is bad, but because the preparation was incomplete — monitoring wasn't in place, the rollback plan wasn't tested, or the messaging was unclear.

Every launch is a rehearsal for the next one. Document what happened and why so the process improves each time.

---

## Workflow

### Step 1 — GTM Brief

Define the narrative before any tactical work:

```
Feature: [Name]
Positioning sentence: For [audience], [feature] is a [category] that [key benefit], unlike [alternative].
Target audience: [specific segment — not "everyone"]
Core message: [one thing you want people to remember]
Key channels: [where this audience actually is]
Launch date: [date]
Success metric: [number that changes in 7 days if launch works]
```

The positioning sentence forces you to make choices. If you can't complete it, the feature scope is unclear and launch should wait.

Output: Top of `docs/launches/YYYY-MM-DD-[feature]-launch.md`

---

### Step 2 — Technical Readiness Checklist

Verify before any external communication goes out:

**Monitoring**
- [ ] Error rates visible in dashboard (Sentry, Vercel logs, or equivalent)
- [ ] Key metric tracked (primary action event fires correctly)
- [ ] Alerts configured for error rate spike > threshold

**Rollback**
- [ ] Rollback procedure documented (how to revert in <10 minutes)
- [ ] Feature flag in place if gradual rollout (env var or flags service)
- [ ] DB migrations are reversible (tested with `down` migration)

**Performance**
- [ ] Page load time tested on production (not dev server)
- [ ] API endpoints respond < 500ms under normal load
- [ ] No N+1 queries in the happy path (check with EXPLAIN ANALYZE if needed)

**Security**
- [ ] Auth flows tested (unauthenticated access properly blocked)
- [ ] RLS policies verified (users can't access each other's data)
- [ ] No sensitive data in client-visible responses

---

### Step 3 — Product Readiness Checklist

**Documentation**
- [ ] Feature described in changelog / release notes
- [ ] Help doc or tooltip for anything non-obvious
- [ ] Error messages are clear and actionable (not "Something went wrong")

**Support**
- [ ] You know how to reproduce reported issues
- [ ] Support response template ready for common failure modes

**Onboarding**
- [ ] Empty state guides new users toward the first action
- [ ] First-run experience works (tested fresh account)

---

### Step 4 — Marketing Checklist

Scale to what makes sense for the launch size. A small feature update needs steps 1-2; a major launch needs all of them.

1. **Announcement copy** — headline, body, CTA. One message, one CTA. Adapt length per channel.
2. **Visual assets** — screenshot, demo GIF, or short video (≤60 seconds)
3. **Channel execution:**
   - X/Twitter: thread or single tweet
   - LinkedIn: post with first paragraph carrying full weight (it gets truncated)
   - Newsletter: subject with number or question, single CTA
   - Product Hunt: tagline (<60 chars), first comment with story, hunter lined up
4. **Timing:** Post when your audience is online. Check your analytics for peak engagement time.

---

### Step 5 — Rollout Gates

Use progressive rollout when the feature affects data writes, payments, or user auth:

| Stage | Audience | Duration | Gate to next |
|-------|----------|----------|--------------|
| Soft launch | Internal / 5% | 24-48h | Error rate stable, no critical bugs |
| Controlled | 25% | 3-5 days | Key metric moving in right direction |
| Full | 100% | — | Post-launch review scheduled |

For small features (UI-only, no data changes): skip to full launch directly.

---

### Step 6 — Post-Launch Review

**T+7 days — What happened?**
- What was the error rate in the first 24h?
- What did the first user reports say?
- Did the key metric move as expected?
- What would you do differently with the preparation?

**T+30 days — Did it work?**
- Did the success metric reach the target?
- What is the retention rate of users who tried the feature?
- Is there follow-up work (bug fixes, improvements) that came out of launch?
- What's the next iteration based on data?

Output: Append results to `docs/launches/YYYY-MM-DD-[feature]-launch.md`

---

## Output Artifacts

```
docs/launches/YYYY-MM-DD-[feature]-launch.md
├── GTM Brief
├── Technical Readiness Checklist (with checkmarks)
├── Product Readiness Checklist
├── Marketing Checklist + copy drafts
├── Rollout Gate log
└── Post-Launch Review (T+7, T+30)
```

## Quality Checklist

- [ ] Positioning sentence completed (not skipped)
- [ ] Success metric defined before launch (not "we'll see what happens")
- [ ] Rollback procedure documented and tested
- [ ] Error monitoring active before external announcement
- [ ] Post-launch review date in calendar

## Common Antipatterns

- **Announcing before monitoring is in place** — You find out about the bug from a user tweet, not your dashboard. Monitoring first, then announcement.
- **"Success" undefined** — If you don't define success before launch, you can't tell if it worked. Define the metric in Step 1.
- **Marketing copy written after technical work** — The best launches start with the announcement draft. If you can't write it clearly, the feature isn't ready.
- **Skipping T+30 review** — T+7 tells you if the launch went smoothly; T+30 tells you if the feature is valuable. Both are required.

## See Also

- `building-fullstack-features` — For the technical implementation before launch
- `product-strategy` — For positioning this launch within broader strategy
- `product-analytics` — For defining success metrics and post-launch analysis

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…