LogoSkills

/cc-product:launch — 다 만든 뒤, "출시" 단계

7단계: Launch — `docs/gtm-*.md`(GTM 전략·ICP·메시징)와 `docs/analytics-plan-*.md`(A/B 테스트·코호트 지표), 출시 체크리스트를 만들고 PR 로 기본 브랜치에 합칩니다.

/cc-product:launch — 다 만든 뒤, "출시" 단계#

항목내용
실행 명령/cc-product:launch
분류파이프라인
난이도●●○ 보통

파이프라인 7단계(Launch). 완성된 제품을 시장에 어떻게 알리고 팔지(GTM 전략), 누구에게 어떤 메시지로 다가갈지, 출시 후 무엇을 측정할지 정리합니다.

한마디로#

다 만든 제품을 세상에 어떻게 내보낼지 계획하는 단계입니다. 가게 문을 열기 전에 "누구를 손님으로 부를지, 간판에 뭐라고 쓸지, 장사가 잘되는지 어떻게 확인할지"를 미리 정해두는 것과 같아요.

누가·언제 쓰나요#

  • 개발이 끝나 배포할 수 있는 상태이고, 사용자에게 본격적으로 알리려는 경우
  • 출시 전략(GTM)과 마케팅 메시지를 정리하고 싶을 때

👉 건너뛰어도 되는 경우: 사용자에게 노출되지 않는 내부 기능, UI 미세 조정·버그 수정 같은 소규모 개선, 인프라 변경일 때. (이 경우 명령이 먼저 "건너뛸까요?"라고 물어봅니다.)

무엇을 해주나요#

문서 두 개가 만들어집니다.

  • docs/gtm-(프로젝트이름).md — 출시 전략 문서. 제품을 알리고 파는 방식(GTM), 누구를 노릴지(ICP), 어떤 메시지로 말할지가 정리되어 있습니다.
  • docs/analytics-plan-(프로젝트이름).md — 출시 후 측정 계획. 무엇을 실험하고(A/B 테스트), 사용자 그룹별로 어떤 지표를 추적할지가 담깁니다.

여기에 더해, 출시 전에 챙겨야 할 일들을 정리한 출시 체크리스트도 함께 만들어집니다.

이 두 문서는 만들어진 뒤 PR 로 올라가 기본 브랜치에 합쳐집니다 — 기획 단계 문서를 5단계(Breakdown)에서 합쳤던 것과 같은 방식입니다. 파이프라인이 끝났을 때 어느 문서도 작업하던 컴퓨터 한 대에만 남아 있지 않게 하려는 것입니다.

어떻게 쓰나요#

# 기본 (출시 전략 + 측정 계획 전체)
/cc-product:launch

# 출시 전략(GTM)에만 집중
/cc-product:launch --focus gtm

# 측정 계획(analytics)에만 집중
/cc-product:launch --focus analytics

--focus를 붙이면 한쪽에만 집중할 수 있고, 생략하면 전체(all)를 진행합니다.

안에서 무슨 일이 벌어지나요#

크게 두 가지 일을 차례로 진행하고, 마지막에 하나로 정리합니다.

  1. 출시 전략 세우기 — 어떤 방식으로 제품을 알리고 팔지(제품 주도 vs 영업 주도), 어떤 채널과 일정으로 출시할지 정합니다. 이어서 가장 이상적인 고객이 누구인지(ICP)와 첫 타깃 고객층을 정의하고, 그들에게 전할 핵심 메시지·한 줄 소개(엘리베이터 피치)·채널별 메시지를 다듬습니다.
  2. 측정 계획 세우기 — 출시 후 무엇을 비교 실험할지(A/B 테스트 가설·성공 지표·필요 표본 수)를 설계하고, 사용자 그룹(코호트)별로 어떤 지표를 어떻게 추적할지 정합니다.

마지막으로 이 두 결과를 하나의 문서로 통합하고, 출시 체크리스트를 만든 뒤, 그 문서들을 PR 로 올려 기본 브랜치에 합치고 마무리합니다.

끝나면 다음은?#

출시 전략과 측정 계획이 파일로 저장되고 그 PR 이 합쳐지면, 이 파이프라인은 완료(completed) 상태가 됩니다. 전체 프로젝트 요약 리포트가 출력되며, 1단계 조사부터 7단계 출시까지의 여정이 마무리됩니다.

⚙️ 상세 옵션·실행 명세 (개발자 / AI 에이전트용)

Triggers#

  • When launch preparation is needed after Development completion
  • When GTM strategy and marketing messages need to be established

Usage#

/cc-product:launch
/cc-product:launch --focus gtm
/cc-product:launch --focus analytics

Options#

OptionDefaultDescription
--focusallFocus area (gtm, analytics, all)

Skip Conditions#

This stage can be skipped in the following cases:

  • Internal features (not exposed to users)
  • Minor improvements (UI tweaks, bug fixes)
  • Infrastructure changes

User confirmation is requested when skipping.

Prerequisites#

  • Development stage completed
  • Deployable code exists

Execution Flow#

Phase 1: GTM Strategy#

Source: cc-product

  1. GTM Motion (gtm-motion)

    • Product-Led vs Sales-Led decision
    • Channel strategy
    • Launch timeline

  2. ICP Definition (icp-definition)

    • Ideal Customer Profile definition
    • Segment characteristics
    • Initial target segment

  3. Messaging Framework (messaging-framework)

    • Positioning statement
    • Elevator pitch
    • Channel-specific message variants

Phase 2: Analytics Plan#

Source: cc-product

  1. A/B Test Design (ab-testing)

    • Test hypotheses
    • Variant design
    • Sample size calculation
    • Success metrics

  2. Cohort Analysis (cohort-analysis)

    • Cohort definition
    • Tracking metrics
    • Analysis query design

Phase 3: Artifact Integration#

  • Integrated document of GTM strategy + analytics plan
  • Launch checklist generation

Phase 4: Launch Docs PR#

Source: cc-product (references/helpers.md → Publish Pipeline Docs PR — same protocol the breakdown stage uses for the planning documents; not restated here)

  • Call the helper with stage_set = launch and scope = launch
  • These are the documents generated after the breakdown stage's publication point, and they are the last ones the pipeline writes. Without this phase they would be the only pipeline documents that never reach the default branch — launch is gateless, so nothing downstream would notice
  • launch is gateless, so the helper judges it by status (step 2b) rather than a verdict; a skipped launch stage wrote no documents and therefore produces no PR
  • Degradation is recorded and reported exactly as in the breakdown stage — the pipeline is still marked completed, but a document that did not land is named in the final report

Artifacts#

docs/gtm-{slug}.md             # GTM strategy document
docs/analytics-plan-{slug}.md  # Analytics plan
  • Launch docs PR (docs/{slug}-launch → default branch, squash-merged), number recorded at stages.launch.docs_pr

After Completion#

  • .pipeline/{slug}.yaml full pipeline set to completed
  • Confirm stages.launch.docs_pr is merged, or that its degradation reason is recorded — a completed pipeline whose last documents never left the working tree is a false completion
  • Full project summary report output
  • Artifact list cleanup