--- title: Input-Constrained vs Output-Constrained synced_from_vault: true vault_source: 03-living-docs/patterns/Input-Constrained-vs-Output-Constrained.md public: true type: pattern tags: - pattern - ai-strategy - systems-thinking - business-models created: 2026-03-09T00:00:00.000Z --- ## Core Concept Every process is bottlenecked by either **inputs** (volume of work arriving) or **outputs** (quality of work produced). AI has radically different effects on each: - **Input-constrained:** The limiting factor is throughput — how much you can process. AI is a direct labor multiplier. Automate aggressively. - **Output-constrained:** The limiting factor is judgment, taste, or creativity. AI augments but cannot replace the human. Design for augmentation. Misidentifying which type a process is leads to either leaving money on the table (treating input-constrained work as sacred) or destroying value (automating output-constrained work and losing the judgment layer). ## The Pattern | Dimension | Input-Constrained | Output-Constrained | |-----------|-------------------|-------------------| | **Bottleneck** | Volume / capacity | Quality / judgment | | **AI role** | Replace labor | Augment human | | **Value equation** | More throughput, fewer people | Better outcomes, same people | | **Examples** | Support tickets, bug triage, CI/CD, data entry, test generation, invoice processing | Product strategy, architecture, creative direction, leadership, hiring decisions | | **Pricing risk** | Per-seat collapses (headcount → AI) | Per-seat survives (human judgment retains value) | | **Danger of misidentification** | Overstaffing what AI can handle | Automating away the judgment that creates value | ## The Nuance: Most Work Is Both The interesting cases aren't purely one or the other. Software engineering is the canonical mixed example: - **Input-constrained parts:** Writing boilerplate, fixing known bug patterns, migrating APIs, writing tests from specs, code review for style/lint issues - **Output-constrained parts:** System design, understanding user needs, tradeoff decisions, debugging novel issues, architecture The ratio is shifting as AI improves — more of engineering moves from output-constrained to input-constrained over time. This is why "AI will replace developers" is both true and false: it depends on which *part* of the job you mean. **The strategic implication:** The highest-leverage position is being excellent at the output-constrained parts while using AI to obliterate the input-constrained parts. This is the augmentation thesis in one sentence. ## Where I've Seen It - **Mike Cannon-Brookes (Atlassian CEO, a16z podcast, Mar 2026):** Origin of the framing. Used to explain which SaaS companies face existential AI risk. See [Atlassian-CEO-SaaS-Apocalypse](/patterns/atlassian-ceo-saas-apocalypse). - **A peer engineering leader:** Their engineering is increasingly input-constrained (AI handles it), but product/design decisions are output-constrained — hence [Bottleneck-Shifts-Upstream](/patterns/bottleneck-shifts-upstream). - **Show Notes:** Podcast ingestion is input-constrained (process all episodes). Insight extraction is output-constrained (which insights matter to this listener?). The product value lives in the output-constrained layer. - **This OS:** Session rituals are input-constrained (reading files, checking calendars, processing inbox). Strategic thinking is output-constrained (what should I focus on?). The system design pushes input-constrained work to Claude and reserves my attention for output-constrained decisions. ## Implications ### For AI adoption strategy 1. **Audit first:** Classify your team's work into input-constrained and output-constrained buckets 2. **Automate input-constrained aggressively:** These are quick wins with clear ROI 3. **Design augmentation for output-constrained:** Don't try to automate judgment — build tools that make judgment faster and better-informed 4. **Watch the ratio shift:** As AI improves, work migrates from output-constrained to input-constrained. Re-audit periodically. ### For business models Per-seat SaaS pricing is a bet that human headcount correlates with value delivered. For input-constrained work, that correlation breaks when AI enters. For output-constrained work, it holds. Price accordingly. ### For career strategy Develop expertise in output-constrained domains. Input-constrained skills depreciate as AI improves. The VPE role is almost entirely output-constrained — judgment, people, strategy, communication. This is why it's durable. ## Related Patterns - [Augmentation-Over-Automation](/patterns/augmentation-over-automation) — the design philosophy that follows from this distinction - [Bottleneck-Shifts-Upstream](/patterns/bottleneck-shifts-upstream) — what happens when you automate input-constrained work: the output-constrained bottleneck becomes visible - An-Elegant-Puzzle#Annotated Input-Constrained vs Output-Constrained Flows — the Larson stock-and-flow diagram annotated with this pattern. Happy path = input-constrained, failure loop = output-constrained. Testing infrastructure is the gate between them. - [Effectiveness-Over-Efficiency](/patterns/effectiveness-over-efficiency) — output-constrained work is about effectiveness (right problem); input-constrained is about efficiency (fast processing) - [Amdahls-Law](/patterns/amdahls-law) — the sequential output-constrained bottleneck limits how much speedup you get from parallelizing input-constrained work - [Right-Problem-Leverage](/patterns/right-problem-leverage) — in output-constrained domains, 100x comes from problem selection - [Doorman-Fallacy](/patterns/doorman-fallacy) — mistaking the input-constrained layer (visible work) for the source of value (output-constrained judgment) --- ## Cross-References - [Atlassian-CEO-SaaS-Apocalypse](/patterns/atlassian-ceo-saas-apocalypse) — origin (Cannon-Brookes podcast)