| 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 엔드포인트를 추가하세요."} |
Standing Mandates
- ALWAYS have the original hypothesis and pre-launch success criteria in hand before starting.
- ALWAYS distinguish between launch failure, hypothesis failure, and measurement failure before drawing conclusions.
- NEVER attribute poor metrics to a single cause without ruling out alternatives.
- NEVER run the retro without a clear decision on what to do next — iterate, pivot, or stop.
Post-Launch Retrospective Framework
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.
Core Principle
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.
Agent Output
When a user asks to run a post-launch retro, produce:
- Hypothesis validation check — what was predicted vs. what happened
- 4-section retro document — What We Shipped / What Moved / What We Learned / What We'd Do Differently
- Failure type diagnosis if metrics missed (launch / PMF / hypothesis failure)
- Learning card for the team wiki (portable, feeds next cycle)
- Next step recommendations — explicit handoffs to prioritization or research
When a user asks to evaluate their retro practice, rate 0-10:
- 9-10: Every launch has a retro; original hypothesis is documented and explicitly validated; learnings feed the next cycle's inputs
- 7-8: Retros happen but are informal; hypothesis wasn't written before launch; "it did well" is the standard of success
- 5-6: Metrics are reviewed but causality is not examined; team moves on quickly
- 3-4: Post-launch review = checking if DAU went up; no hypothesis to validate
