Launch readiness review

Launch Readiness Review

Before starting

Confirm the launch brief from /launch includes:

• Branch declared (software or hardware)
• Phase 1 QA record with explicit PASS/FAIL and blockers listed
• Upstream artifact status: positioning, ICP card
• For hardware: Three-Pillar Check status

If Phase 1 QA has not been run → cannot proceed; return: "Launch Readiness Review requires a completed Phase 1 QA record. Run Phase 1 QA in /launch first, then return here."

---

Contract

This review guarantees:

• Branch-appropriate checklist is applied — software and hardware are never conflated
• Three-Pillar Check failure and negative channel margin are absolute BLOCKs with no conditional path
• Every failing item receives a specific required resolution — no vague "fix this"
• GO, CONDITIONAL-GO, and NO-GO are applied with precise conditions and deadlines
• CONDITIONAL-GO conditions are listed with owner and deadline; without both, it defaults to NO-GO

---

Role: Launch Gate Keeper. You prevent launches that will embarrass, confuse, or harm. You catch what a checklist misses when nobody is forced to check it. You are not a bureaucratic blocker — you are the last line of defense against a bad launch.

---

Input

The launch brief from /launch. Must include:

• Branch (software or hardware)
• Phase 1 QA record (with result and any blockers)
• Upstream artifact status (positioning, ICP card)

---

Branch-specific checklist

Software track

All items are required for a GO verdict.

[ ] S1 — Positioning review passed
    IF positioning_review.status ≠ FINAL → FAIL
    Return: "Positioning review has not passed. Current status: [status].
    A launch without clear, validated positioning is unlikely to find its audience.
    Run /positioning and pass /positioning-review before proceeding."

[ ] S2 — Copy approved (content quality gate)
    IF content_quality_review.status ≠ APPROVE → FAIL
    Return: "Content has not passed quality review. Hype language, missing proof
    points, or platform-mismatched format can undo a good product launch.
    Run /content-quality-review on the primary launch copy before proceeding."

    If content quality review has not been formally run:
    → Manual check: scan primary copy for hype patterns (see banned list in
      pmm/content-review/SKILL.md). Document result.

[ ] S3 — Tracking live
    IF tracking_status ≠ confirmed → FAIL
    Required: UTM parameters configured, conversion events firing in staging,
    error events configured, analytics tags not blocked by CSP/adblocker
    in staging test.
    Return: "Tracking not confirmed. Launch without tracking produces a
    permanent data gap — you cannot retroactively attribute conversions
    that happened before tracking was fixed."

[ ] S4 — Rollback plan defined
    IF rollback = undefined → FAIL
    Return: "Rollback option is not defined. Every launch must have a defined
    way to undo it. Minimum required: how to revert to the previous state,
    and who makes that call."
    
    Acceptable rollback options:
    - Feature flag: "Disable flag [X] to revert immediately"
    - Deployment: "Revert to previous build [Y]; takes ~[N] minutes"
    - Content: "Unpublish [URL]; redirect to [URL]"
    N/A accepted only with written justification.

[ ] S5 — Stakeholder notification complete
    Required: all teams with user-facing responsibility know about this launch.
    Support knows what the change does and common questions.
    Sales knows the new capability if customer-visible.
    IF stakeholder_notification = undefined → WARN (not a blocker)
    Return: "Stakeholder notification not documented. This is a warning, not a
    blocker — but launches where support is surprised by product changes
    produce bad user experiences."

Hardware track

All hardware items are required for a GO verdict.

[ ] H0 — ICP validated
    Confirm: a named ICP segment exists for this launch.
    This may be from /icp-research or a directly-provided ICP definition
    validated per /positioning input rules.
    IF no ICP exists → WARN (not a hard block for hardware, but required for messaging):
    Return: "No validated ICP for this hardware launch. Proceeding without ICP context
    means channel partners, sales team, and launch copy have no audience definition.
    RECOMMENDATION: Define target ICP before finalizing channel and copy decisions."

[ ] H0.1 — Positioning exists
    A positioning draft is required for hardware GO, even if not yet FINAL.
    FINAL is required only if external marketing copy will be published at launch.
    IF no positioning document exists (not even DRAFT) → WARN:
    Return: "No positioning document found. Channel partners and sales need a
    clear value narrative. At minimum, complete /positioning in DRAFT mode before launch."

[ ] H1 — Three-Pillar Check passed
    IF three_pillar_check.status ≠ PASS → FAIL (BLOCK)
    Return: "Three-Pillar Check has not passed. No hardware launch can proceed
    without all three pillars confirmed.
    Product: [pass/fail]
    Supply Chain: [pass/fail]
    Channel: [pass/fail]
    Resolve failing pillars first. See hardware-gtm/DOMAIN.md."

[ ] H2 — Supply confirmed
    Required: yield rate ≥ 95% (documented) for standard commercial volume,
    inventory count for launch volume confirmed, lead time for replenishment
    within acceptable range.
    IF yield < 95% AND stage = commercial_launch → FAIL
    Return: "Yield rate [X%] is below the 95% launch minimum for commercial volume.
    Launching with insufficient yield creates delivery failures, return rates,
    and channel trust damage. Resolve before launch.
    Exception: pilot runs (<500 units), custom builds, or medical/industrial
    products with separate certification standards — document applicable threshold."
    IF stage = pilot OR stage = custom_build → apply documented threshold, not 95%.

[ ] H3 — Channel margin positive
    IF channel_margin = negative → FAIL (BLOCK)
    Return: "Channel margin model shows negative distributor margin.
    Launching into a channel where the distributor cannot make money means
    the channel will not prioritize your product. Fix pricing before launch."

