菜单
Use after a feature or product launch to formally close the cycle: validate the original hypothesis, analyze which metrics moved, document learnings, and decide what to do next. Triggers on: "출시 후 회고", "런칭 결과 분석", "피처 성과 리뷰", post-launch review",
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/newkayak12/claude-skills --skill post-launch-retrospective命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
| name | post-launch-retrospective |
| effort | high |
| description | Use after a feature or product launch to formally close the cycle: validate the original hypothesis, analyze which metrics moved, document learnings, and decide what to do next. Triggers on: "출시 후 회고", "런칭 결과 분석", "피처 성과 리뷰", post-launch review", |
| license | MIT |
| metadata | {"author":"wondelai","version":"1.0.0"} |
| scenarios | ["We shipped the feature 3 weeks ago — help me run a post-launch retro.","출시 후 회고를 어떻게 체계적으로 진행하면 될까?","Our activation metric didn't move after the launch — which type of failure is this?","런칭 결과를 분석해서 다음 사이클에 반영할 러닝카드를 만들어줘.","How do I tell if poor metrics are a launch problem vs. a product problem?","피처 가설이 맞았는지 틀렸는지 정리해줘."] |
| compatibility | {"recommended":["think-tool"],"optional":["mcp-reasoner"],"remote_mcp_note":"think-tool이 있으면 런치 실패 유형(론치 실패 vs. 가설 실패 vs. 측정 실패)을 구분하는 데 도움이 됩니다. Claude 설정 → MCP Servers에서 remote SSE 엔드포인트를 추가하세요."} |
A structured evaluation process for feature and product launches — validating the original hypothesis, analyzing metric movement, documenting learnings, and connecting results to the next cycle.
A launch without a retrospective is an experiment without a conclusion. Most teams move directly from launch to the next item on the roadmap. This creates an organization that ships without learning — the same bets get placed repeatedly because no one recorded what the last one taught.
The retrospective closes the Build-Measure-Learn loop. It answers: "Was our hypothesis right? What actually moved? Why? What do we now believe? What does this mean for what we build next?"
A critical distinction: Launch failure (low adoption, poor rollout, messaging missed) is different from product-market fit failure (we built the right thing poorly) is different from hypothesis failure (our assumption about the problem or solution was wrong). The retro must distinguish these — they imply different responses.
When a user asks to run a post-launch retro, produce:
When a user asks to evaluate their retro practice, rate 0-10:
Before running the retrospective, confirm you have:
../prd-development/SKILL.md)../go-to-market-planning/SKILL.md)Anchors the retro to what was actually delivered — not what was planned. Scope changes between design and launch are common and often explain metric gaps.
Feature/release name: [name]
Launch date: [date]
What we planned to ship: [original scope from PRD]
What actually shipped: [actual scope]
Scope delta: [what was cut, deferred, or added and why]
Target audience: [who was this released to — all users, a segment, a cohort?]
Rollout method: [full release / phased / feature flag / A/B / beta group]
This is the evidence section. Be precise. Compare against baseline and against the original success metric definition.
For each metric in your success criteria:
Metric: [metric name]
Baseline (pre-launch): [value]
Target (from PRD/hypothesis): [value]
Actual (post-launch): [value]
Delta: [absolute and relative change]
Statistical significance: [if A/B test — p-value and confidence interval]
Time window: [measured over what period?]
Confounds: [anything else that changed during this period that could explain the movement?]
Metrics table format:
| Metric | Baseline | Target | Actual | Result |
|---|---|---|---|---|
| [metric 1] | [value] | [value] | [value] | Hit / Missed / Partial |
| [metric 2] | [value] | [value] | [value] | Hit / Missed / Partial |
Important: Also document metrics that were NOT in the success criteria but moved — these often contain the most useful learning. Negative side effects (other metrics that dropped) must be documented here.
This is the most important section. It is also the section most likely to be skipped or written as vague platitudes ("we learned we should communicate better").
For each major learning:
LEARNING: [one sentence — a specific, revisable belief about users, the product, or the process]
Evidence: [what data or observation supports this belief?]
Confidence: High / Medium / Low
Type: Hypothesis validation / User behavior discovery / Process insight / Technical finding
Implication: [What should we do differently or next because of this?]
Learning types and what they imply:
| Learning Type | Implication |
|---|---|
| Hypothesis confirmed | Increase confidence in this bet; use as evidence in prioritization |
| Hypothesis disconfirmed | Update the assumption map; don't repeat this bet without new evidence |
| User behavior unexpected | Flag for follow-up research (../customer-research-synthesis/SKILL.md) |
| Metric moved but wrong segment | Revisit targeting; consider segment-specific variants |
| Process failure (not product) | Document in team norms; retro is not a product learning |
This section should be brutal. Vague answers ("better communication") are a waste of the retro. Specific answers ("we should have done a 10% rollout before full release because we didn't catch the edge case in the invoice calculation") change how the team works next time.
Structure for each item:
What happened: [specific event or decision]
Impact: [what did this cause?]
What we'd do instead: [specific, actionable alternative]
Who owns this change: [if a process change — who is responsible for implementing it?]
Common retrospective findings (prompts if the team is stuck):
../go-to-market-planning/SKILL.md) address the right audiences?The core test of the retrospective.
Original hypothesis:
"We believed [doing X] for [user Y] would result in [outcome Z].
We would know we were right when [metric M reached level L]."
Validation result:
[ ] Confirmed — metric hit, directional signal strong
[ ] Partially confirmed — metric moved but below target OR only for a subset of users
[ ] Disconfirmed — metric did not move or moved in the wrong direction
[ ] Inconclusive — insufficient data (small sample, too short a window, confounds)
If disconfirmed or partially confirmed:
Which assumption was wrong?
[ ] We misidentified the user need (problem assumption)
[ ] We built the wrong solution for a real need (solution assumption)
[ ] The need exists but this user segment doesn't have it at scale (segment assumption)
[ ] The solution was right but the execution was poor (launch/quality failure)
[ ] External factors masked the result (confound)
基于 SOC 职业分类