Amazon Leadership Principles — Product & Engineering

Apply these principles at every decision point. Not all apply to every situation — use judgment.

Pre-Build: Is This Worth Building?

Customer Obsession

• Who is the customer? Name them specifically.
• What is their pain? Quote real complaints, not assumptions.
• Work backwards: write the press release and FAQ BEFORE writing code.
• If you can't articulate why the customer cares in one sentence, stop.

Ownership

• Think long-term. Will this matter in 6 months?
• Don't build something just because it's interesting. Build what's needed.
• You own the outcome, not just the code. If it ships broken, that's on you.

Invent and Simplify

• What's the simplest version that solves the problem?
• Can you solve this with existing tools before building new ones?
• Complexity is a cost. Every abstraction must earn its place.

Are Right, A Lot

• What data supports this direction?
• What's the strongest argument AGAINST building this?
• Seek to disconfirm your hypothesis, not confirm it.

During Build: Execution Standards

Bias for Action

• Ship the smallest useful version first. Perfect is the enemy of shipped.
• Reversible decisions (two-way doors) → decide fast, move on.
• Irreversible decisions (one-way doors) → slow down, get data.

Dive Deep

• Don't hand-wave. Know the numbers: latency, error rates, user counts.
• When something looks wrong, investigate. Don't assume it's fine.
• "It works on my machine" is not a valid test.

Insist on the Highest Standards

• Code must have error handling, not just the happy path.
• Every feature needs: tests, documentation, monitoring.
• Ask: "Would I be comfortable if this was the only thing a customer saw?"

Frugality

• Do more with less. Fewer dependencies, smaller bundles, lower costs.
• Don't gold-plate. Ship the 80% solution, iterate on the 20%.
• Constraints breed resourcefulness. Treat them as features.

Think Big

• Is this a band-aid or a real solution?
• Will this approach scale to 10x the current load?
• What would the ambitious version look like? (Then ship the pragmatic one.)

Code & Architecture Review Checklist

Apply when reviewing code, PRs, or architecture decisions:

1. Customer Impact — Does this change make the customer's life better? How?
2. Simplicity — Is this the simplest solution? Can anything be removed?
3. Ownership — Does the author own the full lifecycle? Tests? Error handling? Monitoring?
4. Dive Deep — Are edge cases handled? What happens when it fails?
5. Highest Standards — Would you ship this to your most important customer today?
6. Bias for Action — Is this blocked by a perfect-is-the-enemy-of-good decision? Ship it.
7. Earn Trust — Is the code honest about its limitations? Are errors surfaced, not swallowed?

PRFAQ Template (Working Backwards)

Before building any significant feature or product, write this first:

PRESS RELEASE (1 paragraph)
- What is it? (one sentence)
- Who is it for?
- What problem does it solve?
- How does the customer benefit?
- Quote from a (hypothetical) customer

FAQ — Customer Questions
1. How does it work?
2. How much does it cost?
3. What if [common objection]?
4. How is this different from [competitor/alternative]?

FAQ — Internal/Technical Questions  
1. How will we measure success?
2. What are the biggest risks?
3. What's the simplest MVP?
4. What does v2 look like?

Anti-Patterns to Call Out

• Building without a customer — "We should build X because it's cool" → Who asked for it?
• Over-engineering — 3 layers of abstraction for a 50-line script → Simplify.
• Ignoring failure modes — "It'll probably work" → What happens when it doesn't?
• Scope creep — "While we're at it, let's also..." → Ship what you started first.
• Vanity metrics — "We have 1000 users!" → How many are active? How many pay?
• Premature scaling — Building for 1M users when you have 10 → Earn the complexity.

When to Apply Each Principle