product-launch-war-room

Product Launch War Room

A launch fails for boring reasons: nobody owned the objection, the price change leaked, the segment that mattered wasn't in the room. This skill runs the war room that catches those reasons before launch day — adversarial by design, decision-oriented, and grounded in your real customers when data is available.

It composes the panel skills (customer-panel-of-experts, prospect-panel-simulator) into a single GTM decision and a rollout plan you can execute.

What it's for

• New product / feature launch
• Repositioning or rebrand
• Price increase or packaging change (hand the rollout to pricing-change-strategist)
• Market or segment expansion
• Sunsetting something customers depend on

Step 1 — Define the launch

Lock these before any debate:

• What's launching and what specifically changes for the customer.
• Audience — existing customers, prospects, a specific segment, the market.
• Goal + metric — the number that defines success and the window to hit it.
• Constraints — timeline, budget, team, dependencies, hard commitments already made.
• Reversibility — fully reversible / costly / one-way door. This sets how much rigor the war room applies.

Step 2 — Convene the room

Seat both sides. Use icp-deep-scanner personas where the call is customer-facing; add functional experts for execution risk:

• Customer voice — relevant buyer personas (load from personas/; if absent and tools are connected, run icp-deep-scanner read-only; otherwise mark PROVISIONAL).
• The skeptic / pre-mortem lead — assumes the launch already failed and explains why.
• Functional experts as the launch demands — GTM/demand-gen, sales, product, support/CS, finance, brand. Each owns the risks in their lane.

For a thorough war room, dispatch parallel sub-agents (one per role) via /agent-army, then synthesize. Connections are read-only; no external sends; no real PII; secrets in env vars only.

Step 3 — Pre-mortem and debate

1. Pre-mortem — "It's 90 days post-launch and it flopped. What happened?" Each role writes the most likely failure in their lane.
2. Customer reaction — run the plan/messaging through the customer or prospect panel. Who's delighted, who churns, who shrugs.
3. Cross-fire — finance vs. growth, sales vs. product, brand vs. speed. Force the real trade-offs into the open.
4. Risk register — every surfaced risk scored by likelihood × blast radius, with an owner and a mitigation.

Step 4 — Decide and sequence

# Launch War Room — {Launch}
Generated: {timestamp} · Room: {roles/personas} · Reversibility: {…} · Grounding: {data / PROVISIONAL}

## Call: {GO / GO WITH CHANGES / DELAY / NO-GO}
The reasoning in one paragraph.

## Top risks (ranked)
| Risk | Likelihood | Blast radius | Owner | Mitigation | Pre-launch or live? |

## Required changes before launch
- The non-negotiables surfaced by the room.

## Phased rollout
- Phase 0 — prep & internal enablement (sales, support scripts, FAQ)
- Phase 1 — soft launch / segment / beta + what we watch
- Phase 2 — full launch + channels + sequencing
- Phase 3 — post-launch monitoring window

## Kill criteria & rollback
- The specific metric thresholds that trigger pause or rollback, and how to walk it back.

## Owners & timeline
| Workstream | Owner | Deadline | Dependency |

## Comms kit to produce next
- Customer email, sales talk track, support FAQ, objection handling, public page.

Step 5 — Hand off the artifacts

Offer to generate the comms kit (cold-email-sequence-generator, landing-page-copywriter, company-announcement-writer), route a price change to pricing-change-strategist, build the launch video with hyperframes-ad-director, or re-run the room against the revised plan.

Guardrails recap

Adversarial by default — the room's job is to find the failure, not bless the plan · rigor scales with reversibility · kill criteria are mandatory, not optional · read-only connections, no sends, no real PII · provisional grounding is labeled.