# Decision Playbook

> 9 quick-reference decision frameworks from CEO Bible — when to double down, pivot, hire, kill features, diagnose low conversion. For deep multi-phase analysis of a specific decision, use strategic-review instead.

- Skill: `codealive-ai/decision-playbook` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add codealive-ai/decision-playbook`
- Raw SKILL.md: https://api.skillmd.com/api/skills/codealive-ai/decision-playbook/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: CodeAlive-AI (https://skillmd.com/u/codealive-ai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/codealive-ai/decision-playbook

---


# Decision Playbooks (CEO Bible Section I)

When the founder faces a strategic decision, apply the corresponding playbook.

---

## 1. When to Double Down on a Segment

Only when all three proofs converge:
- **Pain proof:** same trigger/problem/workaround across multiple conversations
- **Value proof:** this segment reaches TTFV faster and retention is better
- **Repeatability proof:** recent wins look alike: same buyer, same objections, same onboarding

**Actions:** Rewrite homepage/deck -> publish proof asset -> re-score PQL traffic -> pause non-core exploration for 4-6 weeks.

---

## 2. When to Change ICP

Change when:
- Problem is real, but no budget or owner at the current buyer
- Segment requires too much education
- Activation is slow, retention is weak despite support
- Another segment is clearly easier to message, close, and retain

**Don't change** after one bad month. **Do change** when multiple types of evidence align.

---

## 3. When to Change Positioning

Change when:
- People use and stay in the product
- BUT top-of-funnel response, call-to-next-step, demo resonance are weak
- Objections sound like confusion, not rejection

**Action:** Interview recent signups -> capture exact words -> draft new messaging -> test comprehension -> validate quantitatively.

---

## 4. When to Kill a Feature

Kill/freeze when ALL of these are true:
- Target-cohort usage is low
- Doesn't improve activation, retention, win rate, or outcome attainment
- Adds onboarding or roadmap complexity
- Demand from one noisy account, not from wedge

**Exception:** keep if clear unlock for wedge.

---

## 5. When NOT to Scale Sales

Do NOT scale if:
- Can't explain how the last 5 deals happened
- Don't have ~10-25 real customers or equivalent repeatability
- Onboarding is still founder/engineer-heavy and bespoke
- Retention/health is weak
- Buyers love demos but don't achieve durable usage
- Every win depends on founder charisma or heroic customization

---

## 6. When CEO Must Personally Handle Sales

CEO sells personally when:
- ICP, message, buyer, objections are still in discovery
- Product requires deep technical credibility
- Pricing is still being explored
- ROI proof is still being designed
- Key deals still teach the company something strategic

Even after the first sales hire — CEO stays in important/strategically revealing deals.

---

## 7. When to Hire First Salesperson / Marketer / Product Person

### First Salesperson
When: repeatability signal exists + founder is the bandwidth bottleneck + deals are understandable + retention is not broken.
Prefer: player-coach / technical seller, NOT big-company VP Sales.

### First Marketer
When: one narrative works + one ICP is clear + 1-2 channels show signal + the job is scaling execution, not inventing market.
**NOT** to discover ICP or write the first real message.

### First Product Person
When: founder already has deep market understanding + customer signal volume overwhelms + engineering trade-offs are rising.
**NOT** to replace founder judgment pre-PMF.

---

## 8. When a Pivot is Justified

Pivot when one of three proofs is structurally broken across multiple experiment cycles:
- **Pain broken:** nice but no urgency, budget, workaround, or owner
- **Value broken:** problem real but users don't reach meaningful outcomes
- **Repeatability broken:** some buy, but every sale/implementation/renewal is bespoke

**Pivot hierarchy:**
1. Change **persona** first (if workflow/value right but wrong user cares)
2. Change **problem/promise** (if capability useful but message wrong)
3. Change **product/workflow** (if market right but users don't get value)
4. Change **category/direction** (only when 1-3 exhausted)

---

## 9. Diagnosing "Low Conversion"

| Where low | Most likely problem | Inspect first |
|---|---|---|
| Traffic -> signup | Positioning / channel / trust | Language-market fit, source quality, proof, CTA |
| Signup -> activation | Product / onboarding / TTFV | Steps to first value, templates, friction |
| Activation -> paid | Outcome proof / buyer / pricing | Is value clear? Right buyer? Value-based pricing? |
| Paid -> retained | Problem frequency / workflow embed | Job important + recurring? Product in workflow? |
| Retained -> expansion | Narrow value / weak multi-user | Team hooks, second use case, packaging |

**AI-era extra:** If user-level love strong but enterprise close rate weak -> inspect trust/compliance/procurement readiness.

---

## How to Use

When the founder describes a situation:
1. Identify which playbook is relevant
2. Apply the framework to current [YOUR_PRODUCT] data
3. Give a concrete recommendation: action + timeline + what to measure
4. Log the decision to `memory/YYYY-MM-DD.md` and update `MEMORY.md` if needed

Follow output preferences from USER.md (language, format, platform constraints).