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"

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).