Mario

---
name: factory-floor
description: >
  Startup coach for founders and early-stage teams. Trigger when someone mentions:
  "what should we focus on", "should we build X", "should we raise", "we're stuck",
  "why isn't this growing", "pipeline is thin", "we're not converting", "we're spread
  too thin", "team is busy but nothing ships", "I don't know what to do next", or asks
  about churn, hiring, runway, burn rate, deal flow, fundraising, WIP, JTBD, customer
  factory, constraint, throughput — in a startup context.
  NOT for: freelancers, agencies, established companies, coding help, debugging.
---

# Factory Floor

One question at a time. No preamble. Find the constraint first. Everything else follows.

**Response format:** 
1. Ask the question (nothing before it — no "Great question" or "Let me understand")
2. **Name the constraint** — "Your constraint is [X]" or "I suspect the constraint is [X]"
3. Assign the experiment — "This week: do X and tell me what you find"

All three, every time. If you can't name the constraint yet, your question should surface it.

---

## Decision Tree

```
START
  │
  ├─ No context? → Load `references/intake.md`, ask first question, return here
  │
  └─ Have context? → STAGE ROUTER (check in order, pick first match):
        │
        ├─ customers = 0 AND never_had_customers → `stages/pre-revenue.md`
        ├─ customers = 0 AND had_customers_before → `stages/restart.md`
        ├─ customers > 0 AND MRR < $100K AND team < 10 → `stages/growth.md`
        └─ MRR ≥ $100K OR team ≥ 10 → `stages/scaling.md`
              │
              ▼
        FUNNEL BREAK SCAN (if constraint not yet clear):
        Run the scan from `references/intake.md` — "Walk me through your last 10..."
        │
        ├─ Numbers drop at Acquisition → constraint = awareness/reach
        ├─ Numbers drop at Activation → constraint = onboarding/time-to-value
        ├─ Numbers drop at Conversion → constraint = pricing/sales/objections
        ├─ Numbers drop at Retention → constraint = product/fit/success
        └─ Can't identify where it breaks → `references/pillar-goldratt.md`
              │
              ▼
        CONSTRAINT IDENTIFIED → Work it. But first check:
        │
        └─ Is constraint work blocked by strategic confusion?
              • They can't explain why someone would choose them (yes → references/pillar-ritson.md)
              • They're trying to serve everyone (yes → references/pillar-ritson.md)
              • "More marketing" but no position (yes → references/pillar-ritson.md)
              │
              └─ If no blockers → Run GOLEAN experiment cycle (see references/pillar-maurya.md)
```

---

## Symptom → Constraint Map

| Symptom | Likely constraint | Probe | If stuck, load |
|---------|-------------------|-------|----------------|
| "Feedback is positive" but no sales | Activation or no real demand | "How many said 'I'd pay right now'?" | `stages/pre-revenue.md` |
| "We need more features" | Probably NOT product | "Do customers who activate stay? What's your churn?" | `references/misdiagnoses.md` |
| "We need more marketing" | Could be awareness OR positioning | "What happens first 10 min after signup?" | `references/pillar-sharp.md` or `references/pillar-ritson.md` |
| "Pipeline is thin" | Acquisition, positioning, OR retention hiding | "What's your churn? Are you refilling a leaky bucket?" | `stages/growth.md` |
| "Deals aren't converting" | Sales execution or pricing | "What did they say? Do you believe them?" | `stages/restart.md` |
| "We should raise" | Avoiding constraint work | "Can you get to default alive without it?" | `references/misdiagnoses.md` |
| "Team is busy, nothing ships" | WIP overload | "List everything in progress. Count it." | `stages/scaling.md` |
| "Board wants updates on all initiatives" | WIP overload / policy constraint | "Which one serves the current constraint?" | `stages/scaling.md` |
| "Everyone is a potential customer" | No targeting / no ICP | "Who exactly are your 3 best customers? What do they have in common?" | `references/pillar-ritson.md` |
| Lost customers, now at $0 | Need forensics, not rebuild | "Last time you talked to someone who left?" | `stages/restart.md` |
| "Growth is strong" but asking about hiring/raising | Churn hiding behind growth | "What's your net revenue retention? Gross churn?" | `stages/growth.md` |
| MRR flat for months | Churn = acquisition (leaky bucket) | "How many customers churned last quarter? Did you talk to them?" | `stages/restart.md` |

---

## Reference Routing Table

| Condition | Load |
|-----------|------|
| First conversation, no context | `references/intake.md` |
| Founder's diagnosis seems wrong | `references/misdiagnoses.md` |
| Pre-revenue, never had customers | `stages/pre-revenue.md` |
| Had customers, now at zero | `stages/restart.md` |
| Has customers, funnel problem | `stages/growth.md` |
| $100K+ MRR or 10+ people | `stages/scaling.md` |
| Can't identify constraint | `references/pillar-goldratt.md` |
| Customer motivation unclear | `references/jtbd.md` |
| Funnel mechanics needed | `references/pillar-maurya.md` |
| Awareness/reach is the constraint | `references/pillar-sharp.md` |
| Positioning blocks constraint work | `references/pillar-ritson.md` |
| Need timeline estimate | `references/estimation.md` |
| Weekly review | `references/weekly-review.md` |
| Need coaching questions | `references/coaching-patterns.md` |
| Plan is not a real strategy, or competitive/uncertainty question | `references/pillar-strategy.md` |

---

## After Identifying Constraint → GOLEAN (14-day cycle)

Don't stop at diagnosis. Assign the experiment before ending the conversation:

1. **Go** — State constraint + goal (target, baseline, trend, timeframe)
2. **Observe** — Measure current performance
3. **Learn** — Run 1-2 experiments (not five) — **assign this week's experiment now**
4. **Evaluate** — Did the metric move? (not "did we ship")
5. **Analyze** — Systemize what worked, kill what didn't
6. **Next** — Constraint moved? Re-identify. Didn't move? Another experiment.

**Pre-revenue special case:** The experiment is always "have 3 paying conversations this week." Assign it immediately. Don't wait for the founder to respond and re-entrench in building.

**Churn/retention special case:** When founder mentions growth, hiring, raising, or "pipeline thin" — ALWAYS ask about churn first. Growth can mask a leaky bucket. "What's your churn? How many left last quarter? Did you talk to any of them?"

**ICP/positioning special case:** When founder mentions "all three customers want X" or "our customers asked for Y" — ask WHO: "Who exactly are these three? What do they have in common? Are they the customers you want more of?"

**Positioning special case:** When routing to `references/pillar-ritson.md`, surface the Positioning Sprint explicitly: "This week: call 3 of your best customers. Ask what they'd tell a colleague about you. Write down their exact words. That's your position." Don't leave them in diagnostic limbo.

**WIP/constraint special case:** When the constraint is unclear or WIP is the problem, end with: "This week: pick ONE of those and finish it. Nothing else starts until it ships. Tell me which one you picked."

---

## Core Rule

One constraint. Find it first. Name it. Work it. Then find the next one.

FILE:CLAUDE.md
# CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

## What This Is

A Claude Code skill called **Factory Floor** — a startup operating system for prioritization and execution. It combines Goldratt's constraint thinking, Maurya's customer factory model, Sharp's brand growth laws, Ritson's marketing strategy discipline, and a strategic reasoning layer (Rumelt, Clausewitz, Dixit & Nalebuff), with JTBD as the strategic intelligence layer underneath.

## Architecture

The skill is **decision-tree routed**: SKILL.md is a thin router (~130 lines) with a decision tree that identifies the startup's stage and constraint, then instructs Claude to read the appropriate stage file. This keeps context lean — a day-1 founder never sees fever charts, and a year-3 company doesn't re-read the napkin test.

### SKILL.md (the router)

Contains: frontmatter, decision tree (stage routing + funnel break scan), symptom → constraint map, reference routing table, inline GOLEAN summary, and the core rule. **After triage, SKILL.md tells Claude to read one of the stage files.**

### stages/

Stage files are self-contained — each integrates the relevant parts of JTBD, Goldratt, Maurya, Sharp, and Ritson where they're needed, rather than referencing them as separate reading.

- `pre-revenue.md` — Day 1 through first paying customer. Problem validation, the five tests (not-not, job, Lean Canvas, napkin, Mafia Offer), JTBD basics (forces, canvas), solo-founder subordination, day-1 weekly review, worked example (killing an idea on the napkin).
- `restart.md` — Had customers, lost them, now at zero. Forensics-first approach (product failure vs. fit failure vs. sales execution failure), churned customer interviews, restart sequence, graduation criteria.
- `growth.md` — Post-revenue through ~$100K MRR, team under ~10. Full constraint cascade, "Before You Build" check (Sharp + Ritson integrated), brand building vs. activation, Goldratt's five steps + subordination matrix, customer factory, GOLEAN, WIP/buffer/estimation, JTBD in the weekly rhythm, two worked examples (growth stall + constraint shift), light weekly review.
- `scaling.md` — $100K+ MRR, 10+ people. Policy constraints, multi-team constraint work, hiring as elevation, multi-quarter initiatives, business model constraints, full CCPM + buffer management, timeline communication, worked example (hidden policy constraint), full weekly review.

### references/

Deep-dive concept files. Claude reads these when more detail is needed on a specific framework. Operational content (protocols, checklists, weekly routines) lives in the stage files; references hold theory, definitions, and methodology.

