# Jeff Bezos - Operations Flywheel

> Jeff Bezos's operational excellence framework: flywheel effect design, input vs output metrics, high-velocity decision making, disagree and commit, and two-pizza team structure — from Amazon shareholder letters and internal operating principles

- Skill: `openlabor/jeff-bezos-operations-flywheel` (Agent Skill)
- Install (CLI): `npx skillmds@latest add openlabor/jeff-bezos-operations-flywheel`
- Raw SKILL.md: https://api.skillmd.com/api/skills/openlabor/jeff-bezos-operations-flywheel/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: OpenLabor (https://skillmd.com/u/openlabor)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/openlabor/jeff-bezos-operations-flywheel

---


# Jeff Bezos - Operations Flywheel

Use these frameworks when designing operations, setting up metrics, organizing teams, or improving decision-making velocity. Apply the flywheel model to map self-reinforcing business loops. Replace output metrics with input metrics. Structure teams for speed and autonomy.

**Routes when user asks about:** flywheel effect, business model loops, input metrics, output metrics, high-velocity decisions, disagree and commit, two-pizza teams, operational excellence, Amazon operations, how to build self-reinforcing growth, measurement systems

---

## How to Use This Skill

When organizing workflows, designing processes, setting up metrics, or restructuring teams, apply the relevant framework below. The flywheel is the strategic design tool; input metrics are the measurement system; decision velocity and team structure are the execution layer.

---

## Designing Flywheels

