Set WIP limits per pipeline stage (solo: Draft=3, Review=2, Polish=2) — don't start new items until existing ones advance

Why This Is a Rule

Work-in-progress limits are the most counterintuitive productivity intervention: doing less at once produces more total output. This is because attention is a fixed resource. Ten items in Draft stage means each item gets 10% of your attention per session. Three items in Draft means each gets 33%. The items with 33% attention move faster through the pipeline and deliver value sooner. The items with 10% attention linger indefinitely in half-finished states, consuming mental tracking overhead without producing any output.

The Kanban system from Toyota production formalizes this: each stage has a maximum WIP count, and the system refuses to accept new items when the limit is reached. For a solo knowledge worker, the limits are small: Draft: 3 (you can maintain mental models of 3 works-in-progress), Review: 2 (review requires focused comparison that doesn't scale beyond 2 items per session), Polish: 2 (polishing requires fresh eyes and benefits from a small focused set). When Draft is at 3, no new drafts are started until at least one advances to Review.

The limits feel restrictive ("But I have 7 ideas I want to draft!") but they produce faster delivery by forcing completion. Ideas waiting to enter the pipeline go on a backlog, not into active WIP. This is When the bottleneck is waiting, not processing — reduce work-in-progress first, because cycle time = WIP / throughput's Little's Law applied structurally: reducing WIP directly reduces cycle time.

When This Fires

• When setting up a personal production pipeline (Move outputs forward through pipeline stages (Draft → Review → Polish → Deliver) — no skipping, no backward oscillation without explicit regression decisions)
• When pipeline stages accumulate items that never advance
• When you have 10+ items "in progress" but none near completion
• Complements Work the most downstream pipeline stage first — Deliver before Polish, Polish before Review, Review before Draft — pull from bottlenecks, don't push WIP (downstream-first) and When the bottleneck is waiting, not processing — reduce work-in-progress first, because cycle time = WIP / throughput (Little's Law) with the structural mechanism that limits accumulation

Common Failure Mode

Unlimited WIP: starting every new idea as a draft, accumulating 15 half-finished items that each receive occasional attention but none receive enough to complete. The pipeline is full but nothing flows through it. The feeling is "I'm working on so many things!" while the reality is "Nothing is getting done."

The Protocol

(1) Set WIP limits for each pipeline stage. Starting points for solo work: Draft=3, Review=2, Polish=2. (2) Track items per stage on a visible board (physical kanban, Trello, or a simple list). (3) When a stage is at its limit, do not add new items. Instead, advance existing items downstream (Work the most downstream pipeline stage first — Deliver before Polish, Polish before Review, Review before Draft — pull from bottlenecks, don't push WIP). (4) New ideas go on a backlog, not into active WIP. The backlog is unlimited; active stages are not. (5) Adjust limits based on experience: if items in a stage consistently wait because you can't process them fast enough, reduce the limit. If a stage is always empty, you might increase the upstream limit slightly. The goal is steady flow, not maximum utilization.