Skip to content

SOP-088 — Launch notification & cross-unit go-to-market

Guide

<!-- last-reviewed: 2026-06-01 · owner: CGEO (Chief Growth & Experience Officer) -->

SOP-088 — Launch notification & cross-unit go-to-market

SOP · owner: CGEO. Layer: SOP/Runbook (docs/canon.md). On a product brief from the CPTO at Build→Grow, the CGEO writes the cross-unit GTM brief (Growth distribution · Creative brand moment · CS onboarding) and notifies the COO of operational load and any security-surface implications. The flywheel model and brand standard are linked, not restated (docs/knowledge/growth/flywheel-model.md, docs/brand/).

Interface Contract

  • Inputs: product brief ← from CPTO · trigger: product brief delivered
  • Inputs: architecture-decision notification ← from CPTO · trigger: architecture decision notified
  • Outputs: cross-unit GTM brief (specs/gtm-<slug>.md) → to all agents · trigger: briefing posted
  • Outputs: product brief / launch instruction → to Growth Director · trigger: product brief delivered
  • Outputs: launch operational-load + security-surface notification → to COO · trigger: launch notification received
  • Outputs: approved GTM brief → to Archivist · trigger: artifact approved
  • Handoff trigger (in): the CPTO delivers a Build→Grow product brief naming what is launching, for whom, and what the slice does
  • Handoff trigger (out): the cross-unit GTM brief is distributed to all three Directors and the COO is notified of any operational/security-surface load
  • Definition of Done before handoff:
    • [ ] GTM brief names: audience segment · positioning · launch timing · each unit’s role (Growth distribution · Creative brand moment + assets · CS onboarding sequence) · success metric by unit · the flywheel arc this launch strengthens
    • [ ] COO notified in writing of any new operational process / onboarding automation / quality-gate change the launch requires
    • [ ] Security-surface note included in the COO notification if the launch materially expands the learner-data surface or introduces a new authentication touchpoint (so the Security Director can assess)
    • [ ] Public-facing launch assets routed through the voice/brand gate (SOP-090) before ship
    • [ ] No personal/learner data declared in any edge (PA-only; mirrors the PA personal-information exclusion)
    • [ ] Counterparty verified against the live .claude/agents/ directory (never the legacy roster; innovation-lead is retired)
    • [ ] Learnings captured to docs/knowledge/ if the launch surfaced one
    • [ ] GTM brief handed to the Archivist (0 drift)

product brief delivered and architecture decision notified are registered (docs/handoff-triggers.md, Wave-2 block, Operations-approved 2026-06-01); this SOP declares the CGEO consumer side that closes the CPTO outputs that previously reconciled as pending (Phase-0 F4 / SOP-041) — they are now matched point-to-point. The GTM-brief outputs use the registered briefing posted (a brief posted for a consumer to pick up); the Archivist edge uses artifact approved. The CGEO→COO launch notification uses the registered launch notification received trigger (Waves 3+4 block) and is matched against the COO’s mirroring input (SOP-071).

Purpose

Make sure no major launch reaches an audience without a coordinated cross-unit motion — so Growth’s distribution, Creative’s brand moment, and CS’s onboarding fire together and strengthen a named flywheel arc, and so the COO integrates any operational/security load before the launch date, not after.

When to use

When the CPTO delivers a Build→Grow product brief (what is launching, for whom, what the slice does), or when a major content launch, series launch, or platform-feature release requires coordinated action across Growth, Creative, and CS. Routine single-unit publishing does not route here (that is the unit’s lane).

Flow

flowchart LR
  A["Product brief received"] --> B["Read the brief:<br/>what · for whom · what it does"]
  B --> C["Write GTM brief:<br/>segment · positioning · timing<br/>+ each unit's role + arc"]
  C --> D["Notify COO:<br/>op-load + security surface"]
  D --> E["Route public assets<br/>through SOP-090"]
  E --> F["Distribute to 3 Directors;<br/>convene pre-launch review"]
  F --> G["Hand GTM brief<br/>to Archivist"]
  classDef s fill:#1d4ed8,color:#fff,stroke:#1e3a8a
  class A,B,C,D,E,F,G s

Text fallback: receive the product brief → read what is launching, for whom, and what the slice does → write the GTM brief (audience segment, positioning, timing, each unit’s role, success metric by unit, the flywheel arc it strengthens) → notify the COO of operational load and any security-surface implication → route public-facing assets through the voice/brand gate (SOP-090) → distribute to all three Directors and convene a brief pre-launch review (surface conflicts before execution) → hand the GTM brief to the Archivist.

Steps

  1. Read the product brief. Confirm what is launching, for whom, and what the slice does. If it is single-unit (no cross-unit motion needed), route back — this SOP is for coordinated launches.
  2. Diagnose the arc. Name which flywheel arc this launch is designed to strengthen (docs/knowledge/growth/flywheel-model.md). A launch with no named arc is a launch with no thesis.
  3. Write the GTM brief (specs/gtm-<slug>.md): audience segment · positioning · launch timing · Growth role (distribution + channel) · Creative role (brand moment + assets) · CS role (learner onboarding sequence) · success metric by unit · the flywheel loop it strengthens.
  4. Notify the COO in writing if the launch requires new operational process, onboarding automation, or quality-gate changes — before the launch date so the COO can integrate the load. Include a security-surface note if the launch materially expands the learner-data surface or adds an authentication touchpoint (so the Security Director can assess).
  5. Route public-facing assets through the voice/brand gate (SOP-090) before ship.
  6. Distribute to all three Directors and convene a brief pre-launch cross-unit review. Surface conflicts before execution, not after.
  7. Hand off the GTM brief to the Archivist; capture any learning.

Roles / approvers

Run by the CGEO. The three Directors (Growth, CS, Creative) own execution of their role in the GTM brief; the COO integrates operational/security load (binding on cluster units once arbitrated); the Security Director assesses any security-surface note; the Archivist preserves. Launches that imply a monetization lever or a major audience pivot escalate to the Principal (no unilateral Principal-level decisions).

Guardrails

  • Must NOT own the launch operational process — surface the load; the COO/Process Engineer designs and implements it (must-not-own-operational-processes guardrail).
  • Must NOT skip the brand gate — public-facing assets clear SOP-090 against docs/brand/ first; an un-voice-checked asset is not done.
  • Surface before execution — convene the pre-launch review and surface conflicts before the launch date; a GTM brief discovered after launch is a failure.
  • Personal/learner data is PA-only — declare no edge that hands off personal data.
  • Co-create, don’t one-shot — if the launch implies a new rule, route to Golden Rule (GR-3).
  • Do not restate the flywheel model or brand standard — link to docs/knowledge/growth/flywheel-model.md / docs/brand/.

See also: docs/units/cgeo-cluster/operating-model.md · SOP-089 (GTM-viability review) · SOP-090 (voice/brand gate) · docs/handoff-triggers.md · docs/sop/SOP-041-architecture-review.md (the CPTO side).