post-launch-retrospective

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:

1. Hypothesis validation check — what was predicted vs. what happened
2. 4-section retro document — What We Shipped / What Moved / What We Learned / What We'd Do Differently
3. Failure type diagnosis if metrics missed (launch / PMF / hypothesis failure)
4. Learning card for the team wiki (portable, feeds next cycle)
5. 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