Every business should map its virtuous cycle. Reference the Amazon flywheel (Bezos's napkin sketch, 2001):

```
Lower Prices → More Customers → More Volume → More Sellers Attracted
→ Wider Selection → Better Customer Experience → Lower Prices (loop)

AND simultaneously:
More Volume → Lower Cost Structure → Lower Prices
```

Every element reinforces every other element. Push on any part and the whole thing accelerates.

### Flywheel Design Process

**Step 1 — Identify core customer value**: What single thing does the customer value most?

**Step 2 — Map what creates that value**: What inputs produce that customer value? (Lower cost structure → lower prices)

**Step 3 — What does customer satisfaction produce?**: More customers → more volume → more leverage → lower costs? Network effects? More data?

**Step 4 — What does more volume produce?**: Lower unit costs? Attract suppliers/partners? Data advantage?

**Step 5 — Connect the loop**: Draw the full virtuous cycle. Verify each element genuinely feeds the next.

**Step 6 — Identify the bottleneck**: Where is the flywheel weakest? What constraint, if removed, would accelerate the whole loop?

### Flywheel Quality Checklist
- [ ] Each element in the loop causes the next — test causality, not just correlation
- [ ] The loop returns to the starting point (actually circular)
- [ ] Adding more to any element accelerates the entire loop
- [ ] The flywheel creates a self-reinforcing moat over time
- [ ] Competitors cannot easily enter the loop at any point

---

## Input Metrics vs. Output Metrics

Most companies measure outputs. Bezos insisted on measuring inputs — this is the single most important operational insight.

### The Distinction

**Output metrics** (results): Revenue, profit, customer satisfaction, NPS, churn rate
- Problems: lagging indicators (learn about problems too late), can be gamed, don't tell you what to fix

**Input metrics** (drivers): First-contact resolution rate, in-stock rate, delivery speed, selection breadth
- Advantages: leading indicators, tell you exactly what to change, harder to game

"We need to be able to know whether we are delivering a great customer experience, and we need to be able to measure that directly — not through proxies." — Bezos

### Input → Output Mapping Template

| Output Metric | Driving Input Metrics |
|--------------|----------------------|
| Revenue | Leads → conversion rate → avg. order value |
| Customer satisfaction | First-contact resolution rate, delivery time, defect rate |
| Retention/NPS | Onboarding completion, feature adoption, support ticket rate |
| Profit margin | Unit economics, operational efficiency, supplier terms |

### Amazon's Input Metric Examples
- In-stock rate (% of items available)
- Detail page view weight (% of views that convert)
- Perfect order percentage (orders with no problems)
- Contact rate (customer contacts per unit shipped — rising = problems, falling = improving)
- Glance views (how often items are seen)

### Building Your Input Metric System
1. List top 5 output metrics
2. For each output: what is the single most important input that drives it?
3. Is this input measurable weekly or daily (not monthly/quarterly)?
4. Build dashboards around inputs, not outputs
5. Review input trends in every operational meeting

---

## High-Velocity Decision Making

"Speed matters in business. Many decisions and actions are reversible and don't need extensive study." — Bezos

### Why Companies Slow Down
They apply the same process to all decisions. Type 1 (irreversible, high stakes) process applied to Type 2 (reversible, low stakes) decisions kills velocity.

### The 70% Rule
"Most decisions should probably be made with somewhere around 70% of the information you wish you had. If you wait for 90%, in most cases, you're probably being slow."

Going from 70% to 90% certainty takes 3x longer but only improves quality by ~20%. For reversible decisions, this is a bad trade.

**Apply the 70% rule to**: product features, marketing decisions, operational changes, hiring for most roles, pricing tests, partnership pilots.

**Do NOT apply to**: major acquisitions, irreversible architecture, legal/regulatory commitments, large capital commitments.

### Decision Velocity Checklist
Before any decision:
1. **Is this reversible?** If yes → decide now with 70% information
2. **Who is the right decision-maker?** Person closest to the problem — not necessarily most senior
3. **Do we have 70%?** If yes → decide
4. **Cost of 30-day delay?** If high → decide now
5. **Failure modes if wrong?** If recoverable → decide now

---

## Disagree and Commit

"If you have conviction on a particular direction even though there's no consensus, it's helpful to say, 'Look, I know we disagree on this but will you gamble with me on it?'" — Bezos

### The Problem This Solves
Consensus cultures: slow to the pace of the most reluctant person, produce watered-down decisions, create passive resistance, mistake silence for agreement.

### The Protocol
1. **Voice disagreement clearly**: "I disagree because [specific reason]. I think we should [alternative] because [reasoning]."
2. **Get genuinely heard**: Decision-maker must engage with the objection, not dismiss it.
3. **Decision-maker decides**: Once the argument is heard, make the call.
4. **Commit fully**: "I disagree, but I'm committed to making this succeed. Here's how I'll support it."

**What it is NOT**: doing the minimum, bringing up objections later, letting it fail to say "I told you so."

### When to Use
- Technical architecture disagreements where one approach must be chosen
- Product prioritization when two valid paths exist
- Any decision where continued debate costs more than the risk of being wrong

---

## Two-Pizza Teams

"If you need more than two pizzas to feed a team, it's too large." — Bezos

### Design Rules

**Team size**: 5-8 people maximum.

**Structure**: One owner with clear accountability. All necessary skills represented. Dedicated resources — not borrowed.

**Scope**: Team owns a coherent domain end-to-end. Clear APIs to other teams. Success metrics the team controls.

**Autonomy**: Team makes its own operational decisions. Escalation for conflicts between teams, not within.

### Team Size Diagnostic

| Symptom | Likely Cause | Fix |
|---------|-------------|-----|
| Meetings > 8 people regularly | Team too large | Split the team |
| Nobody knows who owns a decision | Unclear scope | Redefine charter |
| Can't ship without waiting for another team | Dependency problem | Bring skill in-house or restructure |
| Individual contribution invisible | Team too large | Split or restructure |

---

## Operational Excellence Audit

Run quarterly to assess operational health.

### Flywheel Health
- [ ] Can you draw your flywheel in 5 minutes?
- [ ] Are all loop elements measurable?
- [ ] Is the flywheel accelerating quarter-over-quarter?
- [ ] Is the bottleneck identified and being addressed?

### Metrics Quality
- [ ] Do you have daily/weekly input metrics for top 5 outputs?
- [ ] Are input metrics reviewed in operational meetings?
- [ ] Is there a clear owner for each input metric?
- [ ] Has any metric been gamed recently? (metric improving while experience degrades)

### Decision Velocity
- [ ] Average time from "idea raised" to "decision made" for Type 2 decisions?
- [ ] What % of decisions made at the right level (not escalated unnecessarily)?
- [ ] How many decisions delayed for consensus when they only needed alignment?

### Team Structure
- [ ] Are all teams genuinely two-pizza sized?
- [ ] Does each team have a clear owner and charter?
- [ ] Can teams ship independently?

---

## Sources
- Amazon Shareholder Letters 1997-2020
- *Working Backwards* — Colin Bryar & Bill Carr
- *Good to Great* — Jim Collins (flywheel concept origin)
- Amazon Leadership Principles (amazon.jobs)
- Bezos interview at re:Invent 2021
- *The Everything Store* — Brad Stone