Launch plan

Skill ramanbamba/10x-pm/skills/launch-plan

Prompts don't compound. Skills do. The open-source AI toolkit for product managers — 13 Claude Code skills + 3 red-team agents for the full PM workflow.

Install

npx -y skills add ramanbamba/10x-pm --skill launch-plan

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Build a go-to-market launch plan with tiering, owner matrix, timeline, and go/no-go checklist. Use when the user says "plan this launch", "GTM plan", "launch checklist", "release plan for [feature]", or is preparing to ship something to customers.

SKILL.md

3.5 KB, as published. Nobody here has run it

Launch Plan

Plan a launch as a coordination problem: right-size the effort with tiering, make every workstream owned, and gate the ship date with a real go/no-go.

Before planning

Tier the launch first — most launch failures are tier mismatches (a Tier 3 tweak getting a press push, or a Tier 1 bet shipping silently):
- Tier 1: new product or major capability; company-level narrative; full GTM machine
- Tier 2: meaningful feature for a known segment; targeted announce (blog, email, in-app)
- Tier 3: improvement/fix; release notes and docs only Recommend a tier with reasoning; confirm with the user.
Ask for the date driver: fixed date (event, contract) or fixed scope? Never let both be fixed silently.
Ask what "launch success" means numerically at day 7 and day 30 (adoption target, activation of the feature, pipeline generated). No target, no tier 1/2 launch.

Workflow

Positioning one-liner first. For [audience] who [struggle], [feature] delivers [outcome], unlike [alternative]. If this can't be written crisply, the launch messaging isn't ready — flag it.
Build the workstream matrix scaled to tier. Candidate workstreams: product readiness, docs/help, support enablement (macros, known issues), sales/CS enablement, pricing/packaging changes, marketing assets, comms/PR, legal/compliance review, analytics instrumentation, rollout mechanics (flags, % ramp, rollback). Cut what the tier doesn't need.
Timeline backwards from launch day. T-minus format with the critical path marked. Include a dry-run/bug-bash slot for Tier 1–2.
Define the rollout mechanics explicitly: flag strategy, ramp stages (internal → beta → % → GA), the metric watched at each stage, and the rollback trigger + procedure. "We'll monitor it" is not a plan.
Write the go/no-go checklist — binary items only, each with an owner. Schedule the go/no-go meeting T-2/T-3 days.
Day-after plan: who watches which dashboard, where feedback routes, when the first retro happens.

Output format

# Launch plan — [feature], Tier [N]
**Launch date:** [date] ([driver: fixed date / fixed scope]) · **DRI:** [name]
**Positioning:** [the one-liner]
**Success:** [D7 target] · [D30 target]

## Workstreams
| Workstream | Owner | Key deliverable | Due | Status |
|---|---|---|---|---|

## Timeline
| T-minus | Milestone | Owner |
|---|---|---|

## Rollout & rollback
Stages: [internal → beta → X% → GA, with dates]
Watch metric per stage: [metric + threshold]
**Rollback trigger:** [specific condition] → **Procedure:** [steps, owner]

## Go/no-go checklist (meeting: T-[N])
- [ ] [Binary item] — [owner]

## Day 1–7 operations
[Dashboard owner · feedback routing · retro date]

## Risks
[Top 3, each with mitigation and early-warning signal]

Quality bar — self-check

Tier is justified, and the plan's weight matches it.
Every workstream has one named owner — "team X" is not an owner.
Rollback trigger is a number, not a mood.
Go/no-go items are binary. "Docs mostly ready" fails; "help article published" passes.
Success metrics exist before launch — a launch without targets can't fail, which means it can't succeed either.