/feature-results - Post-Launch Analysis
Document feature results and capture learnings.
Quick Start
/feature-resultsThen provide:
- Feature name and ship date
- Original hypothesis (or I'll pull it from your PRD)
- Actual results (metrics, or I'll query your analytics MCP)
I'll generate a results doc with: executive summary, results vs targets, root cause analysis (if missed), segment breakdown, estimate calibration, stakeholder communication guidance, and concrete next steps.
Output: Saved to thoughts/shared/pm/analyses/feature-results-[name]-[date].md Time: ~10 min with data ready, ~20 min if we need to dig
Pre-Launch Detection
Before generating a results analysis, verify the feature has actually shipped.
Check for launch signals:
- Does the PRD in
thoughts/shared/pm/prds/show status "Shipped" or "Launched"? - Does the PM mention actual results data (not projections)?
If the feature hasn't launched yet:
It looks like [feature] hasn't shipped yet. Post-launch analysis works best with real data.
For pre-launch work, you might want:
- `/feature-metrics` - Define what you'll measure before launch
- `/impact-sizing` - Estimate expected impact
- `/experiment-decision` - Plan your A/B test or rollout
- `/launch-checklist` - Make sure you're ready to ship
Want to proceed anyway (e.g., analyzing a soft launch or pilot), or switch to one of these?When to Use
- After A/B test completes
- After feature reaches full rollout
- During quarterly reviews
- For portfolio analysis
Quick Start Prompt
When PM types /feature-results, respond:
Let's document the results of your feature launch.
Tell me:
1. What feature shipped?
2. What were the original goals/metrics?
3. What actually happened?
I'll help you create a results doc that captures outcomes and learnings.Results Doc Structure
1. Executive Summary
- One paragraph: What shipped, did it work, what's next
2. Original Hypothesis
- What we expected to happen
- Why we believed it
3. Results
- Primary metric: Target vs. Actual
- Guardrail metrics: Any issues?
- Unexpected findings
4. Analysis
- Why did results occur?
- What surprised us?
- What didn't we anticipate?
5. Learnings
- What would we do differently?
- What should we apply elsewhere?
6. Next Steps
- Keep / Iterate / Kill?
- Follow-up experiments
- Related opportunities
Output Template
# Feature Results: [Feature Name]
**Ship Date:** [Date]
**Analysis Date:** [Date]
**Owner:** [PM Name]
---
## Executive Summary
[1-2 sentences: What shipped, key result, recommendation]
**Verdict:** [Ship to 100% / Iterate / Kill]
---
## Original Hypothesis
**If we** [built X],
**then** [Y would happen],
**because** [Z assumption].
**Target:** [Primary metric] would improve by [X%]
---
## Results
### Primary Metric
| Metric | Baseline | Target | Actual | Verdict |
| ------ | -------- | ------ | ------ | ---------- |
| [Name] | [X] | [Y] | [Z] | [Hit/Miss] |
### Statistical Significance
- Sample size: [N]
- Confidence level: [X%]
- P-value: [X]
### Guardrail Metrics
| Metric | Acceptable Range | Actual | Status |
| -------- | ---------------- | -------- | ------------ |
| [Metric] | [range] | [actual] | [OK/Warning] |
### Unexpected Findings
- [Finding 1]
- [Finding 2]
---
## Analysis
### Why These Results?
[Explain the underlying reasons for the results]
### What Surprised Us?
[Things we didn't expect]
### Segment Breakdown
| Segment | Result | Notes |
| ----------- | ------- | --------- |
| [Segment 1] | [+/-X%] | [insight] |
| [Segment 2] | [+/-X%] | [insight] |
---
## Learnings
### What Worked
- [Learning 1]
- [Learning 2]
### What Didn't Work
- [Learning 1]
- [Learning 2]
### Apply Elsewhere
- [Insight that applies to other features]
---
## Next Steps
**Recommendation:** [Ship / Iterate / Kill]
**If shipping:**
- [ ] Roll out to 100%
- [ ] Monitor for [X] weeks
- [ ] Update documentation
**If iterating:**
- [ ] [Specific change 1]
- [ ] [Specific change 2]
- [ ] Re-run experiment
**If killing:**
- [ ] Document why
- [ ] Rollback plan
- [ ] Communicate to stakeholders
---
## Appendix
- [Link to experiment dashboard]
- [Link to original PRD]
- [Link to detailed data]Root Cause Analysis
When results miss targets, diagnose using this framework:
Discovery Problem (Users don't know it exists)
- Check: Feature awareness rate, in-app visibility, announcement reach
- Common causes: Buried in UI, no onboarding tooltip, weak announcement
- Fix: Improve discovery through tooltips, email campaign, in-app prompts
Quality Problem (Users try it but it doesn't work well)
- Check: Error rates, completion rates, time-on-task, feedback sentiment
- Common causes: Bugs, poor UX, confusing workflow, slow performance
- Fix: Fix bugs, simplify UX, improve performance
Relevance Problem (Users try it but it doesn't solve their problem)
- Check: Use case analysis, segment breakdown, feature-problem fit
- Common causes: Wrong target audience, edge cases not handled, misaligned with actual needs
- Fix: Narrow targeting, add missing use cases, revisit problem definition
Frequency Problem (Users use it once but don't come back)
- Check: Repeat usage rates, habit formation metrics, triggers for return
- Common causes: Not integrated into daily workflow, one-time value, no triggers
- Fix: Add recurring value hooks, notifications, integration with other workflows
Estimate vs Actual Calibration
| Metric | Original Estimate | Actual Result | Accuracy | | ------------------ | -------------------- | ------------- | ---------------------- | | [Primary metric] | [From impact-sizing] | [Actual] | [Over/Under by X%] | | [Secondary metric] | [From impact-sizing] | [Actual] | [Over/Under by X%] | | [Guardrail metric] | [Expected range] | [Actual] | [Within/Outside range] |
Calibration insight: [Are we consistently over/under-estimating? By how much? What should we adjust for next time?]
Historical calibration pattern:
- Look at past 3-5 feature results. If we consistently over-estimate by 30-50%, apply a discount factor to future impact-sizing.
- If we consistently under-estimate, we may be too conservative or missing amplification effects.
- Track this over time to improve estimation accuracy.
Segment Breakdown Guidance
Always analyze results across these default segments. Segment analysis often reveals that an overall miss is actually a win for one segment and a miss for another.
| Segment Dimension | Why It Matters | | --------------------------------------------- | -------------------------------------------------------------------- | | New vs existing users | New users may not find the feature; existing users may resist change | | Plan tier (Free/Team/Business/Enterprise) | Feature value often varies dramatically by tier | | Company size | Small teams adopt differently than large orgs | | Power users vs casual users | Power users may love it; casual users may be confused | | Geographic region (if applicable) | Cultural, language, and connectivity differences |
Segment analysis template:
| Segment | N (sample) | Primary Metric | vs Target | Insight | | -------------- | ---------- | -------------- | --------- | ------- | | New users | [N] | [result] | [+/-X%] | [why] | | Existing users | [N] | [result] | [+/-X%] | [why] | | Free tier | [N] | [result] | [+/-X