--- 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 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
~10,000/mo"] -->|"Acquisition · 3%"| IP["Interested Prospects
~300/mo"] IP -->|"Activation · 40%"| AU["Active Users
~120/mo"] AU -->|"Revenue · 25%"| PC["Paying Customers
~30/mo"] PC -->|"Retention · 85%"| RC["Retained Customers
~25/mo"] 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 [output.svg] [--theme ] [--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.

Factory Floor

Comments (0)