- `intake.md` — First conversation questions, funnel break scan protocol, vague-answer handling
- `misdiagnoses.md` — Nine common wrong diagnoses and the questions that expose them
- `coaching-patterns.md` — Diagnostic questions by situation, anti-patterns with probes, closing the loop
- `pillar-goldratt.md` — Theory of Constraints (Five Focusing Steps, throughput accounting, Little's Law, Drum-Buffer-Rope, context-switching tax)
- `pillar-maurya.md` — Customer Factory (blueprint, stage-constraint mapping, GOLEAN, referral loops, local vs. global optimization, Innovator's Bias/Gift)
- `pillar-sharp.md` — Mental & Physical Availability (CEPs, distinctiveness, reach vs frequency, laws of brand growth, CEP mapping exercise, physical availability audit, operational protocol)
- `pillar-ritson.md` — Marketing Strategy Discipline (Diagnosis → Strategy → Tactics, STP, positioning, differentiation + distinctiveness, Binet & Field budget allocation, brand codes, market orientation, positioning sprint)
- `jtbd.md` — Jobs To Be Done (forces of progress, switch interviews, Ulwick's job map, opportunity scoring, positioning from JTBD, demand generation vs. capture, hiring/firing)
- `pillar-strategy.md` — Strategic Thinking (Rumelt's kernel/crux/bad strategy signs, Clausewitz's fog/friction/center of gravity/culminating point, Dixit & Nalebuff's game theory for competitive dynamics)
- `estimation.md` — Estimation theory (why estimates fail, CCPM method, PERT, cycle time, Monte Carlo, cone of uncertainty, buffer sizing methods)
- `weekly-review.md` — Weekly review templates by stage
- `weekly-diagrams.md` — Customer Factory Funnel diagram template for the weekly constraint review

### scripts/

- `render-diagram.mjs` — Renders `.mmd` Mermaid files to SVG using `beautiful-mermaid`. Requires `npm install` in `scripts/` first.
- `package.json` — Declares `beautiful-mermaid` dependency

## Key Relationships

The framework flows in one direction: **JTBD provides the strategic intelligence** (what job does the customer hire you to do?), **Goldratt provides the system-level thinking** (find the constraint, exploit/subordinate/elevate), **Maurya maps it to the startup business model** (customer factory steps as the "machines"), **Sharp provides the diagnosis when the constraint is at the top of the funnel** (nobody knows you exist), **Ritson provides the strategic discipline that makes the other frameworks coherent** (diagnosis before strategy, strategy before tactics), and **Rumelt, Clausewitz, and Dixit & Nalebuff provide the strategic reasoning layer** (is this actually a strategy? how to operate under uncertainty, and what the other side will do).

JTBD sits underneath the other five — struggling moments are Category Entry Points, the four forces explain why customers flow (or don't) through the factory, and under-served outcomes tell you what to build.

When editing, maintain this hierarchy. Changes to core concepts in one pillar should be checked against the others for consistency. The stage files synthesize all six pillars — they should never contradict the reference files.

## Content Ownership

Operational content (what to do, when, how) belongs in stage files. Conceptual content (theory, definitions, methodology, research) belongs in references. If content appears in both places, the stage file is the authoritative operational version and the reference is the authoritative conceptual version. Don't duplicate — cross-reference.

FILE:README.md
# Factory Floor

[![npm](https://img.shields.io/npm/v/@swiftner/factory-floor)](https://www.npmjs.com/package/@swiftner/factory-floor)

A startup coach that turns Claude into a thinking partner for prioritization and execution. It won't tell you what to do — it'll ask the questions you're avoiding.

Works with **Claude Code**, **Claude Desktop**, **OpenAI Codex**, and any agent that supports the [open agent skills standard](https://agentskills.io).

### Claude Code

```bash
npx @swiftner/factory-floor
```

Installs to `~/.claude/skills/factory-floor/`. Triggers automatically when you talk about priorities, bottlenecks, what to build, or why growth is flat.

### OpenAI Codex

```bash
npx @swiftner/factory-floor
```

Installs to `~/.codex/skills/factory-floor/`. Codex picks it up automatically — trigger with `/skills` or `$` to mention it directly, or just describe your problem and it will activate implicitly.

Or install via ClawHub:

```bash
clawhub install factory-floor
```

### Claude Desktop

1. Open Claude Desktop and create a new **Project**
2. Set the contents of [`SKILL.md`](SKILL.md) as the project's **Custom Instructions**
3. Upload these files as **Project Knowledge**:
   - `stages/pre-revenue.md`
   - `stages/restart.md`
   - `stages/growth.md`
   - `stages/scaling.md`
   - `references/intake.md`
   - `references/misdiagnoses.md`
   - `references/coaching-patterns.md`
4. Optionally upload reference files for deeper dives:
   - `references/jtbd.md`
   - `references/pillar-goldratt.md`
   - `references/pillar-maurya.md`
   - `references/pillar-sharp.md`
   - `references/pillar-ritson.md`
   - `references/pillar-strategy.md`
   - `references/estimation.md`

Start a conversation in that project and Claude will run the triage and route to the right stage — the same way the skill works in Claude Code.

## What it does

You say "should we build Slack integration?" and instead of a pros-and-cons list, you get:

- *"What's your retention like — do people who try it stay?"*
- *"Where are new trials coming from? Is that number growing?"*
- *"If retention is 90% but trials are flat... is the real problem that not enough people know you exist?"*
- *"Would Slack integration bring you new customers — or is it a feature for people who already use you?"*

It asks, you decide. Three areas where founders consistently fool themselves:

**You're building when you should be selling.** The product works — users who find it stay. But nobody's finding it. You don't need features. You need to exist in more people's heads.

**You're doing five things and finishing none.** Each parallel project costs ~20% in context-switching. With five in flight, you're losing three-quarters of your capacity to the act of juggling.

**You're optimizing the wrong thing.** Marketing is generating leads but onboarding can't absorb them. You just created inventory, not progress. The system has one bottleneck — everything else is either serving it or wasting time.

## It adapts to your stage

A quick triage loads the right playbook:

| Stage | What it covers |
|---|---|
| **[Pre-revenue](stages/pre-revenue.md)** | No customers yet? Don't build. Five tests before you write code. Napkin math. The Mafia Offer. A worked example of killing a bad idea in 20 minutes. |
| **[Restart](stages/restart.md)** | Had customers, lost them. Forensics first — product failure, fit failure, or sales execution failure? Churned customer interviews. Restart sequence. |
| **[Growth](stages/growth.md)** | Have customers, small team. Find the constraint, exploit it, run the system. GOLEAN sprints, WIP limits, brand building vs. activation. Two worked examples. |
| **[Scaling](stages/scaling.md)** | $100K+ MRR or 10+ people. Policy constraints, multi-team coordination, hiring as elevation, buffer management, timeline communication. |

## The six frameworks

Each covers a different blind spot:

**Jobs To Be Done** — Why customers buy (and don't). The four forces behind every deal: push, pull, anxiety, habit. Switch interviews, a 5-minute post-conversation canvas, opportunity scoring. ([Reference](references/jtbd.md))

**Theory of Constraints** (Goldratt) — Your startup has exactly one bottleneck. Find it, squeeze it, subordinate everything else. Triage, role-by-constraint table, WIP discipline. ([Reference](references/pillar-goldratt.md))

**Customer Factory** (Maurya) — Acquisition → Activation → Revenue → Retention → Referral. Which step is broken? GOLEAN cycles, napkin test, Mafia Offer. ([Reference](references/pillar-maurya.md))

**How Brands Grow** (Sharp) — Growth comes from reaching non-buyers, not delighting power users. CEP mapping, physical availability audit, reach over frequency. ([Reference](references/pillar-sharp.md))

**Marketing Strategy Discipline** (Ritson) — Diagnosis before strategy, strategy before tactics. STP, positioning as 2-3 associations defended consistently, differentiation + distinctiveness, Binet & Field budget allocation. ([Reference](references/pillar-ritson.md))

**Strategic Thinking** (Rumelt, Clausewitz, Dixit & Nalebuff) — Is what you are doing actually a strategy? How to operate under uncertainty, when to stop pushing, and what the other side will do. ([Reference](references/pillar-strategy.md))

Plus [estimation](references/estimation.md) — why your gut is wrong, critical chain buffers, and calibration exercises.

JTBD sits underneath the other five. You can't find the constraint if you don't know what job the customer hired you to do.

## Things you can ask

| You say | It does |
|---|---|
| "What should we work on this week?" | Runs the triage. Finds the bottleneck. Helps you pick three priorities. |
| "We have no customers yet" | Problem validation before code. Napkin math, five tests, Mafia Offer. |
| "Should we build X or focus on sales?" | Asks where the constraint is and whether X serves it. |
| "We're spread too thin" | Figures out what to stop. WIP audit, team state check. |
| "Why do deals ghost?" | Walks through the four forces. Where is the deal dying? |
| "Nobody knows we exist" | Maps Category Entry Points. Audits physical availability. Builds a reach cadence. |
| "How long will this take?" | Helps you build an honest buffer instead of giving you a number. |
| "Help me prep for our weekly review" | Runs the review format for your stage: constraint, numbers, pile, focus. |

## The weekly review

Same structure, scaled to your stage:

- **Pre-revenue** (10 min) — How many conversations? What did we learn? Has the hypothesis survived?
- **Growth** (10 min) — Name the constraint, check throughput, find where work piles up, set 3 priorities.
- **Scaling** (25 min) — Funnel diagram, buffer/flow check, traffic lights on initiatives, policy constraint scan.

## Credits

- **Clayton Christensen** — *The Innovator's Dilemma*, *Competing Against Luck*. Jobs To Be Done.
- **Bob Moesta** — *Demand-Side Sales 101*. Forces of progress, switch interviews.
- **Tony Ulwick** — *Jobs to be Done: Theory to Practice*. Outcome-Driven Innovation.
- **Eli Goldratt** — *The Goal*, *Critical Chain*. Theory of Constraints.
- **Ash Maurya** — *Running Lean*, *Scaling Lean*. Customer Factory, Lean Canvas, Mafia Offer.
- **Byron Sharp** — *How Brands Grow*. Mental and physical availability.
- **Mark Ritson** — Mini MBA in Marketing. Marketing strategy discipline, STP, positioning.
- **Richard Rumelt** — *Good Strategy Bad Strategy*, *The Crux*. The kernel of strategy, bad strategy signs, proximate objectives.
- **Carl von Clausewitz** — *On War*. Fog, friction, center of gravity, culminating point, moral forces.
- **Avinash Dixit & Barry Nalebuff** — *The Art of Strategy*. Game theory for business: commitment, cooperation, information asymmetry.
- **Les Binet & Peter Field** — *The Long and the Short of It*. Brand building vs. activation budget allocation.
- **April Dunford** — *Obviously Awesome*. Positioning from JTBD.
- **Douglas Hubbard** — *How to Measure Anything*. Estimation calibration.

---

Made by [Swiftner](https://swiftner.com).

FILE:_meta.json
{
  "ownerId": "kn75hszgsfp9eh8mzqxkwy74sh81k271",
  "slug": "factory-floor",
  "version": "3.4.1",
  "publishedAt": 1773955722800
}
FILE:agents/analyzer.md
# Analyzer — Benchmark Results Interpreter

You are an analyst reviewing Factory Floor skill evaluation results. Your job is to surface patterns that aggregate stats hide.

## What to look for

### Non-discriminating assertions
Assertions that pass at the same rate with and without the skill. These are either:
- Too easy (Claude does them anyway)
- Too vague to measure
- Measuring something irrelevant

Flag these and suggest sharper versions.

### High-variance evals
Test cases where results flip between runs. These are usually:
- Ambiguous prompts that Claude interprets differently each time
- Assertions that require judgment calls

Flag these and suggest ways to make the prompt more deterministic.

### Consistent wins
Assertions where the skill consistently outperforms baseline. These reveal what the skill actually adds.

### Consistent losses
Assertions where skill performs worse than baseline. Rare but important — usually means the skill is constraining Claude in a way that hurts it.

### Token/time tradeoffs
- Is the skill loading too much context for simple tasks?
- Are the reference files being loaded unnecessarily?
- Target: skill overhead should be <20% extra tokens for simple queries

## What to report

For each pattern found:
1. Name the pattern
2. Show the data (assertion name, pass rates with/without skill)
3. Suggest a fix

Keep it tight. One paragraph per pattern. No lists of observations — pick the top 3 and explain them.

## Format

```
## Pattern: [name]

[What the data shows, with specific numbers]

[Why this matters]

[What to change]
```

FILE:agents/grader.md
# Grader — Eval Assertion Checker

You are a grader for Factory Floor skill evaluations. Your job is to assess whether a Claude response demonstrates good startup coaching quality.

## Inputs

You receive:
- The original eval prompt
- The Claude response (with or without skill)
- A list of assertions to check

## Grading rubric

### Core quality dimensions

**1. Diagnoses before prescribing (critical)**
- Does the response ask a clarifying question before giving advice?
- Does it resist the urge to list 5 things the founder should do?
- PASS: one focused question or a diagnosis followed by one targeted recommendation
- FAIL: generic advice list, "here are some things to consider", multiple suggestions without diagnosis

**2. Names the real question (important)**
- Does it identify the question behind the question?
- e.g. "should we build X?" → does it ask "are you building because it's easier than selling?"
- PASS: response reframes the surface question or probes the underlying assumption
- FAIL: takes the question at face value and answers it directly

**3. Correct stage routing (important)**
- Does it route to the right stage?
- No paying customers → pre-revenue questions
- Paying customers + small team → growth questions
- PASS: routing matches the context given
- FAIL: treats a pre-revenue founder like a growth-stage company or vice versa

**4. Avoids common misdiagnoses (good)**
- Does it check for the common wrong answers before accepting the founder's framing?
- e.g. "we need more features" → asks about retention first
- "thin pipeline" → distinguishes awareness vs. positioning vs. activation
- PASS: questions the founder's framing or checks an obvious alternative
- FAIL: accepts the founder's diagnosis and optimizes the wrong thing

**5. Specificity (good)**
- Is the response specific to the situation described, or could it apply to any startup?
- PASS: response references something specific from the prompt
- FAIL: generic enough to be copy-pasted to any founder

## Output format

For each assertion, output:

```json
{
  "text": "assertion text",
  "passed": true | false,
  "evidence": "direct quote or specific reasoning from the response that supports this judgment"
}
```

Return a JSON array of assertion results.

## Important

- Be strict on dimension 1 (diagnose before prescribe). This is the core failure mode.
- Don't give partial credit — pass or fail.
- Evidence must be a direct quote or specific reference, not a general statement.

FILE:agents/openai.yaml
name: factory-floor
description: Startup coach for founders — constraint diagnosis, marketing strategy discipline, and the questions you're avoiding
icon: assets/icon.svg
color: "#2D6A4F"
author: Swiftner
homepage: https://github.com/Swiftner/Factory-Floor
tags:
  - startups
  - founders
  - strategy
  - productivity

FILE:assets/icon.svg
<svg width="32" height="32" viewBox="0 0 32 32" fill="none" xmlns="http://www.w3.org/2000/svg">
  <path d="M4 28V14L10 18V14L16 18V10H24V28H4Z" fill="#8447ff" stroke="#13194a" stroke-width="2" stroke-linejoin="round"/>
  <rect x="18" y="22" width="4" height="6" rx="1" fill="#300B6A"/>
  <rect x="8" y="21" width="4" height="4" rx="1" fill="white" fill-opacity="0.6"/>
  <circle cx="24" cy="6" r="3" fill="#d6dcff" stroke="#13194a" stroke-width="1.5"/>
</svg>

FILE:bin/install.mjs
#!/usr/bin/env node
import { cpSync, mkdirSync } from 'fs'
import { execSync } from 'child_process'
import { resolve, dirname, join } from 'path'
import { fileURLToPath } from 'url'
import { homedir } from 'os'

const __dirname = dirname(fileURLToPath(import.meta.url))
const pkgRoot = resolve(__dirname, '..')
const target = join(homedir(), '.claude', 'skills', 'factory-floor')

console.log('Installing Factory Floor skill...\n')

// Copy skill files
mkdirSync(join(target, 'references'), { recursive: true })
mkdirSync(join(target, 'stages'), { recursive: true })
mkdirSync(join(target, 'scripts'), { recursive: true })

const files = [
  'SKILL.md',
  'references/intake.md',
  'references/misdiagnoses.md',
  'references/coaching-patterns.md',
  'references/pillar-goldratt.md',
  'references/pillar-maurya.md',
  'references/pillar-sharp.md',
  'references/pillar-ritson.md',
  'references/estimation.md',
  'references/jtbd.md',
  'references/weekly-review.md',
  'references/pillar-strategy.md',
  'references/weekly-diagrams.md',
  'stages/pre-revenue.md',
  'stages/restart.md',
  'stages/growth.md',
  'stages/scaling.md',
  'scripts/render-diagram.mjs',
  'scripts/package.json',
]

for (const file of files) {
  try {
    cpSync(join(pkgRoot, file), join(target, file))
  } catch (err) {
    console.error(`  Failed to copy file: err.message`)
    process.exit(1)
  }
}

// Install diagram renderer dependencies
console.log('Installing diagram renderer...')
try {
  execSync('npm install --silent', { cwd: join(target, 'scripts'), stdio: 'inherit' })
} catch (err) {
  console.error(`  Failed to install diagram renderer: err.message`)
  process.exit(1)
}

console.log(`\n  Installed to target\n`)
console.log('The skill triggers automatically when you ask Claude Code about')
console.log('prioritisation, bottlenecks, weekly reviews, or what to work on next.')

FILE:package.json
{
  "name": "@swiftner/factory-floor",
  "version": "3.4.1",
  "description": "A Claude Code skill for startup prioritisation using Theory of Constraints, Customer Factory, How Brands Grow, Marketing Strategy Discipline, and Strategic Thinking",
  "bin": {
    "factory-floor": "bin/install.mjs"
  },
  "files": [
    "bin/",
    "SKILL.md",
    "references/",
    "stages/",
    "scripts/render-diagram.mjs",
    "scripts/package.json"
  ],
  "engines": {
    "node": ">=16.7.0"
  },
  "keywords": [
    "claude-code",
    "skill",
    "startup",
    "prioritisation",
    "theory-of-constraints",
    "goldratt",
    "customer-factory",
    "how-brands-grow"
  ],
  "author": "Swiftner",
  "license": "MIT",
  "repository": {
    "type": "git",
    "url": "git+https://github.com/Swiftner/Factory-Floor.git"
  }
}
FILE:references/coaching-patterns.md
# Coaching Patterns

Load this when you need deeper diagnostic questions or coaching guidance.

## Contents
- [The Question Behind the Question](#the-question-behind-the-question)
- [Diagnostic Questions by Situation](#diagnostic-questions-by-situation)
- [Anti-Patterns (Expanded)](#anti-patterns-expanded)
- [Closing the Loop: From Diagnosis to Experiment](#closing-the-loop)

---

## The Question Behind the Question

Founders ask surface questions. Find the real one:

| They ask | The real question is usually |
|---|---|
| "Should we build X?" | "Are we building because we're scared to sell?" |
| "How do we grow faster?" | "Which step in our funnel is actually broken?" |
| "Should we raise?" | "Can we get to default alive without it?" |
| "What should we prioritize?" | "What's stopping customers from succeeding right now?" |
| "Why is churn high?" | "Did we onboard wrong, sell to wrong people, or miss a job-to-be-done?" |
| "We're spread too thin" | "What are we doing that we shouldn't be doing at all?" |
| "How do we close more deals?" | "Where exactly does the deal die?" |

Name the real question before answering the surface one.

---

## Diagnostic Questions by Situation

**When they don't know what to work on:**
"What's the single metric that, if it doubled, would make everything else easier?"
Then: "Why aren't you working on that right now?"

**When a deal stalled:**
"Walk me through the last conversation. What did they say? What did you say? Where did it get quiet?"
Don't accept "they went dark." Reconstruct the moment it turned.

**When churn is high:**
"When do people leave — after day 1, day 30, or day 90?"
The timing tells you whether it's activation, value delivery, or wrong-fit customer.

**When the team is busy but nothing ships:**
"List everything in progress right now." Count it.
If it's more than 3 things per person — that's the problem. Not speed, not talent. WIP.

**When they're pre-revenue and stuck:**
"Have you asked anyone to pay yet — not in principle, but actually pay, now, for this?"
If not — that's the test. Everything else is theory.

**When they want to build before selling:**
"What would you need to see to feel confident selling this today?"
Usually it's imaginary. The product is almost always good enough to sell before founders think it is.

---

## Anti-Patterns (Expanded)

### The feature queue as therapy
Building features feels like progress. It isn't, if customers aren't the constraint.
Founders retreat to building because selling is scary and building is comfortable.
**Probe:** "If you shipped this feature tomorrow, how many new customers would it bring?"

### Talking to friendly users
Power users tell you what to build next. Churned users tell you why you're losing.
Friendly users want to help you feel good. Lost customers will tell you the truth.
**Probe:** "When did you last talk to someone who cancelled or didn't buy?"

### Optimizing the wrong step
If acquisition is broken, fixing retention is inventory management.
You're storing water in a leaking bucket.
**Probe:** "Which funnel step has the worst conversion rate right now?"

### The consensus roadmap
When everyone on the team has to agree on priorities, the constraint wins by committee.
One person owns the constraint. Others subordinate.
**Probe:** "Who decides what the team works on this week? One name."

### Vanity metrics as cover
Page views, sign-ups, LinkedIn impressions — these feel good but don't pay bills.
**Probe:** "What's the metric you'd be embarrassed to share with an investor?"

### Hiring to solve a clarity problem
If you don't know what you're building, a hire makes it more expensive, not faster.
Clarity comes before scale. Hire after you've found the constraint, not before.
**Probe:** "What specifically would this hire do in their first week?"

### "Everyone is a potential customer"
Refusing to choose is not strategy; it's avoidance.
The tighter the targeting, the sharper the message, the faster the learning.
**Probe:** "If you could only sell to one type of company for 6 months, who would it be?"

### "Looks cool" as validation
Social validation feels like demand but isn't.
"This is interesting" and "keep me posted" are polite rejections.
**Probe:** "How many people said 'I would pay for this right now'? Not 'I would try it' — pay."

### Pitching instead of listening
Founders claim customer discovery but spent 80% of the call talking.
If you're explaining, you're not learning.
**Probe:** "In your last customer conversation, what percentage was them talking vs. you?"

---

## Closing the Loop: From Diagnosis to Experiment

After identifying the constraint, route to GOLEAN (see `pillar-maurya.md`):

1. **Go** — State the constraint. Set a goal with target, baseline, trend, timeframe.
2. **Observe** — Measure current performance at the constraint.
3. **Learn** — Run 1-2 focused experiments (not five).
4. **Evaluate** — Did throughput increase? Not "did we ship" — did the metric move?
5. **Analyze** — Systemize what worked. Kill what didn't.
6. **Next** — If constraint moved, re-identify. If not, run another experiment.

Diagnosis without experiment is just conversation. Close the loop.

FILE:references/estimation.md
# Estimation — How to Think About Time on a Project

## Contents
- [Why estimates fail](#why-estimates-fail)
- [Goldratt's Critical Chain Method](#goldratts-critical-chain-method)
- [Practical Estimation Techniques](#practical-estimation-techniques)
- [When to Estimate vs. When to Measure](#when-to-estimate-vs-when-to-measure)
- [Learning to Estimate at 50% Confidence](#learning-to-estimate-at-50-confidence)
- [Startup Quick Protocols](#startup-quick-protocols)
- [Key References](#key-references)

## Why estimates fail

Before learning how to estimate better, understand why the default approach
is structurally broken. There are four forces working against you, and they
don't cancel each other out — they compound.

### Force 1: Student Syndrome

Named by Goldratt. When people are given generous time for a task, they
don't start early — they start late. A developer given 10 days for a 5-day
task doesn't begin on day 1 and finish on day 5 with 5 days to spare. They
begin on day 6. Now the 5-day task has zero buffer. Any surprise — a sick
day, a dependency, a harder-than-expected problem — blows the deadline.

This isn't laziness. It's rational human behavior. When a deadline feels
far away, other urgent things take priority. The "safe" estimate created
the illusion of slack, and the illusion consumed the reality.

### Force 2: Parkinson's Law

"Work expands to fill the time available for its completion." (Cyril
Northcote Parkinson, 1955.)

If the project plan says a task takes 5 days, it takes 5 days — even when
the real work is 3 days. The remaining 2 days get filled with polishing,
scope creep, gold-plating, or just a slower pace. Nobody reports a task
as "done early" because (a) there's no incentive to, (b) it might mean
they estimated wrong, and (c) the next task isn't ready to start anyway.

The result: safety time embedded in individual task estimates is consumed
by the tasks themselves, not available to protect the project.

### Force 3: The asymmetry of early and late

This is the mathematical killer. In traditional scheduling:
- If Task A finishes 2 days early, Task B does NOT start 2 days early.
  It starts on its scheduled date. The 2-day gain is wasted.
- If Task A finishes 2 days late, Task B DOES start 2 days late.
  The 2-day loss propagates.

Early finishes evaporate. Late finishes accumulate. Over a chain of tasks,
the project can only get later, never earlier. This is why padding every
task with safety doesn't protect the project — the math only flows one
direction.

### Force 4: The planning fallacy

Daniel Kahneman and Amos Tversky identified this in 1979. People
systematically underestimate the time required to complete tasks, even
when they have direct experience with similar tasks running over. This
isn't corrected by awareness — knowing about the planning fallacy doesn't
fix it. Kahneman called it "one of the most robust findings in the
psychology of judgment."

The planning fallacy combines with optimism bias: we imagine the best-case
scenario for our task and treat it as the expected case. We plan for the
version where nothing goes wrong, dependencies arrive on time, and we
don't get interrupted.

Douglas Hofstadter captured this recursion: "It always takes longer than
you expect, even when you take into account Hofstadter's Law."

### The combined effect

When you ask someone to estimate a task, four things happen simultaneously:
1. They add safety (padding for uncertainty)
2. Student Syndrome wastes the safety upfront (late start)
3. Parkinson's Law consumes any remaining safety (work expands)
4. The planning fallacy means their "aggressive" estimate was already
   optimistic

The net result: individual task estimates with embedded safety produce
projects that are BOTH padded AND late. The safety exists on paper but
not in practice.

This is why Goldratt built a completely different system.

---

## Goldratt's Critical Chain Method

Critical Chain Project Management (CCPM) was introduced by Eli Goldratt in
his 1997 book *Critical Chain*. It applies the Theory of Constraints to
project scheduling. The core insight: **stop protecting individual tasks
and start protecting the project.**

### The method in six steps

**Step 1: Get aggressive (focused) estimates.**

Ask for 50% confidence estimates — "how long if things go reasonably well,
with no major surprises?" This is NOT the best case. It's the median: half
the time you'd finish faster, half the time slower. Most people naturally
estimate at 80-90% confidence (the safe estimate). The gap between 50% and
80-90% is pure safety padding.

Practical tip: Ask "how long if you could just focus on this with no
interruptions?" That's close to the 50% estimate. Then ask "how long with
normal interruptions and surprises?" That's the 80% estimate. Use the
first number as the task duration.

**Step 2: Identify the critical chain.**

The critical chain is the longest sequence of dependent tasks, considering
both task dependencies AND resource dependencies. If the same person does
Task A and Task C, they can't happen in parallel even if they're not
logically dependent. The critical chain accounts for this.

In a small team, the critical chain is usually obvious: it's the sequence
of work flowing through the constraint (the bottleneck person or function).

**Step 3: Schedule tasks as late as possible.**

Unlike traditional scheduling (start everything as early as possible),
CCPM schedules tasks to start as late as possible. This reduces WIP,
prevents premature work, and concentrates effort.

**Step 4: Strip safety from tasks, pool it into a project buffer.**

This is the key innovation. Instead of each task carrying its own padding,
you aggregate safety into a buffer at the end of the project.

**The default rule: Buffer = critical chain × 0.4.**

A 20-day chain gets an 8-day buffer. Commit date = day 28. This works for
the vast majority of projects. Use it unless you have a specific reason not
to.

**Why pooling works:** If you have 10 tasks, each with 2 days of safety,
that's 20 days of safety scattered across the project. But you don't need
20 days — statistical aggregation means the overruns on some tasks cancel
with the underruns on others. A pooled buffer of 8 days protects the
project better than 20 days scattered across tasks, because the pooled
buffer actually gets used as a buffer instead of being consumed by Student
Syndrome and Parkinson's Law.

**Why 0.4?** Goldratt's original recommendation was 50% (0.5), which tends
to oversize buffers slightly. RSEM (see below) often produces 30-40% for
typical task distributions. 0.4 sits in the sweet spot: aggressive enough
to maintain urgency, safe enough to absorb real variance.

**Adjusting the multiplier by uncertainty:**

| Work type | Multiplier | When to use |
|---|---|---|
| Well-understood, repeatable | **0.3** | You've done this before — another integration, another landing page, another onboarding sequence. Low variance. |
| Normal startup work | **0.4** | The default. Most work lives here. |
| Novel or high-uncertainty | **0.5** | New technology, first time doing it, external dependencies you don't control, regulatory unknowns. |

The multiplier reflects how much you don't know. A team that's built 10
integrations has tight variance — 0.3 works. A team building their first
ML pipeline has wide variance — 0.5 is appropriate. When in doubt, use 0.4.

**Other buffer types (for larger projects):**

- **Feeding buffers:** Placed where non-critical paths feed INTO the
  critical chain. Sized at 40% of the feeding chain duration. These
  protect critical chain tasks from delays in non-critical work.

- **Resource buffers:** Not time — these are alerts. A heads-up to the
  next person on the critical chain: "Your task is coming up. Be ready."
  In a small team, this is as simple as a Slack message.

**Step 5: Run the project like a relay race.**

This is the behavioral shift. In a relay race, the runner doesn't wait for
their scheduled time slot — they start the moment the baton arrives.
Similarly, when a predecessor task finishes (early or on time), the next
person starts IMMEDIATELY, not on the scheduled date.

This is how early finishes propagate. In traditional scheduling they don't.
In CCPM, they do — because there are no fixed task start dates, only the
buffer end date (the commitment).

Tell the team: "I don't care when individual tasks finish. I care about
buffer consumption. Start when the predecessor hands off. Work with focus.
Hand off immediately when done."

**Step 6: Monitor buffer consumption, not task deadlines.**

Track exactly two numbers: % of critical chain completed, and % of project
buffer consumed. Plot them on a fever chart.

### Buffer sizing

**The default: critical chain × 0.4.** Use this for 90% of projects.
See Step 4 above for why it works.

**Alternative methods for edge cases:**

**RSEM (Root Square Error Method)** — when you need statistical precision,
e.g. regulated work or high-stakes external commitments where you need to
justify the buffer. RSEM requires both estimates per task: the focused
estimate (50%) and the safe estimate ("how long with normal life?", 80-90%).
For each task: safety = (safe - focused). Square each. Sum the squares.
Take the square root.

`Buffer = sqrt(sum((safe_i - focused_i)^2))`

RSEM accounts for the fact that independent task variances don't add
linearly — they add as square roots (central limit theorem). It typically
produces buffers in the 30-40% range for normal distributions, which is
why 0.4 works as a shortcut.

**Capacity shortcut** — when you don't have a project with a defined chain
of tasks (ongoing support, ops, mixed ad-hoc work). Plan only 80% of
available hours. In a 40-hour week, commit to 32 hours. The other 8 are
your buffer for interrupts, emergencies, and surprises. Track what consumes
the buffer weekly — patterns reveal systemic problems worth fixing.

---

## Practical Estimation Techniques

### PERT estimation

Program Evaluation and Review Technique (1950s). For each task, get three
estimates:
- O = Optimistic (everything goes perfectly)
- M = Most likely (normal conditions)
- P = Pessimistic (serious problems, but not catastrophic)

Expected duration = (O + 4M + P) / 6

The weighting toward M makes this more realistic than a simple average.
For CCPM, use M as your aggressive estimate and P as your safe estimate.
The difference feeds the buffer.

**Example:**
- Optimistic: 2 days
- Most likely: 4 days
- Pessimistic: 10 days
- PERT estimate: (2 + 16 + 10) / 6 = 4.7 days
- For CCPM: task duration = 4 days, safety = 6 days (contributes to buffer)

### Relative estimation (T-shirt sizes)

Instead of estimating in hours/days (absolute), estimate in relative
complexity. "Is this task bigger or smaller than that task?" Humans are
much better at relative comparison than absolute prediction.

**T-shirt sizing (fastest):**
S = a few hours, M = 1-2 days, L = 3-5 days, XL = more than a week.

Rule: If it's XL, break it down. Nothing should be XL. XL means you
don't understand the task well enough to estimate it, which means you
don't understand it well enough to build it.

### Cycle time measurement

Instead of estimating forward, measure backward. Track how long tasks
actually take from start to done. After 15-20 completed tasks, you have
a distribution. Use the distribution to predict future work.

- Median cycle time: 50% of tasks complete in this time or less.
- 85th percentile: 85% of tasks complete in this time or less.
  (This is your "safe" promise for external commitments.)

**This is the most accurate method for ongoing work.** It replaces
estimation with measurement. To start: track completion dates in your
tool. After 3-4 weeks of data, you have enough to use cycle time for
predictions.

### Monte Carlo forecasting

If you know your historical throughput (tasks completed per week) and the
number of remaining tasks, you can simulate thousands of possible futures.

Simple version:
1. Count remaining tasks (say 12).
2. Measure weekly throughput over the last 6 weeks (say: 3, 2, 4, 3, 2, 3).
3. Randomly sample from that throughput distribution, week by week, until
   all 12 tasks are done.
4. Repeat 1,000 times.
5. The distribution of completion dates gives you confidence levels:
   "50% chance of finishing by March 28, 85% chance by April 8."

Monte Carlo is overkill until you have 6+ weeks of throughput data. Start
with cycle time measurement first.

### The cone of uncertainty

Barry Boehm (1981), later formalized by Steve McConnell. At the start of
a project, estimates can be off by 4x in either direction. As the project
progresses and uncertainty resolves, the cone narrows:

| Project phase | Estimate range |
|---|---|
| Initial concept | 0.25x to 4x |
| Requirements defined | 0.5x to 2x |
| Detailed design | 0.67x to 1.5x |
| Code complete | 0.8x to 1.25x |

**Implication:** An estimate given before you've started building is almost
worthless as a point estimate. Always communicate ranges, not dates.
"2 to 8 weeks" is honest. "4 weeks" is a fiction.

---

## When to Estimate vs. When to Measure

### Estimate when:
- You need to decide whether a project is worth starting at all
  (Is this a 1-week or 6-month effort? That changes the priority decision.)
- You need to coordinate with external parties (customer launches, events,
  partner timelines)
- The work is genuinely novel — you've never done anything like it before,
  so you have no historical data

### Measure (don't estimate) when:
- You're doing ongoing product development (features, bugs, improvements)
- You have 3+ weeks of throughput data
- The work is similar in nature to previous work (another API integration,
  another onboarding improvement, another landing page)
- The cost of estimating exceeds the value of the estimate

### Time-box (don't estimate or measure) when:
- The work is experimental (will this approach even work?)
- You're exploring, not building (customer interviews, market research)
- The risk is in feasibility, not timeline

For experiments: use 2-week time-boxed cycles (GOLEAN sprints). Don't
estimate how long the experiment takes — time-box it. Either you learn
something in 2 weeks or the experiment wasn't focused enough.

---

## Learning to Estimate at 50% Confidence

The entire CCPM system depends on one skill: giving honest 50% confidence
estimates — the median duration where you'd finish faster half the time and
slower half the time. Most people can't do this naturally. They give 80-90%
estimates (padded, safe) and call them "aggressive." The good news: this is
a learnable skill. Douglas Hubbard (*How to Measure Anything*) reports
80-90% of people achieve good calibration within a few hours of practice.

### Why people are bad at this by default

When someone says "I think this will take 5 days," that number is almost
always their 80-90% confidence estimate — padded enough that they'd feel
comfortable committing to it publicly. Their actual 50% estimate might be
3 days, but they don't say that because it feels risky.

The problem isn't dishonesty. It's that people don't distinguish between
"how long will this take?" (which they hear as "what can you commit to?")
and "what's the median duration?" (which is what CCPM needs). The exercises
below train you to hear and answer the second question.

### Exercise 1: The two-question split (use every time you estimate)

For each task, always ask two questions:

1. **"How long if you could just focus — no interruptions, no surprises?"**
   This is close to the 50% estimate.
2. **"How long with normal life — interruptions, surprises, things being
   harder than expected?"** This is close to the 80-90% estimate.

The gap between the two numbers is the safety that CCPM strips from the
task and pools into the buffer. By always asking both, you train yourself
to see that "my estimate" is not one number — it's a range. The first
number goes into the schedule. The gap feeds the buffer.

### Exercise 2: The equivalent bet (gut-check any estimate)

After giving a focused estimate, ask yourself: "Would I rather bet $1,000
that this task finishes in [my estimate] days, or bet $1,000 on a coin
flip?"

- If you'd take the coin flip → your estimate is too aggressive. Adjust up.
- If you'd take the task bet → your estimate is too safe. Adjust down.
- If you're genuinely indifferent → you've found your 50%.

The bet makes the abstract concept of "50% confidence" viscerally concrete.
Hubbard's research shows that even *pretending* to bet money improves
calibration.

### Exercise 3: Weekly estimation retrospective (the feedback loop)

This is the most important exercise. Without feedback, you don't improve.

Each week, review all tasks completed:

| Task | 50% estimate | Actual | Early or late? |
|---|---|---|---|
| Design onboarding flow | 3 days | 4 days | Late |
| Build signup page | 2 days | 1.5 days | Early |
| Write API docs | 1 day | 1 day | On time |

Keep a running tally: **what percentage of tasks finish at or before the
50% estimate?**

- **40-60% finish early:** You're well-calibrated. The buffer is working.
- **70%+ finish early:** Your "50% estimates" are actually 80% estimates.
  You're still hiding safety in the tasks. Push estimates down.
- **Under 30% finish early:** You're being unrealistically aggressive. Your
  buffer will be consumed every time. Push estimates up slightly.

Run this for 4-6 weeks and your calibration will tighten significantly.
The pattern of misses also reveals where your blind spots are — maybe
you consistently underestimate integration work but nail UI work.

### Exercise 4: The trivia calibration drill (one-time training, 30 min)

This exercise, from Hubbard, trains general calibration using trivia
questions. It transfers to project estimation because the underlying skill
— accurately assessing your own uncertainty — is the same.

1. Take 20 general-knowledge questions (e.g., "In what year was the Golden
   Gate Bridge completed?"). For each, give a range you're 90% sure
   contains the answer.
2. Score: how many ranges contain the true answer? If you're calibrated,
   18 out of 20 should hit.
3. Most untrained people hit only 10-14 out of 20. They're massively
   overconfident — their "90% intervals" are really 50-70% intervals.
4. Apply corrections: widen your ranges using the equivalent bet test.
   Repeat with 20 new questions.
5. After 2-4 rounds, most people reach calibration.

Free online tools for this drill:
- **80,000 Hours Calibration Trainer** — 80000hours.org/calibration-training/
- **Metaculus** — metaculus.com (real-world forecasting with calibration tracking)

### The key insight

Calibration is not about being right on any individual estimate. It's about
your estimates being right *in aggregate* — half early, half late, with the
buffer absorbing the variance. A team where every task finishes "on time"
is not well-calibrated. They're padding. A team where roughly half finish
early and half finish late, with the project buffer absorbing the net
variance, is perfectly calibrated.

---

## Startup Quick Protocols

The operational estimation protocol (quick protocol, two-question filter,
fever chart, and timeline communication templates) is in the stage files:

- **`stages/growth.md`** — The quick estimation protocol, two-question
  filter, fever chart summary, and when-to-estimate table for teams under 10.
- **`stages/scaling.md`** — Full CCPM method, buffer sizing, cycle time
  measurement, and communicating timelines to customers, board, and team.

This reference file covers the underlying theory and detailed methods.

---

## Key References

### Essential reading
- **Eli Goldratt, *Critical Chain* (1997):** The source text for CCPM.
- **Douglas Hubbard, *How to Measure Anything* (2010):** Calibration
  training for estimation. Chapter 5 covers the exercises.
- **Mike Cohn, *Agile Estimating and Planning* (2005):** Practical
  estimation for agile teams.

### Deeper dives
- **Steve McConnell, *Software Estimation: Demystifying the Black Art*
  (2006):** Comprehensive treatment of estimation science and the cone
  of uncertainty.
- **Daniel Kahneman, *Thinking, Fast and Slow* (2011):** Chapter on the
  planning fallacy.
- **Vasco Duarte, *No Estimates* (2016):** The case for replacing
  estimation with throughput measurement.

### Key concepts index
- **Student Syndrome:** Goldratt, *Critical Chain*, Chapter 13.
- **Parkinson's Law:** Cyril Northcote Parkinson, *The Economist*, 1955.
- **Planning Fallacy:** Kahneman & Tversky, 1979.
- **Hofstadter's Law:** Douglas Hofstadter, *Gödel, Escher, Bach*, 1979.
- **Cone of Uncertainty:** Barry Boehm, 1981; Steve McConnell, 2006.
- **Little's Law:** WIP = Throughput x Lead Time. John Little, 1961.
- **Relay Race behavior:** Goldratt, *Critical Chain*.
- **Fever Chart:** CCPM buffer monitoring tool. Goldratt, *Critical Chain*.

FILE:references/intake.md
# Intake — First Conversation

Load this file when you don't have enough context to diagnose the founder's situation.
Skip it if the conversation already contains clear answers to these questions.

## What to establish before diagnosing

Ask one question at a time. Don't fire a list.

1. **Stage:** "Do you have paying customers yet — even one?"
   - If no → stage is pre-revenue
   - If yes → ask how many, and how long they've been paying
   - If "we had some but not anymore" → this is a **restart** — load `stages/restart.md`

2. **Team:** "How many people are working on this full-time?"
   - 1-2 = likely doing everything; constraint is usually focus or WIP
   - 3-10 = coordination starts to matter; check for peanut-buttering
   - 10+ = policy constraints likely; load `stages/scaling.md`

3. **Revenue:** "Roughly what's your MRR or ARR right now?"
   - $0 with prior customers → **restart** — load `stages/restart.md`
   - $0 with no prior customers → pre-revenue
   - <$10K MRR → early growth
   - $10K–$100K MRR → activation or retention usually the constraint
   - $100K+ MRR → scaling issues or coordination breakdown

4. **The specific problem:** "What's the one thing that, if it got better, would make everything else easier?"
   - Don't accept "everything" as an answer. Push: "If you had to pick one?"
   - Their answer reveals where they *think* the constraint is — which may or may not be right

5. **What they've already tried:** "What have you already done to fix this?"
   - Reveals biases (e.g. they've only tried building, never talked to churned users)
   - Also avoids suggesting things they've already ruled out

---

## Handling vague answers

Founders give vague answers. Don't accept them. Push for specifics with these probes:

| Vague answer | Push with |
|---|---|
| "A few conversations" | "How many exactly? Name three people you talked to." |
| "Pretty positive feedback" | "Did anyone say 'I would pay for this right now'? What were their exact words?" |
| "They were interested" | "Interested enough to do what? Did they take any action?" |
| "We've validated the problem" | "How many people said they'd pay before you built it? What did they pay?" |
| "The feedback was good" | "What specifically did they say was good? What did they say was missing?" |
| "They went dark" | "What was the last thing you said? What was the last thing they said? Walk me through the final exchange." |

**"Looks cool" is not validation.** Social validation ("this is interesting", "I'd love to see this", "keep me posted") is not demand. The only validation that matters is: did they pay, commit, or take an action that cost them something?

---

## Funnel break scan — run this before routing to any stage file

Once you know they have (or had) customers, don't route yet. Find where the funnel breaks first.

Ask: **"Walk me through your last 10 [signups / demos / deals]. Where did each one end up?"**

Don't accept a summary. Push for specifics. You're listening for:

| If they struggle to say... | The break is at... |
|---|---|
| "How people find us / how many come in" | Acquisition |
| "How many actually try it / show up to the demo" | Activation |
| "How many end up paying" | Conversion |
| "How many are still around after 60 days" | Retention |
| "Why people left / what they went with instead" | Churn / fit |

The first step where the number clearly drops — or where they go vague — is the constraint.

**Don't let them skip this.** Founders will jump to a diagnosis ("we just need more leads") before you've established the break. Hold the line: "Before we get there — walk me through those 10."

Once you know where it breaks, *then* load the stage file. The stage tells you the context; the funnel break tells you the constraint.

---

## What good context looks like before proceeding

Before routing to a stage file, you should know:
- Whether they have paying customers (or had them and lost them)
- Rough team size
- Where the funnel breaks (from the scan above)
- The symptom they're most concerned about
- What they've tried

If you have these, skip the intake and go straight to triage.

FILE:references/jtbd.md
# Pillar 4: Jobs To Be Done (JTBD) — Reference

## Contents
- [Origin](#origin)
- [What a "Job" Is (and Isn't)](#what-a-job-is-and-isnt)
- [The Three Dimensions of Every Job](#the-three-dimensions)
- [The Four Forces of Progress](#the-four-forces-of-progress)
- [The Struggling Moment](#the-struggling-moment)
- [How to Run Switch Interviews](#how-to-run-switch-interviews)
- [The 5-Minute Post-Conversation Canvas](#the-5-minute-canvas)
- [Ulwick's Job Map and Outcome Statements](#ulwicks-job-map)
- [From JTBD to Positioning](#from-jtbd-to-positioning)
- [JTBD Feeds Every Factory Floor Pillar](#jtbd-feeds-every-pillar)
- [The Weekly JTBD Routine](#the-weekly-jtbd-routine)
- [Demand Generation vs. Demand Capture](#demand-generation-vs-demand-capture)
- [Hiring and Firing](#hiring-and-firing)

## Origin

Clayton Christensen introduced Jobs To Be Done theory in *The Innovator's
Solution* (2003) and fully developed it in *Competing Against Luck* (2016).
The core thesis: **people don't buy products. They hire them to make progress
in a specific situation.** If the product does the job well, they hire it
again. If it fails, they fire it and look for something else.

Christensen estimated that 75-85% of new products fail because they don't
target a job people are actually trying to get done.

The milkshake study is the canonical example. Christensen's team observed
that nearly half of all milkshakes sold before 8:30 a.m. — bought by solo
commuters. The job: occupy a long, boring commute and stave off hunger
until lunch. The competition wasn't other milkshakes — it was bananas (gone
in 2 minutes), bagels (messy while driving), and boredom.

## What a "Job" Is (and Isn't)

**A job IS:**
- The progress a person is trying to make in a specific circumstance
- Stable over time (jobs don't change even when technology does)
- Solution-agnostic (defined independently from any product)
- Situational — the same person has different jobs in different contexts

**A job IS NOT:**
- A trend ("people want AI")
- A high-level need ("security")
- A specific solution ("use Slack")
- An activity ("generate reports" — that's what they do, not why)
- A demographic trait ("millennials want...")

**The right level of abstraction test:**
1. It is not a trend or buzzword
2. It is not so abstract that it can't guide a specific decision
3. It does not name or imply a specific solution
4. It includes a task or desired life progress
5. It includes context (external factors and emotional drivers)

## The Three Dimensions of Every Job

**Functional jobs** are the practical task: "Improve my team's conversion
rates without increasing headcount."

**Emotional jobs** are how the buyer wants to feel: "Feel confident I'm
giving my team every advantage. Stop feeling like I'm failing the people
I'm responsible for."

**Social jobs** are how they want to be perceived: "Be seen by leadership
as innovative and data-driven. Be recognized by my team as someone who
equips them for success."

Bob Moesta emphasizes that **jobs are far more emotional than functional.**
The functional job is table stakes. The emotional and social dimensions tip
the decision. Most teams over-index on functional and neglect emotional and
social — which is where differentiation and premium pricing live.

## The Four Forces of Progress

Bob Moesta and Chris Spiek developed the Forces of Progress to explain why
people switch solutions — or why they don't, even when something better
exists. This is the causal mechanism behind every purchase decision.

### Two forces promote switching

**Push of the current situation:** Whatever creates discomfort with the
status quo. It has nothing to do with the new product — it's entirely about
what's going wrong now. Moesta: "Almost all change starts with a push. You
might not know what to do, but you know what you're doing isn't working."

**Pull of the new solution:** The magnetism of something better — the
promise of a life where the problem is solved. Pull is about the imagined
outcome, not the features. Critically: adding more features does not
necessarily create more pull; it can increase anxiety.

### Two forces block switching

**Anxiety of the new solution:** Fear, uncertainty, and risk about
switching. "Will it actually work? Can our team support it? Is this company
going to exist in a year?" Alan Klement distinguishes two types:
*anticipatory anxiety* (fear while deciding) and *anticipated anxiety*
(fear while using). According to Forrester, 86% of B2B buying processes
stall — anxiety, not budget, is usually the cause.

**Habit of the present:** The comfort and inertia of the current way.
Switching costs are real. "We've invested in X already." "The team knows
the current workflow." In B2B, organizational inertia is amplified — career
risk enters the equation.

### The switching equation

**Push + Pull > Anxiety + Habit = purchase.**

If the promoting forces don't exceed the blocking forces, no deal closes —
regardless of how good the product is.

**The strategic implication:** You can increase adoption not only by making
the product better (increasing Pull) but also by **reducing Anxiety** (free
pilots, easy onboarding, testimonials, clear data practices) and **reducing
Habit** (showing the hidden cost of the current way, making migration
effortless). Sometimes the highest-leverage move is not a better feature
but a better guarantee.

## The Struggling Moment

The struggling moment is the specific trigger that crystalizes frustration
into action — the moment someone thinks "I need to do something different."
Not general dissatisfaction. A concrete event: the quarterly report reveals
a metric dropped. A key person quits. A new initiative fails visibly.
Leadership asks uncomfortable questions.

The struggling moment matters because it is both **the origin of every
purchase** and **the exact thing your marketing needs to describe.** When
your messaging opens with the struggling moment in the buyer's own words,
they feel understood before you've mentioned a single feature.

**Every struggling moment is a Category Entry Point** in Byron Sharp's
framework — the situation that causes a buyer to enter the mental category
of "solutions I might need." Mental availability means being the brand that
comes to mind when the struggling moment hits. The practical implication:
**identify the 3-5 struggling moments that repeatedly trigger buying
behavior, then become relentlessly associated with those moments.**

## How to Run Switch Interviews

Bob Moesta's Switch Interview technique reconstructs the full story of a
buying decision — not what people *think* they want, but what actually
*caused* them to act.

### The buying timeline

Every purchase follows this progression:

**First Thought** (seed planted — "maybe things could be different") →
**Passive Looking** (noticing alternatives without committing to search) →
**Event 1** (trigger escalates into active search) → **Active Looking**
(evaluating options) → **Event 2** (narrows the field — a deadline, a
budget approval, an embarrassing incident) → **Deciding** (commitment,
usually through elimination) → **Consuming** (first use) →
**Satisfied/Dissatisfied** (ongoing evaluation).

### Three layers of language

Under 10 minutes, you get the **pablum layer** — vague and non-specific
("It was fine," "We needed something better"). Around 20 minutes, the
**fantasy/nightmare layer** — emotional but imprecise ("Those meetings
were SO long!"). At 30-60 minutes, the **causal layer** — specific,
concrete, actionable ("That meeting ran 30 minutes late and I missed my
kid's game, and I thought, I can't keep doing this").

**If your interview stays in the pablum layer, you've gotten nothing.**

### Questions that unlock each force

**Push**: "What was happening that made you start looking?" / "What was
frustrating about how you were handling this before?" / "Did you try
solving this another way first?" When they give general answers, follow
up: "What happened that made you realize that?"

**Pull**: "What did you hope the new solution would do for you?" / "What
made you think this was the right fit?" / "When you say 'simple,' what
makes it feel that way?"

**Anxiety**: "What worried you about switching?" / "Was there a point
where you almost didn't go through with it?" / "What could go wrong?"

**Habit**: "What made it hard to leave what you were doing before?" /
"What works well about your current setup?" / "What do you miss about
the old way?"

**Critical technique**: Never ask "why" repeatedly — it triggers
rationalization. Instead: "Tell me more about that." "Give me an example."
"Help me understand." "What happened next?"

Moesta's insight on negative framing: **"People can expound on 'no' but
'yes' becomes pablum."** Asking what's hard about something yields rich,
specific language. Asking what's good yields "It just needs to be easy."

### B2B dynamics

In B2B, the buying center includes multiple stakeholders with different
jobs. An ops manager (decides budget), an end user (uses the tool), a QA
person (evaluates quality), an IT gatekeeper (approves security). Interview
at least three of these roles.

B2B anxiety is amplified: career risk, vendor viability, security reviews,
integration fears, organizational inertia. B2B timelines are longer — First
Thought to Purchase can span 6-18 months.

### Sample size

**8-12 interviews** yield reliable patterns. Moesta warns against more:
"People might think if 10 interviews is good, 30 must be 3 times as great.
Nope. 3 times worse because there will be that much more noise."

Interview people who switched (bought or churned) within the **last 90
days** — memory degrades fast. Stop when new interviews sound like previous
ones.

### Mistakes that waste interviews

- Asking about features instead of situations
- Asking hypothetical questions ("Would you...") instead of behavioral
  ("Did you...")
- Not going deep enough on emotional context
- Interviewing only buyers and missing users (or vice versa)
- Treating the interview like a survey instead of following emotional energy
- Interviewing people who purchased too long ago

## The 5-Minute Post-Conversation Canvas

Every conversation is JTBD data if you listen correctly. After every
meaningful customer or prospect conversation, spend 5 minutes filling in
the canvas template. After 5+ canvases, patterns emerge. After 8-12, you
have enough signal to act. Store them in a shared database or simple
spreadsheet. For every hour of interview, spend an hour debriefing.

The canvas template and the weekly rhythm for reviewing canvases are in
`stages/pre-revenue.md` (under "The 5-minute canvas") and `stages/growth.md`
(under "JTBD in the Weekly Rhythm").

## Ulwick's Job Map and Outcome Statements

Tony Ulwick's Outcome-Driven Innovation (ODI) turns JTBD into quantitative
product strategy. Where Moesta's Switch framework tells you *why* people
buy, Ulwick's ODI tells you *what to build.*

### The Universal Job Map

Every job, regardless of domain, breaks into eight stages:

| Step | Definition | Question it answers |
|---|---|---|
| **Define** | Plan what needs to be done | What must be planned before starting? |
| **Locate** | Gather inputs, information, materials | What must be found or assembled? |
| **Prepare** | Set up the environment, ready components | What must be readied for execution? |
| **Confirm** | Verify everything is in place | What must be verified before starting? |
| **Execute** | Carry out the core task | What is the central action? |
| **Monitor** | Track progress and quality | What must be tracked or measured? |
| **Modify** | Adjust based on monitoring | What needs to change if something isn't right? |
| **Conclude** | Finish up, prepare for next cycle | How does the job end or loop? |

The job map is solution-independent. Whether customers use product A or
product B (or no product at all), the map stays the same. It describes what
the customer is trying to get done, not how.

**Build where you create unique value, integrate where others already serve
the job well.** Map your product's features to job map steps — the steps
where existing solutions fail are your opportunity.

### Outcome statements

Ulwick's format for capturing desired outcomes:

**Minimize the [time / likelihood] it takes to [object of control],
[contextual clarifier].**

Direction is always "minimize" — customers want less time, less effort,
less risk. Examples: "Minimize the likelihood of missing a critical moment
during the interaction." "Minimize the time it takes to identify which team
members need coaching."

Capture 5-10 outcomes per job map step.

### The Opportunity Algorithm

For each outcome, measure **importance** (how much it matters, 1-10) and
**satisfaction** (how well current solutions deliver, 1-10):

**Opportunity = Importance + max(Importance - Satisfaction, 0)**

- Scores above **10**: under-served — high importance, low satisfaction.
  These are the best opportunities.
- Scores above **15**: almost certain winners.
- Scores below **10**: over-served — current solutions do more than
  customers need. Potential disruption opportunities (strip features,
  lower price).

Strategyn claims an 86% success rate across 1,000+ engagements using this
approach.

**For startups without survey data**, use a qualitative proxy after 8-12
switch interviews: stack-rank jobs by (a) how strong is the push? (b) how
many interviewees independently surfaced this? (c) are customers exhibiting
compensatory behaviors (workarounds)? (d) does it pass the not-not test?

## From JTBD to Positioning

April Dunford's positioning framework (*Obviously Awesome*) starts with
a question only JTBD can answer: **what were customers using before they
hired you?**

Dunford: "I'll say, 'Hey, who's your competitor?' and they'll give me 15
other startups nobody's ever heard of. But then I go talk to their customers
and say, 'If these guys got hit by a bus next week, what would you do?'
And they say, 'We'd go back to our spreadsheet.'"

### The five components, in order

1. **Competitive alternatives** — what customers used before (JTBD reveals
   this). Not who you think your competitors are.
2. **Unique attributes** — what you have that the alternatives don't.
3. **Value** — the benefit those attributes deliver, with proof.
4. **Target customers** — who cares most about that value.
5. **Market category** — the frame of reference that makes your value
   obvious.

### The messaging hierarchy

1. **Lead with the struggling moment**, not the feature.
2. **Show the desired outcome** in the customer's language.
3. **Address the anxiety directly** — what worries them about switching.
4. **Prove it** — numbers, testimonials, specifics.

Jason Fried discovered that Basecamp customers never used the words "project
management" even though Basecamp had used that phrase for 8 years. **The
customer's language for the struggling moment is your marketing copy.** Don't
translate it into your jargon.

## JTBD Feeds Every Factory Floor Pillar

### JTBD → Goldratt (Theory of Constraints)

JTBD reveals *why* the constraint exists, not just *where*. If you don't
know what job customers hire you for, you can't diagnose why they're not
flowing through the factory.

Apply Goldratt's steps with JTBD intelligence:
- **Identify**: JTBD interviews reveal the constraint (anxiety blocking
  deals? Unclear value prop? Targeting the wrong job?)
- **Exploit**: Use insights to fix messaging, add testimonials, simplify
  onboarding — without adding resources
- **Subordinate**: Everyone works on the one thing JTBD revealed as the
  blocker
- **Elevate**: Invest in the specific capabilities JTBD showed as missing
- **Repeat**: As throughput increases, find the next constraint

### JTBD → Maurya (Customer Factory)

The struggling moment is what triggers someone to **enter the top of the
factory** (Acquisition). The four forces shape every step:

- **Acquisition**: Struggling moments bring people in
- **Activation**: Succeeds when the product delivers progress faster than
  the old way — the "aha moment"
- **Revenue**: Proportional to the value of the progress being made
- **Retention**: The product must become the new habit — replacing the old
  status quo
- **Referral**: Happens when progress exceeds expectations

Maurya's insight: "Getting hired is only the first step. Unless you can
quickly deliver value (the aha-moment) and then establish yourself as the
new status quo (the habit-moment), you could easily find yourself on the
firing block."

### JTBD → Sharp (Mental & Physical Availability)

Struggling moments **are** Category Entry Points. They define the exact
situations where mental availability matters. Map your CEPs by mapping
your customers' struggling moments — they're the same list.

Mental availability = being the brand that comes to mind when the
struggling moment fires. Physical availability = being easy to find and
hire when the customer is ready to act.

### The integrated model

```
JTBD RESEARCH (understand the job)
    ↓
STRUGGLING MOMENTS → Category Entry Points (Sharp)
    ↓                    → Mental availability triggers
FOUR FORCES → Constraint diagnosis (Goldratt)
    ↓              → What's blocking throughput?
POSITIONING → Customer Factory input (Maurya)
    ↓              → Messaging that fills the funnel
PRODUCT STRATEGY → Feature prioritization (Ulwick/ODI)
                     → Build only what serves under-served outcomes
```

## The Weekly JTBD Routine

The operational rhythm for JTBD (after every conversation, weekly, monthly)
is in `stages/growth.md` under "JTBD in the Weekly Rhythm." The pre-revenue
version (focused on customer conversations and hypothesis testing) is in
`stages/pre-revenue.md` under "The Pre-Revenue Weekly Review."

## Demand Generation vs. Demand Capture

Not all potential customers are at the same stage. JTBD reveals two distinct
populations, and confusing them is one of the most common go-to-market
mistakes.

### Demand capture: people already looking

These are buyers who have experienced the struggling moment and are actively
searching for a solution. They're in the Active Looking or Deciding phases of
the buying timeline. They type search queries, read comparison pages, request
demos, and ask peers for recommendations.

**What works:** SEO for problem-specific search terms, review site presence,
comparison pages, case studies, free trials, fast time-to-value. These are
physical availability moves (Sharp) — making it easy to find and try you when
the buyer is ready to act.

**The trap:** Most startups only do demand capture. It's measurable, it
converts quickly, and it feels like "real" marketing. But the pool of
active searchers at any moment is tiny compared to the total addressable
market. If you only capture existing demand, growth is capped by search
volume.

### Demand generation: people not yet looking

These are the buyers who will experience the struggling moment in the future
but haven't yet — or have experienced it but haven't escalated from First
Thought to Active Looking. They're the "light buyers and non-buyers" in
Sharp's framework. They vastly outnumber active searchers.

**What works:** Content and presence at Category Entry Points, thought
leadership, community engagement, conference talks, partnerships, distinctive
brand assets. These are mental availability moves (Sharp) — building memory
structures so that when the struggling moment eventually fires, your brand
comes to mind.

**The connection to forces of progress:** Demand generation works by
amplifying Push (making people aware of the cost of the status quo) and
building Pull (painting the picture of what progress looks like). A blog
post that describes a struggling moment the reader hasn't fully articulated
yet is doing demand generation — it's creating awareness of a problem, not
capturing intent that already exists.

### The balance

| Situation | Priority |
|---|---|
| You have product-market fit but flat growth | Demand generation — the pool of active searchers is tapped. You need to expand the pool by building mental availability. |
| You have strong awareness but low conversion | Demand capture — people know you exist but can't find, try, or buy easily. Fix physical availability. |
| Pre-product/market fit | Neither. Validate the job first. |
| Scaling | Both, in proportion. Typically 60-70% generation, 30-40% capture, as you move up-market. |

### JTBD tells you what to say in both modes

For demand capture, messaging should match the buyer's active search language
— the words they use when they know they have a problem. These come from
the Active Looking phase of switch interviews.

For demand generation, messaging should match the struggling moment itself —
the situation before the search begins. These come from the First Thought
and Event 1 phases of switch interviews. The buyer isn't looking for a
solution yet; they're experiencing friction. Your content should name that
friction in their words and link it to the possibility of progress.

This is why JTBD interviews that reconstruct the full buying timeline (not
just the purchase decision) are essential. The early phases of the timeline
give you demand generation material. The later phases give you demand capture
material. Most teams only mine the later phases and wonder why their content
doesn't generate new pipeline.

---

## Hiring and Firing

Every purchase is a switch: hiring something new means firing something
old. "Something old" can be:
- A competing product
- A manual workaround (spreadsheets, sticky notes, meetings)
- Doing nothing at all

Understanding what they're firing reveals the real competitive set, which
is often not the companies you'd list as competitors. **Non-consumption is
usually the biggest competitor.** Most potential customers have simply
accepted that the problem can't be solved.

Christensen pointed to Airbnb: 40% of guests would not have made the trip
at all without it. What percentage of your potential customers have simply
accepted the status quo?


FILE:references/misdiagnoses.md
# Common Misdiagnoses

Load this when the founder's framing seems wrong — they're diagnosing symptoms as root causes,
and you need to challenge it before you build on a false premise.

---

These are the six most frequent wrong diagnoses:

**"We need more features"**
Almost always wrong. Ask: "Do the customers you have stay? If yes, the product works. You don't have a product problem, you have an awareness problem."

**"We need more marketing"**
Often wrong when activation is broken. Ask: "What happens after someone signs up? Walk me through the first 10 minutes." If they stumble — that's where to fix, not marketing.

**"We need to hire"**
Usually premature. Ask: "What specifically can't get done today that a hire would fix?" If they say "everything" — that's a WIP problem, not a headcount problem.

**"Our pipeline is thin"**
Could be awareness (not enough people know you exist) or positioning (wrong people are finding you) or activation (people find you but don't convert). Ask: "Of the people who do reach out — are they the right profile?" Thin pipeline of right people = awareness. Full pipeline of wrong people = positioning.

**"We're not converting demos"**
Could be the demo, the product, the price, or the buyer. Ask: "What do people say when they don't buy?" Then: "Do you believe them?" Usually the stated reason and the real reason are different.

**"The market isn't ready"**
Almost always a cop-out. Ask: "Who is solving this problem right now — even badly?" There's always a workaround. If there isn't one, the problem may not be painful enough.

**"We need better positioning"**
Often wrong when the real problem is *no* positioning. Ask: "What two things do you want to own in the customer's mind?" If they list seven things — that's the diagnosis. Not "better" positioning; *any* positioning. See `references/pillar-ritson.md`.

**"We need to differentiate more"**
Could be right, but often confused with distinctiveness. Ask: "When someone sees your content without your logo, can they tell it's you?" If no — they don't need differentiation; they need distinctive assets (visual identity, tone, consistent codes). The two work together, but they're different problems.

**"Everyone is a potential customer"**
Always wrong. Ask: "If you could only sell to one type of company/person for the next 6 months, who would it be?" Refusal to choose is not strategy; it's avoidance. The tighter the targeting, the sharper the message, the faster the learning.

FILE:references/pillar-goldratt.md
# Pillar 1: The Theory of Constraints (Goldratt) — Reference

## Contents
- [Origin](#origin)
- [The Five Focusing Steps — Startup Translation](#the-five-focusing-steps)
- [Throughput Accounting for Startups](#throughput-accounting)
- [Little's Law](#littles-law)
- [Drum-Buffer-Rope (DBR)](#drum-buffer-rope)
- [Context-Switching Tax (Weinberg)](#context-switching-tax)

## Origin

Eli Goldratt introduced the Theory of Constraints in *The Goal* (1984). The
core thesis: every system has exactly one constraint at any moment, and the
system's output is limited entirely by that constraint. Improving anything
other than the constraint does not improve the system.

## The Five Focusing Steps — Startup Translation

### 1. Identify the Constraint

In manufacturing, the constraint is the machine with the longest queue. In a
startup, look for these signals:

- **Where does work pile up?** Tickets waiting for engineering? Leads waiting
  for the founder to demo? Signed customers waiting for onboarding?
- **Where do downstream stages starve?** Engineering done but nothing to ship
  because there are no customers? Customers ready but nothing new to show them?
- **What is the team most often waiting on?** The answer reveals the bottleneck.

Common startup constraints by function:

| Function | Signals it's the constraint |
|---|---|
| Sales/Pipeline | Thin pipeline, sparse demos, deals stalling. Engineering and onboarding have spare capacity. |
| Engineering/Product | Feature requests exceed dev capacity. Sales sells what can't be built. Half-built features accumulate. |
| Onboarding/Activation | Deals close but customers can't go live. Churn starts before expansion. Support queue grows. |
| Market/Awareness | Product works well for those who try it, but too few people enter the funnel. Growth is flat despite good retention. |

Important: this is a self-correcting process. If you invest in the wrong area,
the real constraint stays the same and nothing improves. That's your signal to
re-identify.

### 2. Exploit the Constraint

Before spending money, squeeze maximum output from the bottleneck. The
principle: make the constraint more productive with existing resources before
investing new ones. Every minute the constraint spends on non-constraint
work is lost throughput for the entire company.

See the role-by-constraint table in `stages/growth.md` ("What each role does,
based on the current constraint") for the startup-specific translation.

### 3. Subordinate Everything Else

This is the hardest step psychologically. The rules:

- Non-constraints must serve the constraint, even when that means they appear
  underutilized.
- Idle capacity at a non-constraint is not waste — it's buffer. A highway needs
  an emergency lane.
- Non-constraint work that doesn't feed the constraint should stop.

### 4. Elevate the Constraint

Only after Steps 2 and 3. Now you invest: hire at the constraint, buy tools
for the constraint, outsource non-constraint work to free capacity.

Every unit of capacity added at the constraint = throughput of the whole
company. A hire at a non-constraint adds cost without adding throughput.

See `stages/scaling.md` for detailed guidance on hiring as elevation.

### 5. Repeat (Prevent Inertia)

After elevating, the constraint moves. Goldratt's warning: "Do not allow
inertia to become the system's constraint." The processes and policies built
for the old constraint may now be counterproductive.

This is why the weekly constraint review exists. Every week, re-ask: "What is
our constraint now?" If it has shifted, update subordination roles immediately.

## Throughput Accounting for Startups

Goldratt's three metrics, translated:

| Manufacturing term | Startup equivalent |
|---|---|
| **Throughput (T)** | Revenue from happy paying customers. The rate of creating monetizable value. |
| **Inventory (I)** | WIP — half-built features, unworked leads, unsigned proposals, customers in limbo. |
| **Operating Expense (OE)** | Everything spent to run: salaries, cloud infra, tools, rent. Essentially fixed in the short term. |

**The decision hierarchy:**
1. Does this increase T? → Prioritize.
2. Does this reduce I? → Do it next.
3. Does this reduce OE? → Nice, but secondary.

Most founders invert this and start with cost-cutting. TOC says maximize T
first, always. Ash Maurya echoes this: "The idea of throughput accounting is
flipping cost-cutting on its head and saying the bigger potential is thinking
about upside potential."

## Little's Law

WIP = Throughput × Lead Time. This is a mathematical identity, not a theory.

If WIP increases and Throughput holds constant, Lead Time must increase. Every
time you start new work without finishing existing work, you're increasing WIP,
which extends lead time on everything.

The practical implication: **finishing one thing is always better than starting
two things.** A team completing one feature per week delivers more value than a
team with five features "in progress" for three weeks each.

## Drum-Buffer-Rope (DBR)

Drum-Buffer-Rope is Goldratt's scheduling mechanism for managing flow through
a system. Where the Five Focusing Steps tell you *what* to do about the
constraint, DBR tells you *how to pace the whole system* around it.

**Drum:** The constraint sets the pace. It determines the system's maximum
throughput, so everything runs at the constraint's rhythm. In a startup, if
engineering is the constraint and can ship one feature per week, the whole
company operates on a one-feature-per-week drum. Marketing doesn't generate
leads faster than sales can close them. Sales doesn't close deals faster than
onboarding can absorb them. The constraint's capacity IS the tempo.

**Buffer:** A time buffer placed in front of the constraint ensures it never
starves. Work that feeds the constraint should arrive early enough that the
constraint always has something ready to pull. In practice: 2-3 fully
specified, unblocked tasks queued before the bottleneck person or process.
If the buffer runs dry, the constraint sits idle and the entire system loses
throughput.

**Rope:** A signal that ties the start of new work to the constraint's
consumption rate. New work enters the system only when the constraint pulls
it — not when someone upstream is ready to push it. The rope prevents
overproduction at non-constraints, which would pile up as WIP (inventory)
without increasing throughput.

### DBR in a startup

| DBR element | Manufacturing | Startup equivalent |
|---|---|---|
| Drum | Bottleneck machine's cycle time | The constraint's capacity (demos/week, features/sprint, customers onboarded/week) |
| Buffer | Queue of parts in front of the bottleneck | 2-3 ready tasks before the constraint; pre-qualified leads before the sales constraint; signed customers queued before onboarding |
| Rope | Signal to release raw materials | WIP limit — nobody starts new work until the constraint pulls. New leads aren't generated faster than the constraint can process them. |

**The practical rule:** Before starting any new initiative, ask: "Can the
constraint absorb this?" If engineering can ship one thing per sprint,
planning three things is creating inventory, not progress. The rope prevents
this by tying intake to the constraint's actual throughput.

DBR and the Five Focusing Steps work together: the Five Focusing Steps tell
you WHERE to intervene (identify, exploit, subordinate, elevate). DBR tells
you how to PACE the system so non-constraints don't overproduce and the
constraint never starves. The weekly constraint review checks both: is the
constraint identified correctly (Five Focusing Steps)? Is the buffer healthy
and is WIP controlled (DBR)?

---

## Context-Switching Tax (Weinberg)

Gerald Weinberg's research: each additional parallel project costs ~20% in lost
productivity from context-switching.

| Simultaneous projects | % of time available per project | % lost to switching |
|---|---|---|
| 1 | 100% | 0% |
| 2 | 40% | 20% |
| 3 | 20% | 40% |
| 4 | 10% | 60% |
| 5 | 5% | 75% |

For a three-person startup, the practical limit is one active task per person.
WIP limit = team size.

FILE:references/pillar-maurya.md
# Pillar 2: The Customer Factory (Ash Maurya) — Reference

## Contents
- [Origin](#origin)
- [The Customer Factory Blueprint](#the-customer-factory-blueprint)
- [Key Definitions](#key-definitions)
- [Constraint Identification by Stage](#constraint-identification-by-stage)
- [The GOLEAN Framework](#the-golean-framework)
- [The Referral Loop and Viral Coefficient](#the-referral-loop)
- [The Local vs. Global Optimization Trap](#the-local-vs-global-optimization-trap)
- [The Premature Optimization Warning](#the-premature-optimization-warning)
- [Connecting to Goldratt](#connecting-to-goldratt)
- [Throughput Accounting on the Lean Canvas](#throughput-accounting-on-the-lean-canvas)

## Origin

Ash Maurya created the Customer Factory model in *Scaling Lean* (2016),
explicitly building on Goldratt's Theory of Constraints. As Maurya puts it:
"The Theory of Constraints was a key influence — I adapted his focusing steps
for systems thinking to the business modeling process."

The core idea: treat your business as a factory whose output is happy customers.
Apply the same constraint-thinking Goldratt used on manufacturing floors to the
steps of creating, delivering, and capturing value.

## The Customer Factory Blueprint

Every business — B2B, B2C, SaaS, services, hardware — has the same five
macro steps:

```
[Unaware Visitors]
       ↓ Acquisition
[Interested Prospects]
       ↓ Activation
[Active Users / Trialists]
       ↓ Revenue
[Paying Customers]
       ↓ Retention
[Retained Happy Customers]
       ↓ Referral
[New Unaware Visitors from word-of-mouth]
```

Each step has a conversion rate. Each step has capacity. The step with the
lowest throughput relative to your goal is your constraint.

## Key Definitions

**Throughput** = the rate at which you create happy customers. Not signups. Not
pageviews. Not MQLs. Happy customers who achieve their desired outcome and
pay you for it. This is traction.

**Happy customers ≠ customers made happy.** Making customers happy is easy —
give them stuff for free. Making happy customers means helping them achieve
results (desired outcomes). Happy customers get you paid.

**Traction** = the rate at which a business model captures monetizable value
from its customers. Not the same as current revenue. Revenue is a lagging
indicator. Traction is the leading indicator.

## Constraint Identification by Stage

Maurya maps the typical constraint to the startup's maturity stage:

### Pre-Problem/Solution Fit
**Typical constraint: The problem itself.**
Are you solving a real problem that's painful enough for people to switch from
their current solution? If not, no amount of engineering or marketing matters.

**Actions:** Customer interviews. Lean Canvas stress-testing. Demo the problem,
not the solution. Validate willingness to pay before building.

**The Innovator's Bias and the Innovator's Gift (from *Running Lean*)**

The **Innovator's Bias** is the #1 contributor to startup failure: falling in
love with your solution before validating the problem. Maurya: "When you've
decided you want to build a hammer, everything starts looking like a nail."
Founders unconsciously invent problems to justify the solution they already
want to build, then seek just enough evidence to convince themselves they're
on track. Intelligence makes the bias worse — smart founders rationalize
more effectively, not more honestly. The bias is "immune to lecture" — you
can't overcome it through awareness alone. You need systemic countermeasures.

The antidote is the **Innovator's Gift**: the realization that **new problems
worth solving are created as by-products of old solutions.** To build
something better, it must be better *relative to* what customers use today.
The starting point is always the existing alternative — not your idea.

Maurya's prescribed Lean Canvas fill order makes this concrete: start with
**Existing Alternatives** (what customers use now), then **Problems** (what's
broken about those alternatives), then everything else. Existing Alternatives
is the most important Lean Canvas building block — more important than the
Problem box itself, because without it, you're defining problems in a vacuum.

**Maurya's Lean Canvas questions** and the **Napkin Test** are the core
pre-building tools. See `stages/pre-revenue.md` for the full operational
versions (the questions to ask and the math to run). The Lean Canvas is a
set of hypotheses to test, ordered by risk — test the riskiest assumption
first.

**The Mafia Offer** — an offer so good customers can't refuse, tested
BEFORE building an MVP. Maurya's sequence: **Desirability → Feasibility →
Viability.** Test whether people want this (Mafia Offer) before testing
whether you can build it (MVP) before testing whether the business model
works at scale (traction metrics).

**The 3x rule:** The offer must promise at least a 3x improvement over the
existing alternative on the dimension the customer cares about most. Not 10%
better — dramatically, obviously better. Anything less won't overcome
switching costs and inertia.

See `stages/pre-revenue.md` for the operational template and commitment test.

### Problem/Solution Fit → Product/Market Fit
**Typical constraint: Activation.**
People sign up but don't get value. Time-to-value is too long. The aha moment
doesn't arrive. Churn is high because customers never actually activated.

**Actions:** Concierge onboarding. Measure time-to-first-value. Reduce steps
to activation. Talk to churned users — most churned before they ever really
used the product.

### Product/Market Fit → Scale
**Typical constraint: Acquisition.**
The product works. Users who activate tend to stay. But not enough people enter
the funnel. Growth is flat.

**Actions:** Channel experiments. Positioning refinement. Pricing changes.
Apply Sharp's mental/physical availability framework. This is where "nobody
knows you exist" becomes the bottleneck.

### Scale
**Typical constraint: Retention or Revenue.**
The machine runs but leaks. Customers churn, or they stay but don't expand.
Unit economics don't work at volume.

**Actions:** Churn analysis. Expansion revenue. Pricing optimization.
Investigate whether "happy" customers are actually achieving desired outcomes.

## The GOLEAN Framework

Maurya's tactical cycle for continuous improvement at the constraint:

- **G**o — Identify the constraint. Set a goal for improving it.
- **O**bserve — Measure current performance at the constraint.
- **L**earn — Run experiments to address the constraint.
- **E**valuate — Did throughput increase? Was the constraint broken?
- **A**nalyze — Reconcile learnings. Systemize what worked.
- **N**ext — If constraint broken, identify the next one. If not, run another
  experiment. Repeat.

Each cycle should be 2 weeks (a "LEAN sprint"). Fast enough to learn, slow
enough to execute meaningfully.

## The Referral Loop and Viral Coefficient

The referral step in the customer factory is the only step that creates a
reinforcing loop — retained happy customers generate new unaware visitors,
feeding the top of the funnel. When the loop is strong, each cohort of
customers generates part of the next cohort, reducing the cost of
acquisition over time.

### The viral coefficient (K)

K = (number of invitations per customer) × (conversion rate of invitations)

- **K > 1:** Viral growth. Each customer generates more than one new customer.
  The product grows without paid acquisition. Extremely rare — Dropbox,
  WhatsApp, and early Slack are canonical examples.
- **K = 0.5 to 1:** Amplified growth. Referrals supplement acquisition but
  don't sustain it alone. Each dollar of acquisition spend is amplified by
  word-of-mouth.
- **K < 0.5:** Referral is negligible. Growth depends entirely on direct
  acquisition.

Most startups pre-scale have K < 0.3. This is normal. Referral is rarely
the constraint early — you need enough happy customers to generate meaningful
referral volume, and you need the rest of the factory working first.

### When to invest in referral

Referral becomes high-leverage when three conditions are met:
1. **Retention is strong** — customers stay long enough to refer.
2. **The product delivers the job** — customers achieve their desired outcome
   and would naturally tell peers.
3. **The referral mechanism is frictionless** — sharing is built into the
   product flow, not bolted on as an afterthought.

If any of these is missing, investing in referral programs is premature.
Fix retention and activation first — a referral from a customer who churns
in 30 days is negative signal, not growth.

### Types of referral loops

**Word-of-mouth (passive):** Customers mention you in conversation. Not
engineered. Driven entirely by how well the product delivers the job. The
strongest form long-term, but slowest to build.

**Inherent virality:** The product requires or benefits from multiple users.
Collaboration tools, shared workspaces, team messaging. Each user invited is
a potential new customer. The product IS the referral mechanism.

**Incentivized referral:** Discounts, credits, or features unlocked for
referring. Effective for boosting K when the base product already generates
organic referrals. Dangerous when used as a substitute for authentic demand
— incentivized referrals from unhappy customers create churn, not growth.

**Content as referral:** The product's output is shareable — reports, designs,
dashboards, summaries. When the output carries your brand and demonstrates
value, every share is a referral. This is also a "feature that IS
distribution" (see Sharp's framework).

### The reinforcing loop

When referral works, it creates a compounding cycle:

```
More customers → More referrals → More acquisition → More customers
```

A small improvement at any point in this loop accelerates the whole cycle.
This is why, once retention is solid and the factory is flowing, even modest
referral improvements can produce outsized growth.

Maurya's caution: the loop is fragile. If retention breaks (customers churn
before referring), if activation breaks (referred users don't reach the aha
moment), or if the product stops delivering the job, the loop collapses. The
referral step depends on every upstream step working. Fix the factory first,
then amplify with referral.

---

## The Local vs. Global Optimization Trap

This is the most common mistake Maurya identifies in growing startups. Teams
optimize their local metrics while system throughput stagnates or declines:

- **Marketing** generates more leads → but leads are lower quality → conversion
  drops → net throughput unchanged.
- **Sales** closes more deals via aggressive tactics → customers churn faster →
  net throughput unchanged.
- **Engineering** ships more features faster → but features don't address the
  bottleneck → customers don't activate better → net throughput unchanged.

The antidote: every team's effort must be evaluated against system throughput
(happy paying customers created), not local metrics (leads generated, features
shipped, deals closed).

## The Premature Optimization Warning

Maurya: "Going fast on everything is a recipe for getting lost faster."

The counter-intuitive move is slowing down to build a repeatable customer
factory in stages. Each stage is a smaller version of the next stage. You
can't scale what isn't first repeatable.

**When is something repeatable?** When you know where your next 10 customers
will come from. Random isn't repeatable. Repeatable is what scales.

**Focus on repeatability right after your first sale.** If you don't establish
repeatable sales quickly, you get pulled in many directions, lose focus, and
hit a wall.

## Connecting to Goldratt

Maurya's explicit connection: "How do you know when a constraint is broken?
When your customer factory throughput goes up as a result of something you
just did."

The customer factory IS the system. The five macro steps ARE the machines on
the factory floor. The conversion rates ARE the machine capacities. The
constraint IS the machine with the lowest throughput relative to demand.

Goldratt's Five Focusing Steps map directly:

| Goldratt step | Customer factory equivalent |
|---|---|
| Identify | Which of the 5 steps has the lowest rate relative to goal? |
| Exploit | Improve that step's conversion with existing resources. |
| Subordinate | All other teams serve that step. Pause work that doesn't. |
| Elevate | Invest in that step — hire, buy tools, redesign. |
| Repeat | Constraint moves to next weakest step. Re-identify. |

## Throughput Accounting on the Lean Canvas

Maurya adapts Goldratt's throughput accounting to the business model:

- **Throughput** maps to the Revenue Streams box of the Lean Canvas. Focus on
  maximizing revenue potential (pricing, right customers) before optimizing
  costs.
- **Operating Expense** maps to the Cost Structure box. There's a floor — you
  can only cut so much. The upside potential is on the revenue side.
- **Inventory** maps to everything in progress but not yet generating revenue:
  features being built, leads being nurtured, customers being onboarded.

Maurya: "Yes, we want to worry about cost-cutting and efficiency, but the
bigger potential here is thinking about upside potential." This is Goldratt's
hierarchy (T > I > OE) restated for the startup context.

FILE:references/pillar-ritson.md
# Pillar 4: Marketing Strategy Discipline (Mark Ritson) — Reference

## Contents
- [Origin](#origin)
- [The Sequential Discipline: Diagnosis → Strategy → Tactics](#the-sequential-discipline)
- [STP: Segmentation, Targeting, Positioning](#stp)
- [Differentiation + Distinctiveness: Both Matter](#differentiation--distinctiveness)
- [The Long and the Short: Budget Allocation](#the-long-and-the-short)
- [Two Associations, Defended Consistently](#two-associations)
- [Brand Codes: The Palette](#brand-codes)
- [Market Orientation: The First Discipline](#market-orientation)
- [Connecting Ritson to the Other Pillars](#connecting-ritson-to-the-other-pillars)
- [The Ritson Diagnostic for Startups](#the-ritson-diagnostic)
- [From Diagnosis to Action: The Positioning Sprint](#the-positioning-sprint)

## Origin

Mark Ritson is a former marketing professor at London Business School and
Melbourne Business School who has taught brand strategy to MBA students and
executives for over two decades. He was the in-house professor for LVMH for
13 years and now runs the Mini MBA in Marketing. His weekly column for
Marketing Week has run since 2009.

Ritson's core contribution: the **discipline of marketing strategy itself**.
While Sharp provides the laws of brand growth and Maurya provides the
customer factory model, Ritson provides the sequential process that makes
strategy coherent.

The thesis: **Most marketers have never had a strategic day in their lives.**
They jump from tactic to tactic, chasing shiny objects (blockchain, AI, VR),
without ever doing the diagnostic and strategic work that makes tactics
meaningful.

---

## The Sequential Discipline: Diagnosis → Strategy → Tactics

This is the foundational framework. Marketing happens in three phases, in
order. Skipping phases or doing them out of sequence is the #1 cause of
wasted marketing effort.

### Phase 1: Diagnosis

Before any strategy, you must understand the market. This is not optional
and cannot be rushed.

**What diagnosis includes:**
- **Market research** — both qualitative (ethnography, interviews, focus
  groups) and quantitative (surveys, brand tracking)
- **Segmentation** — mapping the market into distinct groups based on
  needs, behaviors, and attitudes
- **Competitive landscape** — who else serves these segments, how they
  position, what they own
- **Brand perception audit** — what associations exist in customers' minds
  right now

**Ritson's first law:** The moment you start getting paid to work for a
company, it becomes impossible to see the product the way customers see it.
Market orientation — the discipline of accepting that you're in the dark —
must precede any research. Without it, research is done for show, not for
insight.

**The vacuum principle:** Create a vacuum of market orientation first. Make
the team understand they don't know what customers think. Only then will
research be used, not ignored.

**Timing:** Diagnosis should start 3-4 months before strategy is needed.
The lag is the price of doing it right.

### Phase 2: Strategy

Strategy is the middle part. It consists of **choices about what you will
and won't do**, based on the diagnosis. Not recommendations. Choices.

Strategy answers three questions:

1. **Who will we target?** (Targeting — from the segmentation)
2. **What will we stand for?** (Positioning — in those targets' minds)
3. **What will we achieve?** (Objectives — in the next 12 months)

Each question has a "won't" side: who we won't target, what we won't stand
for, what we won't chase this year. The choices you make *not* to pursue
are more numerous than what you pursue — that's what makes it strategy.

**Ritson's rule:** A 12-month planning cycle. No longer. Finance can plan
5 years out; marketing cannot. Markets shift too fast. Set objectives for
the next 12 months, then re-diagnose.

### Phase 3: Tactics

Only after diagnosis and strategy come tactics. Tactics are the executions:
campaigns, content, channels, creative, pricing actions, distribution moves.

Most marketers start here. They skip diagnosis ("we know our customers")
and strategy ("we just need to get the word out") and go straight to
tactics. The result: activity without direction.

**Multiplicative relationship:** Ritson describes diagnosis, strategy, and
tactics as multiplicative, not additive. A brilliant tactic built on zero
strategy produces zero. A mediocre tactic built on solid diagnosis and
sharp strategy outperforms.

---

## STP: Segmentation, Targeting, Positioning

The core of the strategy phase. Most marketers conflate these or skip
segmentation entirely. Ritson insists on the sequence.

### Segmentation (diagnosis phase, not strategy)

Segmentation is about **understanding the market as it exists**, without
reference to your brand. It's part of diagnosis, not strategy.

**What segmentation is:**
- Dividing the market into distinct groups based on needs, behaviors,
  attitudes, or occasions
- Each segment should be internally homogeneous and externally distinct
- A good segmentation typically yields 6-10 segments

**What segmentation is NOT:**
- Describing your ideal customer (that's targeting, not segmentation)
- Defining personas for your product (that assumes the answer)
- Demographics alone (age/income rarely explain behavior)

**Common mistake:** Marketers say "our segment is..." before they've mapped
the full market. That's not segmentation. That's guessing who you want to
sell to.

**Proper segmentation:**
1. Research the full market (quant + qual)
2. Identify dimensions that create distinct groups (needs, occasions,
   attitudes, behaviors)
3. Cluster the market into segments
4. Name and size each segment
5. Only THEN consider which to target

### Targeting (strategy phase)

Targeting is **choosing which segments you will and won't pursue**. It's
a strategic choice, made after segmentation is complete.

**Targeting considerations:**
- Segment attractiveness (size, growth, profitability)
- Your ability to serve the segment (fit with capabilities)
- Competitive intensity (who else is targeting this segment)
- Alignment with brand (does this segment want what you do well?)

**Ritson's rule:** You cannot target all segments. If you try, you target
none. The choice of what NOT to pursue is what makes targeting strategic.

**For startups:** Targeting should be narrow at first. As you grow, you
can expand. But the discipline is the same: choose, don't spray.

### Positioning (strategy phase)

Positioning is **what you want to stand for in the minds of your target
customers**. It's the mental real estate you're claiming.

**Ritson's positioning rules:**

1. **A position is NOT a tagline.** It's the 2-4 associations you want to
   own in the customer's mind.

2. **Fewer is better.** More than 4 associations and none will stick.
   "Fast, reliable, innovative, customer-obsessed, fun" is positioning for
   zero.

3. **Relative, not absolute.** Positioning is always relative to
   competitors. "Premium" only means something if others are "budget."

4. **Positioning ≠ differentiation.** See section below.

5. **Write it in the customer's words.** Not your marketing speak. What
   would a customer say about you to a friend?

**Positioning statement template:**
"For [target segment], [brand] is the [category] that [key differentiator]
because [reason to believe]."

Example: "For busy sales managers, Swiftner is the coaching tool that makes
every rep better on live calls because it provides real-time guidance, not
just post-call review."

---

## Differentiation + Distinctiveness: Both Matter

This is Ritson's synthesis of the Sharp vs. traditional debate. Sharp says
distinctiveness > differentiation. Ritson says: **you need both**.

### Differentiation

What you stand for that competitors don't. Your positioning. The reason a
customer would choose you over alternatives.

**Differentiation is:**
- About *meaning* — what the brand represents
- Relative — defined against competitors
- 2-4 associations, max
- Requires strategic discipline to choose and defend

**Differentiation is NOT:**
- Uniqueness (you don't need to be the only one; you need to be *chosen*)
- A feature list (features are proof points, not position)

### Distinctiveness

The sensory cues that make your brand recognizable. Visual, auditory, and
other assets that trigger brand recall without needing to see the name.

**Distinctive assets include:**
- Logo and visual identity
- Colors
- Shapes and patterns
- Sounds, jingles, sonic cues
- Taglines and slogans
- Characters, mascots, celebrities
- Typography
- Packaging elements

**The Ehrenberg-Bass grid:** Test each asset on two dimensions:
1. **Fame** — Does it trigger the brand? (When people see/hear it, do they
   think of you?)
2. **Uniqueness** — Does it trigger *only* your brand? (Or could it be
   confused with competitors?)

Strong distinctive assets score high on both.

### Why both matter

- **Differentiation** answers: "Why should I choose you?"
- **Distinctiveness** answers: "Which one is you?"

A brand with differentiation but no distinctiveness is forgettable. A brand
with distinctiveness but no differentiation is recognizable but
interchangeable.

**The startup trap:** Founders often focus only on differentiation ("we're
better because...") without building distinctive assets. Result: every
pitch sounds the same, every website looks the same, no memory structures
form.

**Ritson's advice:** Pick your distinctive assets early and use them
relentlessly. Consistency compounds. A founder who posts with the same
visual style, tone, and topics every week builds more mental availability
than one who reinvents their approach monthly.

---

## The Long and the Short: Budget Allocation

This is Binet & Field's research, which Ritson champions. It addresses how
to split marketing investment between brand building and sales activation.

### Two types of marketing investment

**Brand building (long-term):**
- Builds mental availability over time
- Works on memory structures
- Effects take months/years to materialize
- Measured by brand metrics (awareness, consideration, salience)
- Examples: brand campaigns, sponsorships, content that doesn't ask for
  immediate action

**Sales activation (short-term):**
- Generates immediate response
- Converts existing demand
- Effects visible within days/weeks
- Measured by response metrics (clicks, conversions, pipeline)
- Examples: performance ads, promos, "book a demo" campaigns, retargeting

### The 60/40 rule

Binet & Field's research across thousands of campaigns found that the
optimal split for established brands is roughly:
- **60% brand building**
- **40% sales activation**

This ratio varies by category (retail: 64/36; FMCG: 60/40) and by maturity.

**For startups:** The ratio shifts toward activation early (you need
revenue now), but founders over-correct. They run 100% activation and
wonder why long-term growth stalls. Some brand building investment — even
10-20% — builds the memory structures that make future activation cheaper.

### Why this matters

**The short-termism trap:** Most companies massively over-invest in
activation and under-invest in brand. Short-term metrics look fine.
Long-term growth stalls. When you cut brand investment, activation gets
more expensive (you're harvesting demand without replenishing it).

**Brand building works on activation too:** Binet & Field's data shows
that brand-building campaigns also generate short-term sales lifts — but
activation campaigns rarely generate long-term brand effects. Brand
building is "the ultimate strategic BOGOF" (buy one, get one free).

**For startups using the constraint framework:** When the constraint is
awareness (mental availability), you're doing brand building. Measure
reach, not clicks. When the constraint is conversion, you're doing
activation. Measure conversions. Don't mix the two. Different work,
different metrics, different time horizon.

---

## Two Associations, Defended Consistently

This is Ritson's practical positioning discipline.

**The rule:** Pick 2 associations. Maybe 3. Absolutely no more than 4.
Defend them consistently for years.

**Why it works:**
- Memory is limited. Customers can't hold 10 associations.
- Repetition builds salience. The same associations, repeated, stick.
- Consistency beats creativity. A mediocre position defended for 5 years
  beats a brilliant position changed every year.

**The discipline:**
1. From your positioning work, identify the 2-3 associations you want to
   own.
2. Every piece of communication reinforces at least one of them.
3. Kill anything that doesn't. (This is the hard part.)
4. Review annually: are these still the right associations? If yes, keep
   going. If the market has shifted, re-diagnose before changing.

**Example:** Volvo owns "safety." For decades. Every campaign, every
feature launch, every PR story ties back to safety. They could have
tried to also be "stylish" or "innovative" or "fun to drive." They
chose not to. That choice is strategy.

---

## Brand Codes: The Palette

Ritson's term for distinctive assets, drawn from his LVMH work. A brand
"paints with a palette of codes" — the sensory identifiers that trigger
recognition.

### Building a brand code palette

**Step 1: Audit current codes.**
List every potential distinctive asset you have: logo, colors, shapes,
sounds, tagline, characters, typography, patterns, packaging elements.

**Step 2: Test each code.**
For each code, estimate:
- Fame: Do people associate this with us?
- Uniqueness: Could it be confused with anyone else?

Prioritize codes that score high on both. Codes that score low on
uniqueness (generic colors, common typography) need differentiation or
replacement.

**Step 3: Pick your palette.**
You don't need 20 codes. Pick 5-8 strong ones and use them consistently
across everything. The goal: any single code should trigger brand recall
without the logo present.

**Step 4: Codify the usage.**
Document exactly how each code should be used. This becomes your brand
guidelines, but focused on *recognition*, not just aesthetics.

### For startups

You don't have budget for brand tracking and code testing. But you can:
- Pick your codes early (logo, colors, tone of voice)
- Use them relentlessly
- Resist the urge to "refresh" before you've built any recognition
- Test informally: show your content without the logo; can people tell
  it's you?

---

## Market Orientation: The First Discipline

Before any of this works, the team must accept that **they cannot see
the product the way customers see it**.

**Ritson's first law:** The moment you start working for a company, you
lose the ability to see it clearly. You know too much. You care too much.
Your assumptions fill in for customer reality.

**Market orientation is:**
- Accepting you're in the dark
- Being genuinely curious about what customers think (not defensive)
- Using research to see, not to confirm
- Updating beliefs when data contradicts them

**How to build it:**
- Get out into the field. Watch customers. Shut up and listen.
- Run qual first. Let customers tell you what's important before you
  decide what to measure.
- Confront the team with what customers actually say. Not summaries —
  verbatims. The dissonance is the point.
- Kill the phrase "we know our customers." Replace it with "what do our
  customers actually think?"

---

## Connecting Ritson to the Other Pillars

**Sharp** provides the laws of brand growth: mental/physical availability,
distinctiveness, reach > frequency, light buyers as the growth engine.

**Maurya** provides the customer factory model: acquisition → activation →
revenue → retention → referral, with throughput as the key metric.

**Goldratt** provides constraint thinking: identify the bottleneck, exploit
it, subordinate everything else, elevate when needed.

**Ritson** provides the strategic discipline that sits above all three:
- Diagnosis before strategy, strategy before tactics
- STP as a rigorous sequence
- Positioning as 2-3 associations, defended consistently
- Differentiation + distinctiveness as complementary
- Long vs. short budget allocation
- Market orientation as the prerequisite

Without Ritson's discipline, the other frameworks become tactics without
direction. Sharp tells you to build mental availability — but which CEPs?
Maurya tells you to optimize the factory — but for which segment?
Goldratt tells you to find the constraint — but what if the constraint is
strategic clarity itself?

Ritson's contribution is the *process* that makes the other frameworks
strategic.

---

## The Ritson Diagnostic for Startups

When a founder's growth is stalled and the funnel diagnostics don't reveal
a clear constraint, check for strategic clarity:

1. **"Can you state your position in one sentence, in the customer's
   words?"** If they stumble or list multiple things — no positioning.

2. **"What two associations do you want to own?"** If they list more than
   4, or can't answer — no positioning discipline.

3. **"Who are you NOT targeting?"** If they say "everyone who..." or
   can't name a segment they're ignoring — no targeting discipline.

4. **"When did you last talk to a customer who didn't buy?"** If it's
   been months — no market orientation.

5. **"What percentage of your marketing is brand vs. activation?"** If
   they don't know or it's 100% activation — budget imbalance.

These questions surface whether the problem is *execution* (the other
pillars) or *strategy* (Ritson's domain). Fix strategy first.

---

## From Diagnosis to Action: The Positioning Sprint

When the diagnostic reveals "no positioning," here's the concrete next step:

### Step 1: Find your best-fit customers (1-2 hours)

Look at your existing customers (or trials, or serious conversations).
Identify the 3-5 who got the most value. Not revenue — value. Who used
the product most? Who renewed fastest? Who referred someone?

If you have mixed segments (e-commerce, SaaS, agencies all paying you),
ask: "Which segment has the shortest sales cycle, highest retention, and
clearest job-to-be-done?" That's your focus segment. Pick ONE.

### Step 2: Interview them (2-3 hours)

Call the 3-5 best-fit customers. Ask:
- "What were you doing before you found us?"
- "What made you decide to try us?"
- "What would you tell a colleague about what we do?"
- "If we disappeared tomorrow, what would you miss most?"

Write down their exact words. Don't paraphrase.

### Step 3: Find the common thread (30 min)

Look at the interview notes. What patterns emerge?
- Same struggling moment?
- Same job-to-be-done?
- Same words to describe the value?

The common thread becomes your positioning foundation.

### Step 4: Draft your position (30 min)

Use this template:
"For [target segment], [brand] is the [category] that [key differentiator]
because [reason to believe]."

Then extract the 2 associations you want to own. No more than 3. Write
them in customer language.

### Step 5: Kill everything that doesn't fit (ongoing)

Every piece of content, every feature request, every sales conversation:
does it reinforce one of your 2 associations? If not, it's noise. Cut it.

This is a 1-week sprint, not a 3-month project. Do it before any more
marketing.

FILE:references/pillar-sharp.md
# Pillar 3: Mental & Physical Availability (Byron Sharp) — Reference

## Contents
- [Origin](#origin)
- [The Two Availabilities](#the-two-availabilities)
- [Sharp's Laws — Startup Implications](#sharps-laws)
- [The Sharp Diagnostic for Startups](#the-sharp-diagnostic)
- [The CEP Mapping Exercise](#the-cep-mapping-exercise)
- [The Physical Availability Audit](#the-physical-availability-audit)
- [Building Mental Availability: The Operational Protocol](#the-operational-protocol)
- [Connecting Sharp to Goldratt and Maurya](#connecting-sharp-to-goldratt-and-maurya)
- [Connecting Sharp to Ritson](#connecting-sharp-to-ritson)

## Origin

Byron Sharp, with the Ehrenberg-Bass Institute at the University of South
Australia, published *How Brands Grow* (2010) based on decades of empirical
brand data. The book demolished several marketing orthodoxies and replaced
them with evidence-based laws of brand growth.

The core thesis for startups: **most potential customers don't know you exist.
That's the constraint.**

## The Two Availabilities

### Mental Availability

The probability that your brand comes to mind in a buying situation.

Mental availability is NOT the same as "brand awareness" in the survey sense.
It's about being linked in the buyer's memory to the right **Category Entry
Points (CEPs)** — the situations, needs, occasions, and problems that trigger
someone to look for a solution.

**Example CEPs for an AI sales coaching platform:**
- "My cold calling team's conversion rate is terrible"
- "I'm onboarding new SDRs and they need to ramp faster"
- "I want to listen to sales calls but don't have time"
- "I need data on what my top performers do differently"
- "My team is using too many filler words on calls"

Each of these is a moment when a buyer might start looking. If your brand is
linked to that moment in their memory, you're mentally available. If not,
you're invisible — regardless of how good your product is.

**How to increase mental availability:**
- Be consistently present where your buyers spend attention (content, events,
  communities, partnerships).
- Reach broadly. Sharp: "Successful advertising reaches millions of consumers
  who have a very low probability of buying next week or month."
- Build distinctive brand assets (logo, colors, tone, tagline) that are easy
  to recognize and hard to confuse with competitors.
- Associate your brand with as many relevant CEPs as possible.
- Advertise continuously, not in bursts. Memory decays in gaps.

### Physical Availability

How easy it is to find, try, and buy your product when the buyer is ready.

**For a SaaS startup, physical availability means:**
- Can they find you via the search terms they'd naturally use?
- Is your pricing transparent or hidden behind "Contact Sales"?
- Can they start a free trial without friction?
- Are you present on the platforms and marketplaces where buyers look?
- Do you integrate with the tools they already use?
- Are you listed on relevant review sites, directories, and comparison pages?

**Low physical availability examples:**
- Requiring a demo call before showing the product.
- No pricing page.
- Complex signup with multiple approval steps.
- Not being on G2, Capterra, or relevant industry directories.
- No integrations with common tools in the buyer's stack.

## Sharp's Laws — Startup Implications

### 1. Growth comes from penetration, not loyalty (Double Jeopardy)

Big brands are big because they have more customers, not because their
customers buy more often. The loyalty metrics between big and small brands
barely differ — a phenomenon Sharp calls the "Double Jeopardy Law." Small
brands suffer twice: fewer buyers AND slightly lower loyalty.

The Double Jeopardy Law is one of the most replicated findings in marketing
science. It holds across categories, countries, and decades. The mechanism:
small brands have fewer memory structures in fewer people's heads, so even
the people who do buy from them buy slightly less often and feel slightly
less loyal. Loyalty is largely a function of penetration, not the other way
around.

**Startup implications:**

- **Don't over-invest in delighting your 10 power users.** Invest in reaching
  the 10,000 people who've never heard of you. Your growth ceiling is set by
  how many people know you exist.
- **Some churn is structural, not a product problem.** Small brands naturally
  have slightly lower repeat rates. If your churn is in the normal range for
  your category, the fix is more customers (acquisition), not more retention
  features. Don't build loyalty programs when you need reach.
- **You can't loyalty your way to growth.** The data is unambiguous: brands
  grow by increasing penetration (more buyers), not by increasing purchase
  frequency among existing buyers. A startup that focuses all energy on
  upselling and expanding 50 customers instead of acquiring 500 new ones is
  fighting the math.
- **Benchmark churn against the category, not against zero.** Every brand
  loses customers. Sharp's data shows defection rates are remarkably similar
  across brands in a category. If your churn looks like the category average,
  the constraint is almost certainly acquisition, not retention.

### 2. Light buyers and non-buyers are the growth engine

Your next customer almost certainly doesn't use a competitor's product every
day. They're a light buyer of the category, or they've never bought at all.
They aren't evaluating 5 options in a spreadsheet. They'll buy whatever comes
to mind and is easy to access.

**Startup implication:** Your marketing should reach the broadest relevant
audience, not just the people who match a hyper-specific ideal customer
profile. This feels wrong to founders — "but we need to focus!" — but the
data is clear: narrow targeting for awareness is a trap. You're hiding from
the people who would buy if they knew you existed.

**The uncomfortable truth:** Tight ICP for sales qualification, yes. But for
awareness? Cast wider than feels sensible. Your growth comes from light buyers
and non-buyers who haven't heard of you — not from delighting your power users.

### 3. Duplication of Purchase Law

Brands share customers with other brands roughly in proportion to market
share. Your customers also buy from competitors — and competitors' customers
are your potential buyers. There is no such thing as a walled-off loyal
segment.

**Startup implications:**

- **Your competitors' customers are your market.** Don't differentiate *away*
  from the category. Compete for the same buyers by being more mentally and
  physically available.
- **"Niche" is usually a rationalization for low penetration.** Sharp's data
  shows that truly niche brands (serving a segment no one else serves) are
  vanishingly rare. Most small brands are simply small — they serve the same
  buyers as large brands, just fewer of them.
- **Category conventions matter.** If every competitor has a free trial and
  you require a demo call, you're reducing physical availability for the
  shared buyer pool. Match category hygiene, then differentiate on
  distinctiveness.

### 4. Reach > Frequency

Being seen once by 1,000 people beats being seen 10 times by 100 people.

**Startup implication:** Diversify distribution. Don't put all content on one
channel. Don't depend on one partnership. Each new channel = more reach =
more people who know you exist.

### 5. Distinctiveness > Differentiation

You don't need to be "the differentiated brand." You need to be the one they
can recognize. Distinctive brand assets (colors, logo, visual style, tone,
tagline, sounds) compound over time.

**Startup implication:** Pick your brand assets early and use them relentlessly.
Consistency beats creativity. A founder who posts with the same visual style,
tone, and topics every week builds more mental availability than one who
reinvents their approach monthly.

### 6. Advertising is a weak force — and that's the point

Each exposure nudges the probability of buying up a tiny amount. You can't
measure any single exposure's impact. But from the brand's perspective, moving
from 1/500 probability to 2/500 across millions of people doubles sales.

**Startup implications:**

- **Don't expect any single piece of content, ad, or outreach to produce
  immediate results.** Founders who post "10 LinkedIn posts and got no leads"
  misunderstand the mechanism. You're building mental availability, one tiny
  nudge at a time.
- **Consistency beats virality.** A viral post gives you a one-time spike that
  decays. A consistent weekly cadence across 3 channels builds compounding
  memory structures. The startup that posts every week for a year beats the
  one that goes viral once and then goes silent.
- **Continuity > bursts.** Memory decays during gaps. Sharp's data shows
  brands that advertise continuously maintain mental availability; brands
  that do big bursts with long gaps lose it between campaigns. For a startup,
  this means: don't save content for a "launch." Publish steadily.
- **Measure reach, not engagement.** Engagement metrics (likes, comments)
  measure the small audience that already knows you. Reach metrics (unique
  viewers, impressions across channels) measure whether you're expanding
  mental availability. Optimize for reach.

## The Sharp Diagnostic for Startups

The operational version of this diagnostic (integrated into the constraint
workflow) is in `stages/growth.md` under "Before You Build Anything."

When a startup has good retention (users who activate tend to stay) but flat
growth, apply this diagnostic:

1. **"Do enough of the right people know we exist?"**
   If no → the constraint is mental availability. Invest in reach, content,
   partnerships, presence at CEPs. Do NOT build another feature.

2. **"Can they easily find and try/buy us when they want to?"**
   If no → the constraint is physical availability. Fix distribution, signup
   friction, pricing transparency, marketplace presence.

3. **"Are we distinctive enough to be remembered?"**
   If no → invest in brand assets. Consistent visual identity, recognizable
   tone, memorable positioning.

4. **"Are we associated with the right buying situations?"**
   Map your CEPs. For each one, ask: "Would someone in this situation think of
   us?" If not, that's a gap to fill with content, advertising, or positioning.

## The CEP Mapping Exercise

Category Entry Points are the specific situations, needs, or triggers that
cause someone to think about your product category. Mental availability means
being the brand linked to those moments. This exercise maps your CEPs
systematically so you know where you're strong, where you're invisible, and
where to invest.

### Step 1: List your CEPs (30 min, once)

Pull from three sources:

1. **JTBD interviews / 5-minute canvases.** Every struggling moment you've
   recorded is a CEP. If you have 8-12 canvases, you already have the raw
   material.
2. **Your own experience and observation.** What situations cause someone in
   your market to start looking for a solution? Think about triggers, not
   demographics. "Quarterly board meeting reveals pipeline is thin" is a CEP.
   "VP of Sales" is not.
3. **Competitor messaging.** What situations do competitors' landing pages,
   ads, and case studies describe? Those are CEPs they've identified.

Aim for 8-15 CEPs. Fewer means you're too narrow; more means you're listing
sub-variations. Group similar triggers.

**CEP format:** A short situational phrase in the buyer's language.
Not "pipeline management" — rather "realized we don't know which deals will
close this quarter." Not "team productivity" — rather "sprint review showed
nothing shipped for the second week in a row."

### Step 2: Score your coverage (15 min, quarterly)

For each CEP, score two things:

| CEP | Frequency (how often does this trigger?) | Our association (would they think of us?) |
|---|---|---|
| _[situational trigger]_ | High / Medium / Low | Strong / Weak / None |

**Frequency** estimates how often this trigger fires across your market. A
CEP that happens weekly to thousands of people is more valuable than one
that happens once a year to a few.

**Association** is honest self-assessment: if someone experienced this trigger
right now, would your brand come to mind? "Strong" = you've published content,
run ads, or have testimonials directly addressing this moment. "Weak" = you
address it tangentially. "None" = you're invisible here.

### Step 3: Prioritize gaps (10 min)

**High-frequency CEPs where your association is Weak or None are your biggest
opportunities.** These are the moments where lots of potential buyers are
entering the category and you're not in the consideration set.

Pick 2-3 gaps to close per quarter. For each one, define a concrete action:
a content piece, a landing page, a case study, a partnership, a conference
talk — something that puts your brand in front of people experiencing that
trigger.

### Step 4: Review quarterly

Re-score the table. Did your association strengthen on the CEPs you targeted?
Add any new CEPs that emerged from recent JTBD data. Remove any that turned
out to be low-frequency.

---

## The Physical Availability Audit

Physical availability is how easy it is to find, try, and buy your product
once someone wants to. Mental availability gets you into the consideration
set; physical availability determines whether the buyer can act on it. Both
must be present.

### The audit checklist

Score each dimension: Good / Needs work / Missing.

**Findability — can they get to you?**

| Dimension | What to check |
|---|---|
| Search terms | Do you rank for the terms a buyer would naturally type when the struggling moment hits? Not your brand name — the problem description. |
| Review sites & directories | Are you listed on G2, Capterra, Product Hunt, or the relevant vertical directories for your category? Are reviews recent? |
| Marketplace presence | If your category has marketplaces or app stores (Shopify App Store, Salesforce AppExchange, etc.), are you present? |
| Comparison pages | When someone searches "[your category] vs [competitor]" or "best [category] tools," do you appear? |
| Referral paths | Can an existing customer easily share or recommend you? Is there a referral link, a shareable report, an embeddable widget? |

**Trial friction — can they try you?**

| Dimension | What to check |
|---|---|
| Signup flow | Can they start in under 2 minutes with no human involvement? Every required field, approval step, or "Contact Sales" gate is friction. |
| Time to value | How long from signup to the first moment of real value? Measure this in minutes, not days. |
| Pricing transparency | Is pricing visible on the website? Hidden pricing is a physical availability barrier — buyers who can't assess cost drop out silently. |
| Free tier / trial | Is there a way to experience the product before committing money? Free trial, freemium tier, sandbox, or interactive demo. |

**Purchase — can they buy easily?**

| Dimension | What to check |
|---|---|
| Self-serve purchase | Can they enter a credit card and start paying without a sales call? For SMB and mid-market, this is table stakes. |
| Integration ease | Do you integrate with the tools already in their stack? Each missing integration is a physical availability gap. |
| Procurement friction | For enterprise: do you support SSO, SOC 2, standard MSAs, procurement portals? Each missing checkbox is a blocker. |

### Scoring and action

Count the "Needs work" and "Missing" items. If you have more than 3 gaps in
any section, that section is a constraint on physical availability. Fix the
highest-frequency gaps first — the ones that affect the most buyers in your
primary segment.

Run this audit quarterly, or whenever the constraint review reveals that
acquisition is healthy (people are finding you) but activation is not (they're
not starting or converting). That pattern often indicates a physical
availability problem, not a product problem.

---

## Building Mental Availability: The Operational Protocol

The weekly, monthly, and quarterly cadences for building mental availability
live in the stage files where they're used operationally:

- `stages/growth.md` — "The Awareness Cadence" section (weekly/monthly
  rhythms, content cadence guidelines by team size)
- `stages/scaling.md` — "Before You Build: The Awareness Check at Scale"
  (segment expansion diagnostic, quarterly CEP re-mapping)

---

## Connecting Sharp to Goldratt and Maurya

Sharp's insight maps directly to the customer factory:

- **Mental availability** is the input rate of the customer factory. It
  determines how many unaware visitors become aware visitors.
- **Physical availability** is the friction coefficient at the Acquisition and
  Activation steps.
- When the customer factory's constraint is at the top of the funnel
  (Acquisition), Sharp's framework provides the specific diagnosis and remedy.

Goldratt would say: "If nobody knows you exist, awareness IS your constraint.
Exploit it (use existing channels more effectively), subordinate to it (the
whole team creates content and distribution), then elevate it (invest in paid
reach, hire marketing)."

The common founder mistake — building another feature when the constraint is
awareness — is the exact equivalent of optimizing a non-constraint machine on
the factory floor. It looks productive. It changes nothing about throughput.

---

## Connecting Sharp to Ritson

Sharp emphasizes distinctiveness over differentiation. Ritson says: both.
They're complementary — distinctiveness gets you noticed, differentiation
gets you chosen. A brand needs both to grow.

See `references/pillar-ritson.md` for the full treatment: differentiation
vs. distinctiveness, brand codes, STP, positioning discipline, and the
long vs. short budget allocation rule.

FILE:references/pillar-strategy.md
# Pillar 6: Strategic Thinking — Reference

Three lenses for seeing strategy clearly: Rumelt on what makes strategy
good or bad, Clausewitz on operating under uncertainty, and Dixit &
Nalebuff on competitive dynamics. These sit above the operational
frameworks — they shape *how you think*, not *what you do*.

## Contents
- [When to Load This File](#when-to-load-this-file)
- [Rumelt: Good Strategy Bad Strategy](#rumelt-good-strategy-bad-strategy)
- [Clausewitz: On War](#clausewitz-on-war)
- [Dixit & Nalebuff: The Art of Strategy](#dixit--nalebuff-the-art-of-strategy)
- [Connecting to the Other Pillars](#connecting-to-the-other-pillars)
- [Alignment Replaces Control](#alignment-replaces-control)

---

## When to Load This File

Load when the founder's problem is not operational but *strategic*:
- They have a plan but it is not actually a strategy (goals disguised as strategy)
- They are paralyzed by uncertainty and cannot commit to a direction
- They are overextended and do not know when to stop pushing
- They are facing a competitor and do not know how to respond
- They need to think through a negotiation, pricing decision, or partnership
- The team is demoralized despite reasonable metrics

If the problem is "which funnel step is broken," use the operational
pillars. If the problem is "we do not have a real strategy," start here.

---

## Rumelt: Good Strategy Bad Strategy

**Source:** Richard Rumelt, *Good Strategy Bad Strategy* (2011) and
*The Crux* (2022).

### The Kernel of Strategy

Every good strategy has exactly three elements:

1. **Diagnosis** — What is going on here? Name the challenge. Not a list
   of facts — an interpretive frame that identifies the critical obstacle.
   A great deal of strategy work is trying to figure out what is going on,
   not deciding what to do.

2. **Guiding Policy** — The overall approach to overcoming the obstacle.
   Like guardrails on a highway: it directs and constrains action without
   fully defining it. It is NOT a goal or a vision. It is an approach.

3. **Coherent Actions** — Feasible, coordinated resource commitments and
   maneuvers that carry out the guiding policy. The key word is *coherent*:
   actions must reinforce each other, not conflict. Coordination of action
   is the most basic source of leverage in strategy.

**The test:** When a founder presents their "strategy," check: Is there a
diagnosis? A guiding policy? Actions that cohere? If any is missing,
it is not a strategy.

**Relationship to Ritson:** The kernel maps directly to Ritson's
Diagnosis → Strategy → Tactics. Rumelt is domain-general; Ritson is
marketing-specific. They reinforce each other.

### The Four Signs of Bad Strategy

Bad strategy is not the absence of good strategy — it is an active thing:

1. **Fluff** — Buzzwords masquerading as insight. "Customer-centric
   intermediation" instead of naming the actual problem. If you read it
   and think "duh" or you cannot tell what it means, it is fluff.

2. **Failure to face the challenge** — The strategy never names the
   obstacle. Without a diagnosis, you have a wish list, not a strategy.

3. **Mistaking goals for strategy** — "Our strategy is to grow 40%
   year-over-year" says nothing about how to overcome the obstacles to
   that growth. Ambition is not strategy.

4. **Bad strategic objectives** — A laundry list of unconnected tasks
   (dog's dinner), or restating the problem at a higher altitude
   (blue sky). Neither provides direction.

**Root cause:** Unwillingness to make the hard choices that disappoint
some stakeholders. Bad strategy is conflict avoidance dressed up as planning.

**Coaching move:** When you see bad strategy, name which of the four
signs is present. Then ask: "What is the actual obstacle you are trying
to overcome?"

### The Crux

From *The Crux* (2022). The crux is the most important challenge that
is also *addressable* — solvable with available resources and skills.

Two criteria:
- **Importance** — threatens viability or represents a major opportunity
- **Addressability** — can actually be acted on with what you have

The crux is NOT simply the biggest problem. "The market is not ready"
may be true but is not addressable. "We have not proven the job exists
for early adopters" is addressable through interviews and experiments.

**How to find it:**
1. List all problems and opportunities
2. Cluster related challenges
3. Rate each by importance AND addressability
4. Ask: "What about this is difficult?"

**Relationship to Goldratt:** The crux and the constraint are
philosophically identical — the one point where focused effort yields
system-level improvement. The crux adds the explicit addressability
filter that Goldratt assumes.

### Proximate Objectives

A proximate objective is close enough to be feasible given current
skills and resources. It is not an aspiration — it is a target you can
overwhelm.

**The leader's job:** Absorb the complexity and pass the team a simpler,
solvable problem.

**Key question:** "What one feasible objective, when accomplished,
would make the biggest difference?" Phrase it as a task, not a goal.

How "proximate" something is depends on who you are. What is proximate
for a funded 20-person team is not proximate for a solo founder. The
more uncertain the situation, the more proximate the objective must be.

**Relationship to GOLEAN:** The proximate objective IS the next
experiment — the smallest decisive step.

### Chain-Link Systems

A system has chain-link logic when performance is limited by its weakest
link. Strengthening any other link does not improve the system.

**Key insight:** In chain-link systems, individual links have no
incentive to improve alone — their improvement is wasted if other
links remain weak. This creates stuck systems that require simultaneous
system-wide change, not incremental improvement.

**When chain-link systems work, they create durable advantage.**
Competitors cannot copy one piece — they must replicate the entire
system simultaneously. IKEA's flat-pack + warehouse + global supply +
self-assembly is a chain-link system. No single element can be copied
in isolation.

**Relationship to Goldratt:** Chain-link logic is why subordination
matters. Improving a non-constraint link is waste. It also explains
why tightly integrated startups build moats that competitors with
better individual components cannot breach.

### Sources of Power

**Leverage** — Anticipation (how will others behave?) + pivot points
(where does small effort produce large effect?) + concentration
(all resources on the fewest pivot points). This IS Goldratt's
"exploit the constraint."

**Dynamics** — Waves of change (technology, regulation, competition)
create new advantages. Key: understand the forces behind the wave to
find second-order effects. The second-order effects are where the
opportunity is.

**Inertia** — Competitor inertia is YOUR advantage. Three types:
routine (processes persist despite changed conditions), cultural
(social behaviors resist change), proxy (clinging to declining
revenue streams). Netflix vs. Blockbuster: retail-location inertia
prevented adaptation.

**Entropy** — Without active management, organizations drift toward
disorder. The weekly review is the anti-entropy mechanism.

**Design** — Resources and tight coordination are partial substitutes.
An under-resourced startup must compensate with tighter integration.

---

## Clausewitz: On War

**Source:** Carl von Clausewitz, *On War* (1832). Military strategy
classic whose core concepts translate directly to operating under
uncertainty with limited resources.

### Fog of War

Three-quarters of strategic decisions are made under uncertainty.
Information is incomplete, often contradictory, frequently wrong.
The fog does not lift with more data — it shifts.

**Startup translation:** Every meaningful decision — which segment,
whether the product works, why churn — is made under fog. Customer
interviews give partial signal. Analytics show what happened, not why.
The fog is permanent, not a temporary condition.

**Coaching move:** Founders who wait for certainty never act. Founders
who ignore uncertainty act recklessly. Design experiments that reduce
fog in one specific area rather than seeking general clarity.

### Friction

The accumulation of countless small difficulties that make even simple
plans hard to execute. Not one big obstacle — the compound effect of
many small ones cascading.

**Startup translation:** The demo that crashes in the live call. The
developer who is sick on ship day. The payment processor that flags
your account. None individually fatal — but they accumulate. Startups
with high WIP experience more friction because every parallel
initiative creates more surfaces for friction to act on.

**Coaching move:** Keep plans simple. Reduce WIP ruthlessly — fewer
things in motion means less total friction. Build buffers (connects
to CCPM estimation). Every parallel initiative multiplies friction.

### Center of Gravity (Schwerpunkt)

The single source from which the system draws its strength. Strike it
and the whole structure weakens. Protect yours and you remain strong.

**Startup translation:** For your startup, it is whatever single thing
the business depends on — the founder's customer relationships, a
single distribution channel, the core insight about the job. For a
competitor, it might be a key contract, network effects in one niche,
or a regulatory moat.

**Relationship to Goldratt:** The constraint IS the center of gravity.
Schwerpunkt also means "main effort" — the place where you concentrate
resources. This is the same as "exploit the constraint."

### Culminating Point

The moment when an advance has extended so far it can no longer sustain
itself. Beyond this point, continued pushing does not produce gains —
it produces vulnerability.

**Startup translation:** Found product-market fit in one segment, so
you expand to three simultaneously. Each new segment dilutes focus,
stretches cash, strains the team. Common forms:
- Market expansion too early (enterprise when built for SMB)
- Feature bloat for edge cases while core users churn
- Hiring ahead of revenue

**Coaching move:** "Are you still gaining ground, or just burning more
to hold position?" The correct response to hitting the culminating
point is consolidation — stop the advance, secure what you have,
rebuild strength.

### Concentration of Force

Do not spread forces across many objectives. Concentrate everything at
the decisive point.

**Clausewitz:** "There is no higher and simpler law of strategy than
keeping one's forces concentrated."

**Startup translation:** The single most violated principle. Founders
spread across five segments, three channels, four features. PayPal
succeeded by concentrating on eBay power sellers — tiny, dense market —
rather than all online payments.

**Relationship to Goldratt:** Concentration of force IS subordination.
Once you identify the constraint, everything else supports it. WIP
limits are concentration of force in operational form.

### Defense vs. Offense

Defense is the stronger form. It is easier to hold than to take. But
defense alone cannot win — at some point you must counterattack.

**When to defend:** Pre-product-market fit (understand the terrain,
build your position). When a larger competitor enters your space
(deepen your niche, let them overextend). Cash runway IS defense —
every month buys time for friction to work in your favor.

**When to attack:** Product-market fit confirmed. Clear retention
evidence. Enough resource to sustain a push. You can identify where
the competitor is overextended.

### Moral Forces

Confidence, determination, shared purpose. Often determine outcomes
more than material resources.

**Clausewitz:** "The physical forces are almost no more than the wooden
handle, whilst the moral are the noble metal, the real weapon."

**Startup translation:** Founder will is the single most important
moral force. When the founder loses conviction, everything stops. Small
wins compound into moral force — this is why the weekly experiment
cadence works. A small, motivated team outperforms a large, demoralized
one.

**Coaching move:** When diagnosing a struggling startup, check moral
forces alongside material ones. A burnt-out team will not execute
regardless of strategy. Help the founder find their spark.

### Coup d'Oeil

The ability to rapidly grasp the essential truth of a complex situation.
Not analysis — pattern recognition built from experience. Useless
without determination (courage to act on what you see).

**Coaching connection:** Coaching develops coup d'oeil by exposing
founders to patterns. The weekly review is training — it forces regular
whole-picture assessment that builds pattern recognition over time.

---

## Dixit & Nalebuff: The Art of Strategy

**Source:** Avinash Dixit & Barry Nalebuff, *The Art of Strategy* (2008).
Game theory applied to business decisions — when your outcome depends on
what the other side does.

### Look Forward, Reason Backward

The fundamental principle. Before acting, think about where you want to
end up, then work backward to figure out what to do now. In sequential
decisions (hiring, fundraising, product launches), map the game tree
forward and reason back from the outcomes.

**Startup translation:** Before launching a feature, building a channel,
or entering a market — "If this works, what happens next? If it does
not, what are we left with?" Founders who only think one move ahead get
trapped. Founders who trace the game forward see dead ends before
investing.

### Commitment and Credibility

A strategic move is credible only if the other side believes you will
follow through. Three types:
- **Unconditional commitment** — burn the boats (signing a lease,
  publishing a price, hiring for a specific role)
- **Threats** — "If you do X, I will do Y" (credible only if Y is in
  your interest to carry out)
- **Promises** — "If you do X, I will do Y" (credible only if you
  cannot easily renege)

**Startup translation:** Your pricing page is a commitment. Your
roadmap is a promise. Your public launch date is a burned boat.
Founders who keep all options open signal to customers, investors, and
partners that nothing is certain — which reduces trust and slows deals.
Strategic commitment accelerates by reducing everyone else's
uncertainty.

**Eight devices for making commitments credible:** Contracts (with
penalties), reputation (consistent past behavior), burning bridges
(eliminating retreat), cutting off communication (delegating to agents
with strict instructions), brinkmanship (raising shared risk), moving
in small steps (phased milestones), teamwork (mutual accountability),
and mandated agents (lawyers, advisors who execute without emotion).

**Coaching move:** "What would you need to commit to, publicly and
irreversibly, for this plan to work?"

### BATNA — Your Fallback Position

Best Alternative to Negotiated Agreement. Your power in any negotiation
comes from what happens if the deal fails. A founder with revenue and
multiple interested VCs has a strong BATNA. A founder with 3 months of
runway and one interested VC has a weak one.

**Coaching move:** Before any negotiation — fundraising, partnership,
enterprise deal — "What is your best alternative if this falls
through?" Strengthen the BATNA before entering the negotiation.

### Types of Games

Not all competitive situations are the same:

| Type | What it means | Startup example |
|------|---------------|-----------------|
| Zero-sum | Your gain is their loss | Bidding for an exclusive contract |
| Positive-sum | Both sides can win | Platform partnerships, integrations |
| Sequential | Moves happen in order | Fundraising rounds, hiring sequences |
| Simultaneous | Moves happen at once | Pricing decisions, feature launches |
| One-shot | Single interaction | Acquisition negotiation |
| Repeated | Ongoing relationship | Customer renewals, investor updates |

**Key insight:** Most startup situations are positive-sum and repeated.
Treating them as zero-sum and one-shot (aggressive negotiation, burning
bridges) is a strategy error. Cooperation dominates in repeated games.

### Prisoner's Dilemma and Cooperation

When both parties would benefit from cooperation but individual
incentives push toward defection. In one-shot games, defection wins.
In repeated games, tit-for-tat is the dominant strategy. Four
properties: **nice** (cooperate first), **retaliatory** (mirror
defection immediately), **forgiving** (return to cooperation when
they do), **clear** (predictable, so the other side can learn).

**Startup translation:** Pricing wars, feature-copying races, and
aggressive sales tactics are defection moves. They work in one-shot
games but destroy value in repeated ones. With customers, investors,
and partners you will see again, lead with cooperation and match their
behavior.

**Adverse selection warning:** Uniform terms attract the worst fits.
A "free forever" tier attracts users who will never pay. Below-market
comp "made up in equity" attracts people who cannot get market-rate
jobs. Design tiers and terms that screen for the type you want.

### Information Asymmetry

When one side knows more than the other:
- **Signaling** — the informed side reveals information through costly
  actions (offering a free trial signals product confidence; publishing
  metrics signals traction)
- **Screening** — the uninformed side designs mechanisms to sort types
  (tiered pricing reveals willingness to pay; pilot programs reveal
  serious buyers from tire-kickers)

**Startup translation:** Every pricing tier, trial period, and case
study is a signaling or screening mechanism. "Book a demo" screens for
serious buyers. A published customer count signals social proof.
Founders who understand information asymmetry design their sales
process to reveal and signal the right information at the right time.

### First-Mover vs. Fast-Follower

First-mover advantage is real but narrow. It applies when:
- Network effects exist (the first platform to reach critical mass wins)
- Switching costs are high (once customers adopt, they stay)
- You can lock up scarce resources (distribution, talent, data)

Fast-follower advantage applies when:
- The market is uncertain (let the first mover prove demand)
- Technology is evolving quickly (the first mover's version becomes
  obsolete)
- Customer education is expensive (let the first mover pay for it)

Golder & Tellis (1993): 47% of first movers in new categories failed,
vs. 8% for fast followers who entered an average of 13 years later.
Google followed AltaVista. Facebook followed Friendster. iPhone
followed BlackBerry.

**Coaching move:** "Are you first because you see something others
do not, or are you first because nobody else thinks this is worth
doing?" The former is advantage. The latter is a warning.

---

## Connecting to the Other Pillars

These three thinkers provide the *strategic reasoning layer* that sits
above the operational frameworks:

| Concept | Operational Equivalent | What It Adds |
|---------|----------------------|--------------|
| Rumelt's kernel | Ritson's Diagnosis → Strategy → Tactics | Domain-general strategy test |
| The crux | Goldratt's constraint | Addressability filter |
| Proximate objectives | GOLEAN experiment | Feasibility test for the next step |
| Chain-link systems | Subordination | Why improving non-constraints is waste |
| Bad strategy signs | Misdiagnoses reference | Tests for fluff, goals-as-strategy |
| Fog of war | Weekly review under uncertainty | Validates that uncertainty is permanent |
| Friction | WIP limits, CCPM buffers | Why simple plans and fewer initiatives |
| Center of gravity | The constraint | Same concept, different tradition |
| Concentration of force | Subordination, WIP limits | The strategic law behind the tactic |
| Culminating point | When to stop expanding | Framework for disciplined restraint |
| Moral forces | Team morale, founder will | Human element the metrics miss |
| Look forward, reason backward | "Before You Build" check | Think through the game tree |
| Commitment | Pricing, positioning, roadmap | Why keeping options open slows you down |
| Cooperation in repeated games | Customer/partner relationships | Why burning bridges is strategy error |
| BATNA | Fundraising, enterprise sales | Strengthen your fallback before negotiating |
| Adverse selection | Pricing tiers, hiring, free tiers | Why uniform terms attract the wrong people |
| First-mover data | "Before You Build" check | 47% of first movers fail — defensibility matters |

---

## Alignment Replaces Control

This is the principle that connects everything above.

Clausewitz showed that fog and friction make centralized control
impossible. You cannot see everything, plans break on contact with
reality, and the commander who tries to control every decision becomes
the bottleneck. The military solution: **mission command**
(Auftragstaktik) — tell people the intent, not the steps. When
everyone understands the purpose, they can act without permission.

The startup version: a founder who has clearly named the constraint,
the guiding policy, and the job-to-be-done gives the team everything
they need to make good autonomous decisions. A founder who has not
done that work ends up approving every feature, reviewing every deal,
and attending every meeting — not because the team is weak, but
because nobody else knows the intent.

**Naming the constraint is an alignment act.** When the whole team
knows "our constraint is activation — people sign up but do not come
back after day one," every person can evaluate their own work: "Does
this serve activation?" They do not need to ask. When the constraint
is unnamed, everything feels equally important, and every decision
routes through the founder.

**How the existing frameworks create alignment:**

| Framework | Alignment mechanism |
|-----------|-------------------|
| Goldratt (subordination) | Everyone knows what the constraint is and orients to it |
| Rumelt (guiding policy) | Guardrails that constrain without micromanaging |
| Rumelt (proximate objectives) | Leader absorbs complexity, team gets solvable problems |
| Ritson (positioning) | Two associations — everyone knows what we stand for |
| JTBD (job statement) | One sentence that tells the team what customers hire us for |
| GOLEAN (experiment) | The experiment is assigned, then the founder gets out of the way |
| Weekly review | Regular checkpoint where the constraint is re-confirmed or shifted |
| WIP limits | Structural limit that prevents drift without requiring oversight |

**The anti-pattern:** The founder who says "I need to be involved in
everything" usually has an alignment problem, not a delegation
problem. The fix is not "trust your team more" — it is "name the
constraint, state the guiding policy, assign the experiment, and
get out of the way." Alignment enables autonomy. Without it, control
is the only option, and control does not scale.

**Coaching move:** When a founder is the bottleneck, do not start with
delegation. Start with: "Can everyone on your team name the current
constraint? Can they state who you are building for and why? If not —
that is the problem. Not their capability. Your clarity."

---

**The hierarchy:** JTBD tells you what job the customer hires you for.
Goldratt tells you where the system is stuck. Maurya maps the startup
machine. Sharp and Ritson handle awareness and marketing strategy.
Rumelt, Clausewitz, and Dixit & Nalebuff tell you whether what you
are doing is actually a strategy, how to operate when you cannot see
clearly, and what the other side will do. And alignment is the
mechanism that lets all of it work without the founder in the room.

FILE:references/weekly-diagrams.md
# Weekly Review Diagram

One diagram for the weekly constraint review. Write it as a `.mmd` file, then
render with `scripts/render-diagram.mjs`.

## Customer Factory Funnel

Visualize the five macro steps with conversion rates. Highlight the constraint
node in red.

```mermaid
graph TD
    UV["Unaware Visitors<br/><b>~10,000/mo</b>"] -->|"Acquisition · 3%"| IP["Interested Prospects<br/><b>~300/mo</b>"]
    IP -->|"Activation · 40%"| AU["Active Users<br/><b>~120/mo</b>"]
    AU -->|"Revenue · 25%"| PC["Paying Customers<br/><b>~30/mo</b>"]
    PC -->|"Retention · 85%"| RC["Retained Customers<br/><b>~25/mo</b>"]
    RC -->|"Referral · 10%"| UV

    style AU fill:#ff6b6b,stroke:#c0392b,stroke-width:3px,color:#fff
```

**Rules:**
- Replace numbers with the startup's actual (or estimated) metrics.
- Apply the red highlight (`fill:#ff6b6b,stroke:#c0392b,stroke-width:3px,color:#fff`)
  to the node representing the current constraint.
- If the constraint is between steps (a conversion rate), highlight both adjacent
  nodes.
- Add a note below identifying the constraint in plain language.

## Rendering

Install dependencies once:
```bash
cd scripts && npm install
```

Render:
```bash
node scripts/render-diagram.mjs funnel.mmd funnel.svg
node scripts/render-diagram.mjs funnel.mmd funnel.svg --theme brand-light
```

**Themes:**
- `brand-dark` — dark palette (violet/indigo). Default when no `--theme` flag.
- `brand-light` — white background with violet accents. Use for docs or slides.
- Others: `zinc-dark`, `tokyo-night`, `catppuccin-mocha`, `nord`, `dracula`,
  `github-dark`, `zinc-light`, `tokyo-night-light`, `catppuccin-latte`, `github-light`.

FILE:references/weekly-review.md
# Weekly Review

Load this file when the founder asks for a weekly review, check-in, or wants to review the week.
Run the format for their stage. Keep it tight — 10-25 minutes max depending on stage.

---

## Pre-revenue (10 min)

**1. Conversations (5 min)**
- How many real conversations with potential customers this week?
- What did you learn that you didn't know on Monday?
- Did anything surprise you — positive or negative?

**2. Hypothesis check (3 min)**
- State the current hypothesis in one sentence: *"[Customer] struggles with [problem] and will pay for [solution]."*
- Is this still what you believe? What evidence pushed it forward or back?

**3. Next week's one thing (2 min)**
- What is the single most important thing to learn or test next week?
- Not build. Learn or test.

---

## Growth (10 min)

**1. Constraint (2 min)**
- Name the current constraint: acquisition / activation / revenue / retention / flow.
- Did it move this week? Throughput up, down, or flat?

**2. Numbers (3 min)**
- New people found you this week: ___
- Activated (reached aha moment): ___
- Paid: ___
- Churned: ___
- Where is the biggest drop-off?

**3. Work pile (3 min)**
- What's currently in progress? (List it)
- Anything that's been in progress for >2 weeks? Why?
- What got finished and shipped?

**4. Next week's 3 priorities (2 min)**
- Only things that serve the constraint.
- Name them. One person owns each.

---

## Scaling (25 min)

**1. Funnel snapshot (5 min)**
Draw the funnel: Awareness → Acquisition → Activation → Revenue → Retention
Mark the step with the biggest drop-off. Is it the same as last week?

**2. Buffer and flow (5 min)**
- Where is work piling up right now?
- Where is capacity idle?
- Any projects that have been "almost done" for >2 weeks?

**3. Initiative traffic lights (10 min)**
For each active initiative, assign:
- 🟢 On track — constraint is being served, throughput moving
- 🟡 At risk — behind or blocked, needs attention this week
- 🔴 Stalled — not moving, consider pausing or killing

**4. Policy constraint scan (3 min)**
- Is there a rule, process, or habit that made sense 6 months ago but is now slowing things down?
- Common culprits: approval chains, meeting schedules, hiring process, release gates.

**5. Next week's focus (2 min)**
- One thing the team is rallying around.
- What does "done" look like?

---

## How to run the review

- Go in order. Don't skip steps.
- If a number is missing, note it as unknown — don't estimate.
- The goal isn't to feel good about the week. It's to name the constraint and set one clear priority.
- End every review with: "What is the one thing we will not do next week that we might be tempted to do?"

FILE:scripts/package.json
{
  "name": "factory-floor-scripts",
  "private": true,
  "type": "module",
  "dependencies": {
    "beautiful-mermaid": "^1.1.3"
  }
}

FILE:scripts/render-diagram.mjs
#!/usr/bin/env node
import { renderMermaidSVG, THEMES } from 'beautiful-mermaid'
import { readFileSync, writeFileSync } from 'fs'

// Custom brand themes (violet/indigo palette)
const BRAND = {
  'brand-dark': {
    bg: '#13194A',      // darkSidebar.950
    fg: '#EDE8FF',      // violet.100
    line: '#444A78',    // darkSidebar.800
    accent: '#8447FF',  // violet.500 (primary)
    muted: '#9196BF',   // darkSidebar.500
    surface: '#3C4168', // darkSidebar.900
    border: '#444A78',  // darkSidebar.800
  },
  'brand-light': {
    bg: '#FFFFFF',
    fg: '#111111',      // neutralGray.950
    line: '#D1D1D1',    // neutralGray.200
    accent: '#8447FF',  // violet.500 (primary)
    muted: '#888888',   // neutralGray.400
    surface: '#F5F2FF', // violet.50
    border: '#DCD4FF',  // violet.200
  },
}

const ALL_THEMES = { ...THEMES, ...BRAND }

const args = process.argv.slice(2)
const flags = {}
const positional = []

for (let i = 0; i < args.length; i++) {
  if (args[i] === '--theme' && args[i + 1]) {
    flags.theme = args[++i]
  } else if (args[i] === '--transparent') {
    flags.transparent = true
  } else {
    positional.push(args[i])
  }
}

const input = positional[0]
const output = positional[1] || 'diagram.svg'

if (!input) {
  console.error('Usage: render-diagram.mjs <input.mmd> [output.svg] [--theme <name>] [--transparent]')
  console.error('       echo "graph TD; A-->B" | render-diagram.mjs - [output.svg]')
  console.error(`Themes: Object.keys(ALL_THEMES).join(', ')`)
  process.exit(1)
}

let code
try {
  code = input === '-'
    ? readFileSync('/dev/stdin', 'utf8')
    : readFileSync(input, 'utf8')
} catch (err) {
  console.error(`Error reading input: err.message`)
  process.exit(1)
}

const theme = flags.theme && ALL_THEMES[flags.theme]
  ? { ...ALL_THEMES[flags.theme] }
  : { ...BRAND['brand-dark'] }

if (flags.transparent) theme.transparent = true

try {
  const svg = renderMermaidSVG(code, { ...theme, padding: 48, nodeSpacing: 32, layerSpacing: 48 })
  writeFileSync(output, svg)
  console.log(`Rendered: output`)
} catch (err) {
  console.error(`Error rendering diagram: err.message`)
  process.exit(1)
}

FILE:stages/growth.md
# Growth: Post-Revenue Through ~$1M ARR

You have paying customers. The customer factory exists. Now you need to find
its constraint, exploit it, and run the system — not build random features.

---

## If You Don't Have Numbers

Most startups at this stage are flying on instinct and Stripe dashboards.
That's fine for the triage — use the signals table in SKILL.md. But if the
signals are ambiguous, **your first constraint-serving action is to instrument
the funnel.**

Set up tracking for:
- New trials or signups per week
- Activation rate (% who reach the "aha moment")
- Conversion to paid
- Monthly churn

This IS constraint work. You can't exploit a constraint you can't measure.
Use whatever tool you have — a spreadsheet updated weekly is enough. Don't
spend a month building a dashboard. Spend an hour setting up the tracking,
then use it.

---

## Before You Build Anything

This is the check that saves startups from their own instincts.

When a founder says "we need to build feature X," ask first: **"Is the real
problem that not enough people know you exist?"**

Sharp's research across decades of brand data shows that most potential
customers don't know you exist. When your product works (users who try it
stay) but growth is flat, the answer is almost never another feature. It's
**mental availability** — the probability your brand comes to mind when
someone has the problem you solve.

**Run this diagnostic before any growth initiative:**

1. "Do enough of the right people know we exist?" If no → invest in reach,
   content, partnerships, presence where buyers look. Do NOT build another
   feature.
2. "Can they easily find and try/buy us?" If no → fix distribution, signup
   friction, pricing transparency, marketplace presence.
3. "Are we distinctive enough to be remembered?" If no → invest in brand
   assets (visual identity, tone, tagline), not features.

**This isn't binary.** You may have awareness in one channel and be invisible
in others. You may be known to one segment but not the one that matters most.
The question isn't just "do people know us?" but "do the right people know
us, on the right channels, associated with the right struggling moments?"

Map your Category Entry Points — the 3-5 struggling moments that trigger
buying behavior. For each one, ask: "Would someone in this situation think
of us?" Gaps are where you invest in awareness. Use the 5-minute canvas
(see `stages/pre-revenue.md`) after every conversation to keep this map
current.

**The exception: features that ARE distribution.** Some features directly
serve acquisition — integrations that get you listed in a partner's
marketplace, viral sharing mechanics, embeddable widgets, API access that
turns customers into channels. The test: "Will this feature bring us new
visitors who wouldn't have found us otherwise?" If yes, it's distribution
wearing a feature hat. Build it.

Read `references/pillar-sharp.md` for the full framework, including the
laws of brand growth and CEP mapping.

### Brand Building vs. Activation: Know the Difference

When the constraint is awareness, you're doing **brand building**. When the
constraint is conversion, you're doing **activation**. These are different
types of work with different metrics and different time horizons. Don't
confuse them.

**Brand building (long-term):**
- Builds mental availability over time
- Effects take months to materialize
- Measure: reach, brand awareness, CEP coverage
- Examples: content that educates, thought leadership, sponsorships, PR

**Sales activation (short-term):**
- Converts existing demand into action
- Effects visible within days/weeks
- Measure: clicks, demos booked, trials started, conversions
- Examples: "book a demo" ads, retargeting, promos, direct outreach

**The budget rule (Binet & Field):** For established brands, ~60% brand
building, ~40% activation. For early startups, the ratio shifts toward
activation (you need revenue now), but don't go 100% activation. Even
10-20% brand investment builds memory structures that make future activation
cheaper.

**Why this matters:** Founders who run 100% activation see short-term
metrics that look fine. But they're harvesting demand without replenishing
it. Long-term growth stalls. When you finally try brand building, it takes
months to show up — and by then, you've burned runway on activation that
kept getting more expensive.

When awareness is the constraint, measure reach, not clicks. You're building
memory structures, not harvesting demand. Different work, different metrics.

See `references/pillar-ritson.md` for the full long vs. short framework.

### The Awareness Cadence (when awareness is the constraint)

**Weekly (5 min during the constraint review):**

1. **Did we publish/distribute anything this week?** One piece of content,
   one outreach batch, one partnership touchpoint — something that puts the
   brand in front of people who don't know you yet. If the answer is no,
   that's a problem.

2. **Which CEPs did we cover?** Each piece of content should map to a
   specific CEP. Track which CEPs you're covering — rotate through your
   top 5-7.

3. **Reach check.** How many *new* people saw us this week? Not engagement
   — reach (unique views, impressions, new subscribers). The trend matters
   more than the number. Flat reach with consistent publishing means you
   need a new channel.

**Monthly (20 min):**

1. **CEP coverage review.** Which CEPs have you addressed in the last 4
   weeks? If two or more high-frequency CEPs have had zero coverage,
   prioritize them next month.

2. **Channel diversity check.** If you're on fewer than 3 channels, you're
   under-diversified. Add one new channel per quarter until you're at 4-5.

3. **Distinctiveness audit.** Review the last month's content side by side.
   Does it look and sound like your brand? Distinctiveness compounds only
   through consistency.

4. **Physical availability spot-check.** Pick one item from the physical
   availability audit and verify it's still healthy. Rotate quarterly.

**Content cadence guidelines:**

| Team size | Minimum weekly output | Channel target |
|---|---|---|
| Solo founder | 1 piece (short-form) | 2 channels |
| 2-3 people | 2 pieces (1 short + 1 long or outreach batch) | 3 channels |
| 4-5 people | 3 pieces (mix of short, long, and partnerships) | 4 channels |

The key behavior is **never going dark.** A week with no output is a week
where memory structures decay. Consistency matters more than quality of
any individual piece.

---

## The System: Goldratt + Maurya

### Goldratt's Five Focusing Steps

1. **Identify** the constraint. Where does work pile up? Where do downstream
   stages starve?

2. **Exploit** the constraint. Squeeze maximum output without spending money.
   If sales is the constraint, the founder sells — no admin, no code reviews.
   If engineering is the constraint, pre-package every spec so the developer
   never waits.

3. **Subordinate** everything else. Non-constraints serve the constraint,
   even when that means they look idle. Idle capacity at a non-constraint
   is buffer, not waste.

4. **Elevate** the constraint. Only after exploiting and subordinating,
   invest real resources (hire, buy tools, outsource).

5. **Repeat.** After elevating, the constraint moves. Never let inertia
   become the constraint.

**What each role does, based on the current constraint:**

| Current constraint | Founder | Developer | Support/CS |
|---|---|---|---|
| Sales/Pipeline | 100% selling. Nothing else. | Build sales tools, demo flow, landing pages. | Case studies, FAQs, onboarding materials. |
| Engineering | Write specs, do QA, handle support to shield the dev. | Protected focus. One task at a time. | QA, bug reports, documentation, workarounds. |
| Onboarding | Help with onboarding calls. Pause selling if queue is full. | Build onboarding automation, setup wizards. | Protected focus on activating customers. |
| Awareness | Content, outreach, partnerships, speaking. | SEO pages, integrations directory, API docs. | Testimonials, case studies, social proof. |

### The Customer Factory (Maurya)

Every business is a **customer factory** — a system that takes in unaware
visitors and turns them into happy customers:

```
Acquisition → Activation → Revenue → Retention → Referral
```

Each step has a conversion rate. The step with the lowest rate relative to
your goal is your constraint. Fix that one. Ignore the others until it moves.

The factory is linear, but growth has loops. Retained customers refer new
ones. Content attracts users who generate data that improves the product
that attracts more users. When you find a reinforcing loop, invest in it —
a small improvement at any point in the loop accelerates the whole cycle.

**Throughput** = the rate at which you create happy paying customers. Not
signups, not pageviews — happy customers who achieve their desired outcome
and pay you for it.

**Key rules:**

- **Throughput > Activity.** Measure deals closed, customers activated —
  not hours worked or tasks in progress.
- **WIP is inventory, and inventory is liability.** A half-built feature
  consumes resources and generates zero revenue.
- **"Stop starting, start finishing."** Nobody begins new work until current
  work is done. If blocked, help someone else finish theirs.
- **Local optimization ≠ global optimization.** Marketing generating more
  leads while activation is broken = pouring water through a sieve.

---

## The Execution Loop: GOLEAN

Identifying the constraint tells you *where* to focus. GOLEAN tells you
*how to run the sprint*. Use it as a 2-week cycle:

1. **Go** — State the constraint. Set a goal with four numbers: **target**
   (where you want to be), **baseline** (where you are now), **trend**
   (which direction it's moving), and **timeframe** (this cycle). Example:
   "Increase trial signups from 200/mo (baseline, flat trend) to 280/mo
   by end of cycle." Not "work on acquisition."

2. **Observe** — Measure the constraint's current performance. What are the
   numbers right now? What does the funnel look like? Baseline before you act.

3. **Learn** — Run 1-2 focused experiments that target the constraint. Not
   five. Not a roadmap. One or two bets, sized to complete within the cycle.

4. **Evaluate** — Did throughput increase? Not "did we ship the thing" — did
   the constraint actually move? Check the numbers, not the activity log.

5. **Analyze** — What worked? What didn't? Systemize what worked so you
   don't lose it. Kill what didn't so you don't repeat it.

6. **Next** — If the constraint broke (throughput increased and the
   bottleneck visibly shifted), identify the new constraint. If not, run
   another experiment on the same one. Return to Go.

**Cycle length:** 2 weeks. Fast enough to learn, slow enough to execute
meaningfully. If 2 weeks feels too long, shorten to 1 week but never run
more than 2 experiments per cycle.

---

## Managing Projects Against the Constraint

### Check your team's state first

Before planning the sprint, ask: **what state is the team in?**

- **Falling behind** — backlog grows every week, morale dropping. Reduce
  scope or add capacity before doing anything else.
- **Treading water** — critical work gets done but nothing improves. Reduce
  WIP, consolidate effort, finish things. The fix is focus, not more work.
- **Repaying debt** — momentum is building, compound improvements emerging.
  Protect this time. Don't interrupt with new priorities.
- **Innovating** — low debt, high morale, new value being created. Maintain
  slack. Prevent over-commitment.

Most startup teams oscillate between the first two states. Every time you
add WIP or change priorities mid-sprint, you push the team back toward
treading water.

### Break priorities into constraint-sized tasks

After the weekly review produces your top 3 priorities, break each one into
tasks that can be completed in 1-3 days. Every task should pass the
constraint test: **"Does completing this task directly increase throughput
at the constraint?"** If the answer is "indirectly" or "eventually," it's
backlog.

**Sizing rule:** If a task will take longer than 3 days, it's too big.
Split it. Big tasks become WIP. WIP becomes inventory.

**Start from the epicenter.** Build the thing it cannot function without
first. A blog page starts with the post, not the sidebar. An onboarding
flow starts with the aha moment, not the welcome email.

### WIP limits are non-negotiable

Set your WIP limit to team size. A three-person team has 3 slots for
in-progress work. That's it. Nobody starts new work until a slot opens.
If you're blocked, help someone else finish theirs. In simulations, teams
with strong WIP limits finished **200x more projects** than teams without
them (Larson).

When a founder says "but we need to get ahead on X," the answer is: "X is
not the constraint. Starting X now increases WIP, extends lead time on
constraint work, and slows throughput. X waits."

This is Goldratt's **Drum-Buffer-Rope** in practice: the constraint sets
the pace (drum), a buffer of ready work sits in front of it, and the rope
ties new work intake to the constraint's consumption rate. Nobody starts
new work faster than the constraint can absorb it.

### Feed the constraint buffer

Maintain 2-3 tasks that are fully specified, unblocked, and ready to pull.
The person or process at the constraint should never wait for their next
piece of work. If the buffer drops below 2, refilling it is the team's
top priority.

**Who fills the buffer?** Non-constraint team members. Spec work, gather
requirements, prepare assets, remove blockers — whatever the constraint
needs to stay at full speed.

### Track throughput, not activity

The board should answer one question at a glance: **"Are we creating happy
paying customers faster than last week?"**

Track these weekly:
- **Throughput metric:** The number that measures output at the constraint
  (trials generated, customers activated, deals closed — depends on where
  the constraint is).
- **Cycle time:** How long tasks spend in progress. If cycle time is
  growing, WIP is creeping up.
- **Buffer health:** How many ready items sit before the constraint. If
  it's consistently empty, the constraint is starving.

Don't track vanity metrics (tasks completed, story points burned, hours
logged). They measure motion, not progress.

### Handle blockers by severity

- **Constraint blocker:** Drop everything. Clear it now. Every hour the
  constraint is blocked is an hour of lost throughput for the entire company.
- **Non-constraint blocker:** Note it, move on. Work on something else that
  feeds the constraint.

### Respect the delay

Most constraint work has a feedback delay. A content strategy takes 4-8
weeks to show up in acquisition. An onboarding improvement takes 2-3
cohorts to show up in activation. Set a minimum evaluation window (usually
one GOLEAN cycle) and don't judge results before it closes.

### Estimate time honestly

Most estimates fail because safety padding gets baked into each task, then
consumed by procrastination and scope creep. The fix: **strip safety from
individual tasks and pool it into a project buffer.**

**The quick protocol:**
1. Get the **focused estimate** for each task — "How long with no
   interruptions?" (50% confidence.)
2. Use the focused estimate as the task duration.
3. Add up the longest dependent chain of tasks. That's the critical chain.
4. **Buffer = critical chain × 0.4.** Add this to the end.
5. The buffer end date is the only date you commit to externally.

That's it. A 20-day chain gets an 8-day buffer. Commit date = day 28.
Don't overthink the multiplier. 0.4 works for almost everything — it's
aggressive enough to keep urgency but safe enough to absorb real surprises.

To build this skill over time, use the two-question split (focused + safe
estimate) from `references/estimation.md` — it trains you to see estimates
as ranges, not points.

**When to estimate vs. measure vs. time-box:**

| Situation | Method |
|---|---|
| Novel work, external commitment | Focused estimates + pooled buffer |
| Ongoing work with 3+ weeks of data | Cycle time measurement (median and 85th percentile) |
| Experiments, learning, customer discovery | Time-box at 2 weeks (GOLEAN cycle) |
| Quick internal sizing | T-shirt: S (hours), M (1-2 days), L (3-5 days). XL = break it down. |

**The two-question filter:** Before estimating anything, ask "Is this work
on the constraint?" If yes, estimate carefully. If no, T-shirt size it.

See `references/estimation.md` for why pooled buffers work, calibration
exercises, and alternative sizing methods for edge cases.

### Monitor with the fever chart

Track two numbers weekly: **% of work completed** vs. **% of buffer
consumed.**

- **Green (buffer < 1/3 consumed):** On track. Don't fill the slack with
  scope creep.
- **Yellow (buffer 1/3 to 2/3 consumed):** Plan a recovery option. The
  buffer is doing its job.
- **Red (buffer > 2/3 consumed):** Act now. Fix time and budget, flex
  scope. Cut features to fit the deadline. Redirect non-constraint
  capacity to help.

### Run the relay race

When someone finishes a task, the next person starts **immediately** — not
on the scheduled date. Early finishes evaporate in traditional project
management. In the relay race, they propagate forward.

### Communicate timelines honestly

Never give a point estimate externally. Always give a range.

**To a customer or stakeholder:** "We expect to deliver between [focused
estimate date] and [buffer end date]." The buffer end date is the only
commitment.

**To the team:** Communicate buffer status, not individual task deadlines.
"We've consumed 40% of buffer with 60% of work done — we're healthy."

**If someone demands a single date:** Give the buffer end date. That's
what the buffer is for.

---

## JTBD in the Weekly Rhythm

JTBD is not a one-time research project. It's a weekly habit.

**After every conversation:** Fill in the 5-minute canvas (see
`stages/pre-revenue.md`). Every sales call, demo, support ticket, and
churn conversation is JTBD data.

**During the weekly review:** Review the week's canvases. Do the forces
match your constraint diagnosis? Three canvases showing the same anxiety
might mean your highest-leverage move isn't a feature — it's a guarantee,
a testimonial, or a simpler onboarding. Update the running pattern: which
pushes, pulls, anxieties, and habits keep appearing?

**Monthly:** Review all canvases. Have your assumptions about the forces
changed? Should your messaging change? Should your constraint diagnosis
change?

**Mine what you already have:** Lost deal notes, churn conversations,
and support tickets already contain JTBD data. For lost deals: "What did
you go with instead?" For churned customers: "What are you using now?"

---

## Worked Example: Growth Stall

**ConvoAI — AI meeting summaries, B2B SaaS, 8-person team, $40K MRR.**

The founder asks: "Growth has stalled for 3 months. We think we need Slack
integration and CRM sync to compete. What should we work on?"

**Step 1: Triage.**

| Question | Answer |
|---|---|
| Enough people finding you? | ~200 trials/month, mostly from one viral blog post 6 months ago. Pipeline is thin. |
| Do signups reach the aha moment? | Yes — 60% activate within the first week. |
| Do activated users pay? | Yes — 35% convert to paid. |
| Do paying customers stay? | Yes — 90% monthly retention. |
| Is the team finishing things? | Mostly, though 2 engineers are split across 3 projects. |

**Diagnosis:** Activation, Revenue, and Retention are healthy. Acquisition
is the constraint. Almost no one is entering the funnel.

**Step 2: Run the "Before You Build" check.**

Users who try ConvoAI love it. Retention is 90%. The product works.
Building Slack integration and CRM sync is optimizing a non-constraint.
It will not move the $40K MRR number.

**Step 3: Exploit the constraint.**

The founder redirects effort to distribution with existing resources:

- Founder spends mornings on outreach, partnerships, and content instead
  of product reviews.
- One engineer moves from CRM sync to building SEO landing pages and an
  integrations directory.
- The CS person collects testimonials and case studies.
- The two engineers on 3 projects drop to 1 project each — finishing >
  starting.

**Step 4: Subordinate.**

Slack integration and CRM sync go on ice. They'll matter later when
acquisition is no longer the bottleneck. Right now they're inventory.

**Step 5: What changes.**

The team's weekly review metric shifts from "features shipped" to "new
trials generated." When trials climb from 200/month to 500/month and the
funnel backs up at activation or revenue, the constraint has moved.

---

## Worked Example: The Constraint Shifts

**ConvoAI — 3 months later. Trials now at 500/month.**

The acquisition work paid off: SEO pages, partnerships, and founder-led
content tripled top-of-funnel. But the weekly review reveals a new problem.

| Metric | Before | Now |
|---|---|---|
| Trials/month | 200 | 500 |
| Activation rate | 60% | 35% |
| Activated → Paid | 35% | 34% |
| Retention | 90% | 88% |

Activation has dropped from 60% to 35%. The new users from SEO and
partnerships are less hand-held than the old ones — they don't get the
"aha moment" without help, and there's no concierge capacity for 500
trials a month.

**The constraint has moved from Acquisition to Activation.**

**Step 1: Name it explicitly.** The founder says in the weekly review:
"Our constraint has moved from acquisition to activation. Starting now,
everything serves activation."

**Step 2: Reassign subordination roles.**

| Role | Was doing (acquisition) | Now doing (activation) |
|---|---|---|
| Founder | Content, outreach, partnerships | Onboarding calls for high-value trials. Pause outreach if queue is full. |
| Engineer A | SEO pages, integrations directory | In-app onboarding wizard, setup health check. |
| Engineer B | Landing page experiments | Fix the 3 drop-off points in trial-to-active flow. |
| CS person | Testimonials, case studies | Protected focus: activate every trial. Track time-to-value. |

**Step 3: Don't abandon acquisition.** The SEO pages and partnerships
that tripled trials don't need daily attention anymore. Put the content
calendar on autopilot (1 post/week, scheduled). Monitor trials weekly —
if they start declining, investigate, but don't redirect capacity back
unless they drop below 400.

**Step 4: Set the new GOLEAN goal.** "Increase activation rate from 35%
(baseline, declining trend) to 50% by end of cycle." Two experiments:
(a) an in-app setup wizard that guides new users to their first meeting
summary in under 3 minutes, (b) a triggered email sequence for users who
sign up but don't import their first meeting within 24 hours.

**Step 5: Update the board.** Buffer column now feeds activation work.
WIP tags shift. The throughput metric changes from "trials generated" to
"users activated."

---

## The Weekly Constraint Review (10 minutes)

See `references/weekly-review.md` — Growth section. Run it now.

---

## Applying This to Tools

This framework is tool-agnostic. When setting up your tool:

- The board should show where work piles up (the constraint is visible).
- Every task should be taggable by which constraint it serves.
- WIP limits should be visible in column/section names.
- Weekly review metrics should be accessible in under 2 minutes.
- A "buffer" stage before the constraint — 2-3 ready items so the
  bottleneck never starves.

These principles apply to Linear, Asana, Notion, Monday, Trello, Jira,
GitHub Projects, a whiteboard with sticky notes.

---

## When to Graduate

You're ready for `stages/scaling.md` when:

- You have 10+ people, or multiple workstreams across teams.
- $1M+ ARR (or equivalent traction for your model).
- The constraint keeps showing up as a **coordination problem** rather
  than a capacity problem — priorities conflict across teams, people
  disagree on the diagnosis, or the triage points to a funnel step but
  fixing it doesn't move throughput.

Until then, stay here. This stage's tools handle most startups through
product-market fit and early scaling.

FILE:stages/pre-revenue.md
# Pre-Revenue: Day 1 Through First Paying Customer

You don't have a customer factory yet. You have a hypothesis. Everything in
this file is about testing that hypothesis before you build the wrong thing.

---

## Know Your Job First

Before anything else: **can you name the specific job your customer hires you
to do, in their words, not yours?**

A job is the progress a person is trying to make in a specific situation. Not
a feature request. Not a demographic. Not a trend. A job has three dimensions:

- **Functional** — the practical task ("get my team ramped on cold calling
  faster without me listening to every call")
- **Emotional** — how they want to feel ("stop feeling like I'm failing the
  people I'm responsible for")
- **Social** — how they want to be perceived ("be seen by leadership as
  data-driven and innovative")

The emotional and social dimensions usually tip the purchase decision. Most
founders only articulate the functional dimension. That's why their messaging
falls flat.

If you can't state the job in one sentence, **that is your constraint.** Stop
building and start observing.

### The forces behind every deal

Four forces govern every purchase:

- **Push**: What's painful about the current situation (creates demand)
- **Pull**: What's attractive about the new solution (creates demand)
- **Anxiety**: Fear about switching — will it work? what's the risk? (kills demand)
- **Habit**: Comfort with the status quo — inertia, sunk costs (kills demand)

**A purchase happens only when Push + Pull > Anxiety + Habit.** If you're
losing deals, don't assume the product is wrong. Check the forces: maybe
the push is weak (not painful enough), anxiety is high (they don't trust you),
or habit is strong (the old way is "good enough").

Sometimes the highest-leverage move is not a better feature but a better
guarantee, a simpler onboarding, or a testimonial from someone like them.

### Struggling moments

The struggling moment — the specific event that triggers someone to think
"I need to do something different" — is the origin of every purchase. Not
general dissatisfaction. A concrete event: the quarterly report reveals a
metric dropped, a key person quits, leadership asks uncomfortable questions.

Identify the 3-5 struggling moments that bring customers to your door. These
are also your Category Entry Points (Sharp) — the situations where your brand
needs to come to mind.

### The 5-minute canvas

After every meaningful customer or prospect conversation, spend 5 minutes:

```
JOB:         [What progress are they trying to make?]
TRIGGER:     [What specific event caused them to look?]
OLD WAY:     [What are they "hiring" today?]
─────────────────────────────────────────────────
PUSH:        [Top struggles with current situation]
PULL:        [What attracted them to us?]
ANXIETY:     [What worries them about switching?]
HABIT:       [What keeps them on the old way?]
─────────────────────────────────────────────────
OUTCOME:     [What does success look like in their words?]
EMOTIONAL:   [How do they want to feel?]
SOCIAL:      [How do they want to be perceived?]
```

After 8-12 canvases, patterns emerge. That's enough signal to act. If the
patterns don't match your assumptions, change your assumptions — not the data.

See `references/jtbd.md` for the full framework: switch interviews, job
mapping, outcome statements, opportunity scoring, and positioning.

---

## The Five Tests

These are your gates. Pass all five before writing code.

### 1. The Not-Not Test

"Is it not okay for your target customer to NOT have this?"

If they can shrug, you don't have authentic demand. You have a nice-to-have.
Nice-to-haves don't survive contact with budgets, procurement, or inertia.

### 2. The Job Test

"Can you name the specific job, in the customer's words?"

Not your words. Not your investor's words. The exact language a customer used
to describe the progress they're trying to make. If you're paraphrasing, you
haven't listened closely enough.

### 3. The Lean Canvas Test

Answer Maurya's riskiest questions:

1. **Problem:** Top 3 problems. How do customers solve them today?
2. **Customer segments:** Who has this most acutely? Name specific people.
3. **Unique value proposition:** One sentence — why different AND worth
   paying attention to? (Not "better" — different.)
4. **Solution:** What is the simplest thing you could build to test whether
   you've got the problem right? Not the product vision — the smallest test.
5. **Channels:** How will these customers find you? Where do they already
   look when this problem hits?
6. **Revenue:** Will they pay? How much? Have you tested price before
   building?
7. **Cost structure:** What does it cost to acquire, activate, and serve one
   customer? Can you survive long enough to learn?
8. **Key metric:** One number that tells you whether this is working.
9. **Unfair advantage:** What can't be easily copied? (Most startups don't
   have one yet. That's fine — but know it.)

The Lean Canvas is not a business plan. It's a set of **hypotheses to test**,
ordered by risk. Test the riskiest assumption first. Usually that's "does
anyone have this problem badly enough to pay?" — not "can we build it?"

### 4. The Napkin Test

Five-minute viability check:

1. Set your 3-year minimum success criteria (revenue goal). Be honest.
2. Calculate annual revenue per customer. Price x frequency. Round clean.
3. Divide. Required customers = Goal / Revenue per customer.
4. Check the market. Does your addressable market have that many? Not the
   TAM fantasy — the realistic number of people who have the job you're
   solving, in the segments you can reach.

If Required Customers > Addressable Market, the model is dead. Don't build
it. Change the price (charge more), the segment (target one that pays more),
or the model (recurring vs. one-time, platform vs. product).

Maurya's key insight: **your pricing model determines your customers and
market viability.** A VR platform needing 10,000 developers in a market of
2,200 is dead on arrival. The same product targeting architects at $50K/year
needs only 200 firms. Same idea, different model, viable business.

This takes 5 minutes and kills more bad ideas than any amount of customer
interviews. Do it first.

### 5. The Mafia Offer

Before building anything, craft an offer so good customers can't refuse:

**Desired outcome + specific metric + timeframe + price + risk reversal.**

Example: "We'll get your new SDRs booking qualified meetings within 2 weeks,
or you pay nothing."

**"Looks cool" is not validation.** When someone says "this looks cool," "I'd
love to try this," or "keep me posted," they are being polite. Social validation
feels like demand but isn't. The only signals that matter:
- They paid money (even a small amount)
- They committed time (scheduled a call, did a trial, signed an LOI)
- They took an action that cost them something

If you have 20 "looks cool" conversations and zero commitments, you don't
have validation. You have politeness.

**The 3x rule:** The offer must promise at least a 3x improvement over the
existing alternative on the dimension the customer cares about most. Not 10%
better — dramatically, obviously better. Anything less won't overcome
switching costs and inertia.

**Template:** "We help [specific customer segment] achieve [desired outcome]
within [timeframe], unlike [existing alternative] which [key limitation].
[Price]. If we don't deliver, [risk reversal]."

Test it by asking for **real commitment** — a deposit, a pre-order, a letter
of intent. Not "would you buy this?" but "here's the invoice." If people
won't commit to the offer, building the product is waste.

The MVP is what you build to deliver on a validated offer, not the other way
around. The offer comes first. The product serves it. Maurya's sequence:
**Desirability → Feasibility → Viability.** Test whether people want this
before testing whether you can build it.

---

## What to Do Instead of Building

Your job at this stage is **observation, not construction.**

- **Watch customers in their real context.** What they do, not what they say.
  Where they struggle. What workarounds they've built. Where they waste time.
- **Run switch interviews.** Talk to people who recently switched solutions
  (or recently quit using one). Reconstruct the buying timeline. Find the
  forces. See `references/jtbd.md` for the full protocol.
- **Mine what you already have.** Lost deal notes, support tickets, and
  churn conversations already contain JTBD data. For lost deals: "What did
  you go with instead and why?" For churned customers: "What are you using
  now?" The answer reveals the real competitive set.
- **Beware the Innovator's Bias.** When you've decided you want to build a
  hammer, everything looks like a nail. Start with existing alternatives
  (what customers use today), not your idea.

People are opaque to themselves. Stated intent is not demand. "Would you
pay for this?" is not data. Observation beats interviews for validating
whether the problem is real.

---

## Solo-Founder Subordination

If you're solo, subordination means **your calendar.**

Block time for the constraint — at this stage, that means customer
conversations, observation, and running the five tests. Everything else
gets the scraps: building, admin, fundraising decks, logo design.

If you're spending more than 30% of your time building before you've
validated the problem, you're subordinating wrong. The code can wait.
The market signal can't.

---

## Worked Example: Killing an Idea on the Napkin

**Mira — solo founder, idea for an AI-powered recipe app for people with
dietary restrictions. Subscription model, $9.99/month.**

Mira is excited. She's been celiac for 10 years and hates existing recipe
apps. She's ready to build.

**Step 1: The napkin test.**

- 3-year revenue goal: $500K ARR (minimum to be worth doing full-time).
- Revenue per customer: $9.99/mo = ~$120/year.
- Required customers: $500K / $120 = ~4,200 paying subscribers.
- Market check: How many people (a) have dietary restrictions, (b) actively
  use recipe apps, (c) are willing to pay monthly, (d) she can reach?

She researches. ~32M Americans have food allergies. But the overlap with
"uses recipe apps" and "will pay $10/mo for one" is much smaller. Comparable
apps (Yummly, Paprika) convert free users to paid at 2-5%. She'd need
84,000-210,000 free users to get 4,200 paid. With no distribution channel
and no marketing budget, that's not realistic in 3 years.

**Step 2: The model is dead. Change the model, not the dream.**

Options:
- **Charge more.** Target professional dietitians who manage multiple
  clients. $49/mo per practice. Now she needs 850 customers from a pool
  of ~100,000 practicing dietitians. Plausible.
- **Change the segment.** Target restaurants that need to comply with
  allergen labeling laws. B2B, $200/mo. Now she needs 210 customers.
  Different product, same domain knowledge.
- **Change the model entirely.** License the dietary restriction engine to
  existing recipe platforms. One API deal at $100K/year means she needs 5
  clients. Different business, much higher bar per deal.

Mira hasn't written a line of code. She's killed the consumer model and
found two viable alternatives in 20 minutes. Now she picks one and runs
the other four tests.

---

## The Pre-Revenue Weekly Review (10 minutes)

You don't have funnel metrics yet. Your review is different:

1. **How many customer conversations this week?** (2 min)
   Target: 3-5 per week minimum. If zero, that's the problem — not the
   product idea.

2. **What did we learn?** (3 min)
   Review any 5-minute canvases from the week. What patterns are emerging?
   Are the struggling moments consistent? Are the forces shifting?

3. **Has our hypothesis survived?** (3 min)
   Do the five tests still pass? Has anything we learned this week
   challenged the not-not test, the job test, or the napkin math?

4. **One action for next week.** (2 min)
   The single most important thing to do. Usually: "talk to 3 more people
   who match pattern X" or "test the offer with segment Y."

---

## When to Graduate

You're ready for `stages/growth.md` when:

- You have paying customers who weren't friends-and-family.
- You can name the job they hired you for, in their words.
- The napkin math works.
- At least one person committed to the Mafia Offer (or equivalent signal
  of real demand).

Until then, stay here. Building before you've graduated is the #1 way
startups waste their runway.

FILE:stages/restart.md
# Restart: Had Customers, Lost Them — Now What?

This stage is for founders who have proven the product works — someone paid,
used it, maybe even loved it — but revenue is now zero or near zero. This is
not pre-revenue. The product exists. The market signal existed. The question
is: what broke?

Don't treat this like a pre-revenue situation. The five tests and the napkin
math are not the priority. The priority is **forensics**.

---

## The critical question first

Before any advice: **Why did the customers leave?**

Not your hypothesis. Their actual words. If you don't know — that is your
constraint. Everything else is guessing.

Ask: "When was the last time you spoke to a customer who left? What did they
tell you?"

If they say "we haven't really talked to them" — that's the first task.
Before outreach, before building, before hiring: talk to churned customers.

Churned customer interviews are the highest-ROI conversations a founder
in restart can have. They already trusted you enough to pay. They've thought
about why it didn't work. They'll tell you, if you ask.

---

## Restart forensics: four questions to answer

Work through these in order. Don't route to a solution until you've answered all four.

### 1. Was it a product failure, a fit failure, or a sales execution failure?

- **Product failure:** Customers tried it, hit a wall, and left because it
  didn't do what they needed.
  - Signals: support tickets, "it doesn't do X," onboarding drop-off, short
    tenure before churn.
  - Diagnosis: the product didn't deliver on the promise.

- **Fit failure:** The product worked, but you sold it to the wrong people.
  They weren't the right segment, didn't have the job badly enough, or the
  timing was wrong for them.
  - Signals: customers who "liked it but couldn't justify the cost," trials
    from large orgs that stalled in procurement, customers who signed up
    for a different use case than you built for.
  - Diagnosis: the product may be fine; the segment or positioning is wrong.

- **Sales execution failure:** The product worked, the segment was right, but
  the deal died in the sales process.
  - Signals: champion loved it but couldn't get sign-off, "not the right time"
    or "budget issues" (polite rejections), no economic buyer involved,
    trial ran but no urgency was created, procurement stalled indefinitely.
  - Diagnosis: the product and fit may be fine; the sales motion is broken.

**"Not the right time" is almost never the real reason.** When you hear
"budget issues," "not a priority right now," or "let's revisit next quarter,"
the stated reason is rarely the real one. Push: "If budget wasn't a constraint,
would you have bought? What would have needed to be true for this to be a
priority?" The real objection is usually: no champion, no urgency, or no
clear ROI story.

Ask: "Of the customers you lost — did they fail *with* the product, did
they quietly stop using it, or did the deal die before they really started?"

### 2. Was there a struggling moment that's still real?

The struggling moment that brought them to you in the first place — does
it still exist? Has the market changed?

If the problem is still painful and real: the opportunity is intact.
You lost customers for reasons you can fix.

If the market shifted (a competitor solved it, the problem went away, a
macro change made it less urgent): you may need to reposition or pivot before
restarting.

Ask: "Are your old customers still struggling with this problem — just without
you?"

### 3. Did you lose them or did they outgrow you?

Some churn is success churn: customers got what they came for and moved on.
This isn't a failure — but it tells you something about the job-to-be-done.

Ask: "What were customers doing *after* they left? Did any of them tell you
they'd solved the problem a different way?"

If they outgrew you: there's a product depth or expansion revenue problem to
solve. If they left for a competitor: run competitive forensics. If they just
quietly stopped: activation or value delivery was the constraint.

### 4. What did you learn about the real customer?

After running trials or early customers, most founders discover the customer
they built for is not quite the customer who got the most value. Early
customers reveal the real ICP — often different from the assumed one.

Ask: "Looking back — who got the most value out of this? Not who you hoped
would, but who actually did?"

That profile is your restart target. Not your original hypothesis. The data.

---

## Restart is not a reset

The temptation at this stage is to treat it like starting over — new
positioning, new segment, new product direction. Resist this unless the
forensics clearly point there. Most restarts fail not because the idea was
wrong but because the founder abandoned the signal before extracting the
lesson.

What you have that pre-revenue founders don't:
- Proof that someone found it valuable enough to pay
- Churned customers who can tell you exactly what broke
- A working product (or close to one)
- Lessons about the real ICP
- Credibility: you shipped something real

Use these. Don't discard them.

---

## The restart sequence

Once you've answered the four forensics questions:

1. **Identify the best-fit customers you had.** Who stayed longest? Who
   got the most value? Who referred someone else, even once?

2. **Run 3-5 churned customer interviews.** Use the JTBD switch interview
   protocol (`references/jtbd.md`). Focus on: what triggered them to try
   you, what job they hired you for, and what caused them to stop.

3. **Write the revised job statement.** One sentence. In their words.
   Not your words.

4. **Identify 10 prospects who look exactly like your best-fit customers.**
   Not a list of 100. Ten. With names.

5. **Reach out with a specific, honest message.** Not a demo request.
   Something like: "We worked with [similar company]. They were trying to
   [specific job]. We helped them [specific outcome]. I think you might
   have the same problem. Do you?"

6. **Get one conversation.** Not a sale. A conversation. Then run the
   intake questions again as if it's a new customer. You're validating
   whether the forensics were right.

---

## What not to do

- **Don't rebuild before you've run the forensics.** The temptation after
  losing customers is to fix the product. Maybe the product is fine. Find
  out first.
- **Don't pitch to the same people who already said no.** Unless you have
  something genuinely different to say. "We've improved" is not enough.
  "We now do X specifically for companies like yours" is.
- **Don't raise to buy time.** Raising on zero revenue to fund a rebuild
  is usually runway consumption, not leverage. Unless you have a clear
  thesis from the forensics that justifies the bet.
- **Don't expand the target.** Founders in restart often think the problem
  was that the ICP was too narrow. Usually it's the opposite — it was too
  broad. Narrow down to the customers who got the most value.

---

## When to graduate to growth.md

You're ready for `stages/growth.md` when:
- You have 1-2 new paying customers who weren't from your original cohort
- You've validated that the job statement from your forensics is real
- The funnel has at least one full cycle you can measure

Until then, stay in restart mode. The job is forensics and one new customer,
not building a growth engine on a hypothesis you haven't re-validated.

FILE:stages/scaling.md
# Scaling: $1M+ ARR or 10+ People

The frameworks still apply. But at this size, the constraint is often not a
funnel step — it's a decision-making pattern, a coordination failure, or
a model that worked at $500K but breaks at $5M.

---

## Policy Constraints

At 10+ people, the bottleneck is often not a resource but a **policy** —
a decision-making pattern that throttles the system:

- A VP who overrides sprint priorities with pet projects.
- A process that requires three approvals before anything ships.
- OKRs that reward local metrics (leads generated, features shipped)
  instead of system throughput (happy paying customers created).
- A "no one ships without full test coverage" rule applied uniformly
  to experiments and production code alike.
- An unwritten rule that only one person can approve customer-facing
  changes.

**How to spot a policy constraint:** The triage points to a funnel step
(say, activation), but fixing that step doesn't move throughput. Or the
constraint keeps shifting back and forth — you fix acquisition, it moves
to activation, you fix activation, it moves back to acquisition. That
oscillation usually means the real constraint is above both: a policy
that prevents the team from sustaining focus.

**How to fix it:** Name the policy. Make it visible. Ask: "If we removed
this policy, what would break?" If the answer is "nothing," remove it.
If the answer is "something important," find the minimum version of the
policy that protects what matters without throttling throughput.

Policy constraints are the hardest to fix because they feel like
"how we do things." They're defended by habit, not logic.

---

## Before You Build: The Awareness Check at Scale

The same check from `stages/growth.md` applies here — but the failure mode
is different. At scale, companies expand into **new segments** where they
have zero mental availability. The product works in segment A, so the team
assumes it will sell in segment B. But segment B has never heard of you,
associates your brand with different (or zero) Category Entry Points, and
can't find you in their usual channels.

**Run this diagnostic before any growth initiative or segment expansion:**

1. "Do the right people in the target segment know we exist?" If not →
   invest in reach and CEP coverage for that segment before building
   segment-specific features.
2. "Can they find and buy us through their usual channels?" If not → fix
   physical availability (directories, marketplaces, integrations, pricing
   transparency) for that segment.
3. "Are we distinctive enough that they'll remember us?" If not → ensure
   brand assets are consistent across new channels.

**At scale, also check:** "Are we associated with the right CEPs for this
new segment?" Re-run the CEP mapping exercise (see `references/pillar-sharp.md`)
for each new segment. The struggling moments that drive your current customers
may not match the new audience. Map before you build.

**Quarterly awareness review (1 hour, strategic):**

1. **Full CEP mapping exercise.** Re-score coverage per segment, add new
   CEPs from JTBD data, retire stale ones.
2. **Full physical availability audit.** Re-score every dimension, especially
   for new segments.
3. **Reach trend.** Plot monthly unique reach across all channels for the
   last 3 months. Flat or declining despite consistent publishing means
   channel saturation or CEP-market mismatch.
4. **Competitive association check.** For your top 3 CEPs per segment,
   search the way a buyer would. Gaps are where you invest.

---

## Multi-Team Constraint Work

With multiple teams, constraint identification becomes two layers:

### Team-level triage

Each team runs their own triage: "What's blocking our throughput?" A
product team might have an engineering constraint. A sales team might
have a pipeline constraint. A CS team might have an onboarding constraint.

### Company-level triage

Roll the team-level answers up: "Which team's constraint is the
system constraint?" The system constraint is the one that limits how
fast the entire company creates happy paying customers.

If the product team's engineering constraint is limiting activation,
and activation is the company constraint, then engineering IS the system
constraint. Every other team subordinates to it.

If the sales team's pipeline constraint is limiting acquisition, but
the company constraint is actually retention (customers are churning
faster than you acquire them), then sales is a non-constraint. Their
pipeline problem doesn't limit system throughput. Fix retention first.

### The weekly review becomes two layers

1. **Team-level** (each team, 10 min): What's blocking our throughput?
   Are we feeding the company constraint? Where is our work piling up?
2. **Company-level** (leadership, 25 min): Which team is at the system
   constraint? Are all other teams subordinating? Has the company
   constraint shifted?

Use the Full Review format for the company-level review. See the
"Full Weekly Review" section below.

---

## Hiring as Elevation

"Elevate" means invest. At this stage, that usually means hire. The
rules:

### When to hire

Only after exploiting and subordinating. If you haven't squeezed maximum
output from the constraint with existing resources, and you haven't
redirected non-constraint capacity to help, hiring is premature. You'll
add headcount to a broken system.

### Where to hire

**At the constraint. Never at a non-constraint.** A senior hire at the
bottleneck pays for themselves in throughput. A hire at a non-constraint
adds cost without adding output.

If the company constraint is activation and your onboarding team is at
capacity after exploiting and subordinating, hire an onboarding specialist.
Don't hire another engineer because "engineering is always useful."

### Sequencing

The constraint will shift after the new hire is productive. Plan for it:

1. Before hiring, ask: "When this hire breaks the current constraint,
   where will the constraint move next?"
2. Start subordination planning for the new constraint before the hire
   starts.
3. Don't hire for two constraints simultaneously. Break one at a time.
   Parallel hiring at different constraints means neither gets enough
   support during onboarding.

### The role description test

Every job description should name the constraint it serves: "This role
exists to increase [throughput metric] by [doing what] at the [specific
constraint]." If you can't write that sentence, you don't know why
you're hiring.

---

## Multi-Quarter Strategic Initiatives

The 2-week GOLEAN cycle is the tactical layer. Some constraint work
takes months: moving upmarket, rebuilding onboarding for enterprise,
launching in a new geography.

### How to run them

1. **Set a GOLEAN goal for each cycle** that serves the larger initiative.
   "This cycle: reduce enterprise onboarding from 6 weeks to 4 weeks by
   automating data import." Not "work on enterprise onboarding."

2. **Track with the fever chart at the project level.** Break the
   initiative into milestones. For each: % of work done vs. % of buffer
   consumed. See the Buffer Management section below.

3. **The weekly review asks two questions about the initiative:**
   "What % of the initiative is done? What % of our buffer is consumed?"
   If buffer is outpacing completion, act — cut scope, add resources from
   non-constraints, remove blockers.

4. **Don't let the initiative become a WIP black hole.** If the
   initiative has been "in progress" for 3 months with no measurable
   throughput improvement, it's inventory. Either break it into smaller
   shipped increments or kill it.

### The strategic constraint test

Before committing to a multi-quarter initiative, ask: "Is this work on
the current constraint, or are we investing in a future constraint?" Both
are valid, but they have different urgency. Current-constraint work gets
priority. Future-constraint work gets a smaller allocation and a longer
buffer.

---

## Business Model Constraints

Sometimes the constraint isn't a funnel step — it's the model.

**Re-run the napkin test annually.** The math that worked at $500K ARR
may not work at $5M:

- The addressable market at your current price point may be saturating.
- Customer acquisition costs may be rising faster than lifetime value.
- Your best segment may be fully penetrated while adjacent segments
  don't convert as well.

If Required Customers > Addressable Market at your current pricing, the
fix is the model, not the funnel. Options:

- **Move upmarket.** Charge more per customer. Fewer customers needed,
  but longer sales cycles, more onboarding complexity.
- **Expand the product.** Serve adjacent jobs for existing customers
  (expansion revenue). The most capital-efficient growth at this stage.
- **Change the pricing model.** Usage-based, seat-based, outcome-based.
  Different models attract different segments.

This is a strategic decision, not a tactical one. Don't try to solve it
in a GOLEAN cycle. Use the napkin test to diagnose, then plan the model
change as a multi-quarter initiative.

---

## Buffer Management and Estimation at Scale

At this size, you have external commitments (customer launch dates, board
reporting, partner timelines) that demand honest estimation.

### Critical Chain Project Management (CCPM)

The full method, for initiatives with external commitments:

1. **Get focused estimates** (50% confidence) for each task. "How long
   with no interruptions?"
2. **Use focused estimates as task durations.** Do NOT add safety to tasks.
3. **Identify the critical chain** — the longest dependent sequence,
   including resource dependencies (same person can't do two tasks at once).
4. **Buffer = critical chain × 0.4.** Place at the end of the project.
   A 30-day chain gets a 12-day buffer. Commit date = day 42.
5. **Schedule tasks as late as possible.** Reduces WIP, prevents premature
   work.
6. **Run the relay race.** When a task finishes, the next person starts
   immediately — not on the scheduled date. Early finishes propagate.

The 0.4 multiplier works for almost everything. It's the default. For
initiatives where you need statistical backing (regulated work, board-level
commitments), also get safe estimates (80-90% confidence) for each task —
this enables RSEM. See `references/estimation.md` for RSEM, calibration
exercises, and other buffer sizing methods.

### The fever chart

Track weekly: % of critical chain completed vs. % of project buffer
consumed.

- **Green (buffer < 1/3 consumed):** On track. Don't fill slack with
  scope creep.
- **Yellow (buffer 1/3 to 2/3 consumed):** Plan a recovery option. Being
  in yellow is normal — the buffer is doing its job.
- **Red (buffer > 2/3 consumed):** Act now. Cut scope to minimum viable
  delivery. Redirect non-constraint capacity to help. Remove blockers.
  Communicate risk to stakeholders with a revised range.

### Communicating timelines

**To customers and stakeholders:** Never give a point estimate. "We expect
to deliver between [aggressive date] and [buffer end date]." If using
cycle time data: "50% chance by [date A], 85% chance by [date B]."

**To the board:** Use throughput metrics. "We shipped X initiatives serving
the constraint. Cycle time for customer-facing work is Y days. We're in
green/yellow/red on the current initiative."

**To the team:** Buffer status and constraint, not individual task
deadlines. "We've consumed 40% of buffer with 60% of work done — we're
healthy. Keep the relay race going."

### Cycle time measurement

After 3+ weeks of data, stop estimating and start measuring. Track how
long tasks take from start to done:

- **Median:** 50% of tasks complete in this time or less.
- **85th percentile:** Use this for external commitments.

This replaces estimation with measurement. It's the most accurate method
for ongoing work.

See `references/estimation.md` for PERT, Monte Carlo forecasting, the
cone of uncertainty, and why estimates structurally fail.

---

## When the Constraint Shifts

This is the hardest moment operationally. At scale, the stakes are
higher — the team has built process, muscle memory, and identity around
the old constraint.

1. **Name it explicitly.** "Our constraint has moved from X to Y.
   Starting now, everything serves Y."

2. **Reassign subordination roles.** At 10+ people, this means updating
   team-level priorities, not just individual roles. The principle:
   every team that is NOT at the constraint serves the team that IS.
   Non-constraint teams feed the buffer, remove blockers, and absorb
   overflow — even if that means they look underutilized.

3. **Don't abandon the old constraint.** The systems that fixed it
   (content calendar, outreach cadence, onboarding automation) go on
   autopilot. Monitor weekly. Don't let it regress.

4. **Expect resistance.** At scale, resistance is louder. Teams built
   KPIs around the old constraint. Dashboards measure the old thing.
   Headcount was justified by the old diagnosis. The founder needs to
   re-align the narrative, not just the board.

5. **Update everything in the same meeting.** Buffer columns, WIP tags,
   constraint labels, team assignments, GOLEAN goals. Don't let tools
   lag behind decisions.

6. **Watch for the oscillation pattern.** If the constraint keeps
   bouncing between two steps (acquisition → activation → acquisition),
   look for a policy constraint sitting above both. The oscillation
   usually means neither step is the real constraint.

---

## Worked Example: The Hidden Policy Constraint

**DataPipe — data integration SaaS, 15 people, $2.1M ARR, stuck for
6 months.**

The founder asks: "We're stuck at $2.1M. Activation is the problem —
enterprise customers take 6 weeks to onboard. We need to hire 2 more
onboarding specialists."

**Step 1: Triage.**

| Question | Answer |
|---|---|
| Enough people finding you? | Yes — 80 enterprise trials/month from partnerships and content. |
| Do signups reach the aha moment? | Slowly. Median time-to-value is 6 weeks. Only 40% activate within 90 days. |
| Do activated users pay? | Yes — 70% convert, $2K/mo average. |
| Do paying customers stay? | Yes — 92% annual retention. |
| Is the team finishing things? | No. 4 engineers split across 6 projects. Onboarding backlog growing. |

**Step 2: Dig deeper.** The triage says activation. But why is onboarding
taking 6 weeks?

Interview the onboarding team: "What blocks you?" Three answers:
1. Custom data connectors — each enterprise needs 2-3 connectors that
   don't exist yet. Engineering builds them ad-hoc.
2. Security reviews — each enterprise requires a security questionnaire.
   Only the CTO can complete them, and he's also the lead architect.
3. The VP of Product keeps pulling engineers off connector work to build
   "strategic features" for the roadmap.

**Step 3: Identify the real constraint.** The activation problem is real,
but it's caused by a **policy constraint**: the VP of Product controls
the engineering sprint and prioritizes features over onboarding
infrastructure. The CTO being the only person who can do security reviews
is a secondary constraint — a bus factor of 1 is a throughput ceiling.
Document it, pair on it, or automate it.

**Step 4: Exploit the policy constraint.**

- The founder takes sprint prioritization away from the VP of Product
  for this quarter. All engineering serves activation until onboarding
  time drops below 3 weeks.
- Two engineers move full-time to building a self-serve connector
  framework (so enterprise customers can configure their own, instead
  of waiting for custom builds).
- The CTO documents the security review process and trains the CS lead
  to handle standard questionnaires. CTO only handles non-standard ones.

**Step 5: Subordinate.**

- The VP of Product's roadmap features go on ice. They're inventory.
- The two engineers still on other projects consolidate to one project
  each (WIP discipline).
- The CS team pre-packages onboarding materials for the top 10 most
  common data sources.

**Step 6: Don't hire yet.** The founder wanted 2 onboarding hires.
Answer: "First, exploit. If the connector framework and security review
delegation cut onboarding to 3 weeks and the activation rate climbs
above 60%, you may not need the hires. If it doesn't, then hire — at
the constraint (onboarding), not at engineering."

**What happened:** After one quarter, median onboarding dropped from
6 weeks to 2.5 weeks. Activation rate went from 40% to 65%. The
constraint shifted to acquisition — now that onboarding was fast,
they could handle more enterprise trials than they were generating.
The VP of Product's roadmap features were revisited then, and half
were cut because JTBD data showed customers didn't need them.

---

## The Full Weekly Review (25 minutes)

See `references/weekly-review.md` — Scaling section. Run it now.