Launch a feature

Orchestration sequence

How the skills fire across 4 phases.

Each phase produces an artifact the next phase depends on. The sequence is what turns a high-level prompt into a shipped outcome.

Frequently asked

Questions this walkthrough surfaces.

How is this walkthrough different from the feature-launch-playbook skill alone?

The feature-launch-playbook skill covers the launch discipline: shipping vs releasing vs launching, internal alignment, sales enablement, support readiness, rollout strategy, monitoring with rollback triggers. This walkthrough is the broader orchestration: pm-spec-writing produces the spec, roadmap-planning sequences the work, beta-program-management runs the soft launch, content-brief-authoring scopes the comms, content-distribution executes them, editorial-qa gates them, and feature-launch-playbook ties the launch coordination together. The skill is one tool; the walkthrough is the workflow that uses ten tools together.

Do I need all 10 skills for a launch?

No. The Tier 1 walkthrough uses all ten; the Tier 2 cuts to seven; the Tier 3 cuts to four. Most launches are Tier 2 or Tier 3. Pick the cut that matches the launch stakes: a major launch that anchors the year warrants the full cluster; a small feature improvement that affects one segment may need only spec, flag, and analytics. The Variations section below describes the cuts.

When should I run an AB test as part of a launch vs skip it?

Run an AB test when the launch's success criteria are quantitative and the change can be tested against a meaningful control. Skip the test when the change is foundational and rolling back would be expensive (use staged rollout with monitoring instead), when sample size is too small for the test to be conclusive, or when the change is a quality fix that does not warrant testing. The run-an-ab-test walkthrough covers the testing discipline; this walkthrough composes it as one stage when applicable.

What is a 'soft launch' vs a 'public launch' in this walkthrough?

Soft launch: feature available to a calibrated cohort or via gradual ramp without coordinated public announcement. Beta program management runs this stage. Public launch: coordinated comms (blog, email, social, in-app), sales enablement, support readiness. Feature-launch-playbook owns the public launch discipline. Most launches benefit from both: soft launch validates with limited blast radius; public launch creates the coordinated moment that makes the feature land in the market.

How do I avoid post-launch support overload?

Three disciplines. First, support readiness pre-launch: docs, FAQ, support team training, escalation paths. Second, monitoring with explicit thresholds: define the support-volume increase that triggers investigation. Third, mid-launch communication: if friction surfaces in the first 48 hours, communicate to users transparently rather than letting tickets accumulate. The launch-comms calendar covers what ships when; the rollout plan covers the gates between phases.

What does post-launch retro look like?

30 days post-launch: aggregate the metrics against pre-launch hypotheses, surface what worked vs what did not, document lessons that inform the next launch. The retro is owned by the PM with input from engineering, design, content, and customer success. Write it as a document, not a deck; circulate to stakeholders; reference in the next launch's planning. Pair with after-action-report skill for the broader retro discipline.