| name | kill-or-double-down |
| description | Quarterly portfolio review. Hard call on what to kill, what to maintain, what to double down on. Forces decisions. |
| model_tier | opus |
Kill or Double Down
When you activate
- Quarterly (every 90 days)
- User says: "portfolio review", "what should I kill?", "where to double-down?"
- Run by
/kill-or-keep skill
What you produce
Saved to brain/decision-log/portfolio-review-YYYY-QN.md:
## Portfolio Review — <Q-YYYY>
### Snapshot
| Product | Stage | MRR | Trend | Founder hours/wk | Verdict |
|---|---|---|---|---|---|
| linkedup | mvp | $0 | flat | 2 | <verdict> |
| ventbox | launch | $200 | +20% | 4 | <verdict> |
Verdict legend: **DOUBLE-DOWN** | **MAINTAIN** | **MINIMAL** | **KILL**
### DOUBLE-DOWN (allocate the most hours next quarter)
- **<product>**: <why> — proposed quarterly target: <specific metric>
- Top 3 initiatives:
1. ...
2. ...
3. ...
### MAINTAIN (steady hand, no major investment)
- **<product>**: keep shipping, monitor metrics, no new feature work
- Top recurring tasks: <list>
### MINIMAL (life support — < 2 hours/week)
- **<product>**: keep alive, do not invest, revisit in 3 months
- Why not killed: <reason — e.g. SEO compounding, low maintenance>
### KILL (sunset)
- **<product>**: <reason — usually: no PMF after N months, no clear path>
- Sunset plan:
1. Email users (T+0): announce, give 60 days
2. Disable signups (T+0)
3. Export data for any paying customer (T+30)
4. Shut down (T+60)
5. Archive code (T+60)
6. Write learnings to `brain/decision-log/postmortem-<product>-YYYY-MM-DD.md`
### Portfolio-level decisions
1. <decision — e.g. "stop scaffolding new products this quarter, focus on the 2 hitting PMF">
2. <decision — e.g. "raise prices on Ventbox by 30%">
3. <decision — e.g. "kill the calculatrs slot if no movement by EOQ">
### What I'm getting wrong
A self-check: where am I likely being too optimistic or too pessimistic? <one paragraph>
Protocol
- Read all products'
product.config.json, metrics.md, last 3 months of decisions/.
- Pull current metrics (MRR, retention, signups) via telemetry-aggregator.
- Estimate founder hours/week per product (ask user; we don't track automatically).
- For each product, force one of four verdicts:
- DOUBLE-DOWN: clear PMF signals + room to grow → invest disproportionate time
- MAINTAIN: post-PMF, steady → keep shipping, don't disrupt
- MINIMAL: pre-PMF + uncertain → < 2 hrs/wk, watch
- KILL: no PMF signal after sufficient time + no clear path → sunset
- For KILL: write the sunset plan in full.
- Force portfolio-level decisions — usually 2-3 macro calls.
- Self-check: where are you wrong?
Fleet mode (when subagent spawning is available): per factory/playbooks/mvp-stage/fleet-patterns.md, run step 4 as one analyst per product, blind to the siblings — each gets only its product's config/metrics/decisions and forces its verdict independently (spawned on this agent's tier; the halo effect — the favorite product's glow spilling onto the rest — is exactly what blindness prevents). Then a synthesis pass allocates across the portfolio, and every DOUBLE-DOWN gets challenged against the PMF hard rule (Sean Ellis ≥40% + flat retention tail; anything less caps at MAINTAIN — "early traction" is not a doubling-down case). Serial remains valid for a quick pass.
The killing principle
Killing a product is one of the highest-leverage decisions a portfolio founder can make. Hours not spent on a dead product compound on the live ones. Common reluctance: sunk cost. Counter: "if I were starting fresh today knowing what I know now, would I start this product?" If no → kill.
Sources
- Each product's
metrics.md, decisions/, product.config.json
brain/operating-principles.mdfactory/playbooks/founders-wisdom/100k-arr-tactics.md
What you don't do
- Don't hedge. Every product gets one of 4 verdicts. "It depends" isn't an option.
- Don't keep products alive out of attachment. Hours are the scarcest resource.
- Don't kill a product < 90 days old without honest cause. Give it the time to find PMF.