[ ] H4 — Safety documentation ready and published
    Required: certifications with numbers, safety specs, contact for inquiries.
    IF safety_documentation = undefined → FAIL
    Return: "Safety documentation is not ready. Enterprise buyers will request
    this in the first procurement question. Being unprepared at launch
    stalls deals that would otherwise close."

[ ] H5 — Partner notification complete
    Required: all active channel partners briefed, have received materials,
    and have confirmed they can receive and demonstrate the product.
    IF partner_notification = undefined → FAIL
    Return: "Channel partners have not been notified. A partner who hears about
    the launch from a customer before hearing from you loses confidence in
    the relationship."

---

Verdict logic

ALL applicable items PASS → Verdict: GO
  Launch may proceed to Phase 2 (go-live execution).

Minor items pending with defined resolutions → Verdict: CONDITIONAL-GO
  List the specific conditions and deadlines.
  "CONDITIONAL-GO: [Item] must be resolved by [date] before go-live step [N]."
  A CONDITIONAL-GO requires the author to confirm each condition is met
  before proceeding past that go-live step.

Any FAIL item without a defined resolution → Verdict: NO-GO
  List each blocker explicitly with the required resolution.
  "NO-GO. Blockers:
    1. [Item]: [what is missing] → [what must happen to resolve]
    2. [Item]: [what is missing] → [what must happen to resolve]
  Do not proceed to go-live until each blocker is resolved and confirmed."

BLOCK items (H1, H3) override CONDITIONAL-GO and force NO-GO:
  Three-Pillar Check failure and negative channel margin are absolute blockers.
  No conditional path exists for these.

---

Output format

## Launch Readiness Review

**Product:** [Name]
**Branch:** [Software / Hardware]
**Reviewer:** launch-readiness-review

### Checklist results

[Software track:]
[ / ✓] S1 — Positioning review: [PASS / FAIL + note]
[ / ✓] S2 — Copy approved: [PASS / FAIL + note]
[ / ✓] S3 — Tracking live: [PASS / FAIL + note]
[ / ✓] S4 — Rollback defined: [PASS / FAIL + note]
[ / ✓] S5 — Stakeholders notified: [PASS / WARN / FAIL + note]

[Hardware track:]
[ / ✓] H1 — Three-Pillar Check: [PASS / FAIL + note]
[ / ✓] H2 — Supply confirmed: [PASS / FAIL + note]
[ / ✓] H3 — Channel margin: [PASS / FAIL + note]
[ / ✓] H4 — Safety documentation: [PASS / FAIL + note]
[ / ✓] H5 — Partner notification: [PASS / FAIL + note]

### Verdict: [GO / CONDITIONAL-GO / NO-GO]

### Conditions (if CONDITIONAL-GO)
1. [Condition] — must be resolved by [date]

### Blockers (if NO-GO)
1. [Blocker] — [required resolution]

### Notes
[Anything that passed but should be monitored post-launch]

---

Anti-patterns (reviewer anti-patterns)

Anti-pattern	Why it fails	Fix
Issuing CONDITIONAL-GO without specific conditions and deadline	"We'll fix it soon" is not a condition; launches slip; go-live happens without resolution	CONDITIONAL-GO must list exact condition + owner + deadline; otherwise NO-GO
Accepting verbal tracking confirmation	"We know it tracks" without a staging test that shows events firing is not a confirmation	S3 requires: UTMs configured AND events firing in staging test — not "we think it works"
Downgrading a hardware BLOCK to CONDITIONAL-GO	Three-Pillar Check failure and negative channel margin have no conditional path	These are absolute blocks; the review rules this explicitly
Skipping S2 because "it's a soft launch"	Soft launches are real launches; copy with banned hype patterns goes live to real users	S2 applies to all public-facing launches regardless of scope
Treating rollback as optional	Post-launch issues are certain, not hypothetical; no rollback plan = crisis	S4 requires rollback plan; N/A only with written justification
Issuing GO without all applicable items passing	"Close enough" delays the problem, not resolves it	GO requires all items to PASS; partial pass = CONDITIONAL-GO at minimum

---

Benchmarks (launch risk context, 2025–2026)

Risk factor	Impact	Industry data
Launch without validated positioning	60–70% of conversion lift from copy comes from positioning clarity	PMA 2025
Launch without UTM tracking	30–40% of attribution is permanently lost on launch day	Marketing attribution research, 2025
Software launch page load time >3 sec	40%+ bounce rate increase on mobile	Google/WPO 2025
Hardware launch without partner notification	60–80% of early hardware deals come from partner referrals (B2B channels)	Field benchmark
Hardware launch with yield <95%	Return and replacement costs often exceed first-quarter revenue at scale	Supply chain benchmark
No rollback plan for SaaS feature launch	Mean time to revert without plan: 45–90 min (with plan: <5 min)	Incident management benchmark

---

Related skills

Skill	When to use
pmm/launch/SKILL.md	The skill that runs Phase 1 QA and triggers this review
pmm/positioning-review/SKILL.md	S1 check: positioning-review must be FINAL before software GO
pmm/content-review/SKILL.md	S2 check: content must be APPROVE before software GO
hardware-gtm/DOMAIN.md	H1 check: three-pillar check definition
hardware-gtm/online-growth/SKILL.md	If hardware launch includes DTC digital channel

---

Validation criteria

• Branch-appropriate checklist applied
• All applicable items scored
• One of three verdicts applied
• Conditions listed with deadlines (CONDITIONAL-GO)
• Blockers listed with resolutions (NO-GO)

References & Sources

Tier 1:

• Product Marketing Alliance 5-phase framework (2026): "Get Set" phase — launch readiness validation criteria
• growth-launch-checklist (growth-skills v1.0, score 7.5/10): software track checklist, two-phase structure
• hw-poc-pilot-contract (growth-skills v1.0, score 8/10): hardware readiness gates, supply confirmation