★★★★★ 4.7/5 — The clearest inside account of how Amazon actually operates, and the most reusable playbook for any team that wants fewer wasted meetings and sharper execution.
Best for: Product managers, founders, and team leads who want a concrete system for turning ideas into shipped work.
Reading time: ~7 hrs to read the book, ~25 min to read this summary
Difficulty to apply: Moderate — each mechanism is simple on its own, but changing a team’s habits takes real practice.
Working Backwards in one minute
Amazon doesn’t run on inspiration or hustle — it runs on a small set of internal systems that force clarity before anyone commits real time to building anything. Colin Bryar and Bill Carr, two Amazon veterans with a combined 27 years inside the company, pull back the curtain on the actual operating mechanisms behind Amazon’s reputation for shipping fast without shipping sloppy: writing the press release before writing any code, replacing PowerPoint with six-page narrative memos, giving an independent “bar raiser” veto power over every hire, keeping teams small enough to feed with two pizzas, and assigning one single-threaded leader to every initiative that matters. None of these mechanisms are secret or proprietary — they’re just rarely written down in this much operational detail, which is exactly what makes this book different from the usual leadership-principles poster on a wall.
Key takeaways
- Start from the press release, not the product. Every new initiative begins with a draft announcement written as if it already shipped.
- Six-page memos beat twenty-slide decks. Full sentences expose weak logic that bullet points can hide.
- Meetings open in silence, not with a pitch. Everyone reads the memo together before anyone talks.
- A bar raiser can veto any hire. An interviewer with no stake in filling the seat protects the long-term hiring bar.
- Teams stay small enough to share two pizzas. Roughly ten people or fewer, with full ownership of their own roadmap.
- Every big bet gets one single-threaded leader. One owner, one mission, no split attention across competing priorities.
- Track input metrics, not just outputs. The controllable process measures predict the results before the results arrive.
- Disagree openly, then commit fully. Voice real objections in the room — but back the decision completely once it’s made.
- The system scales even when any one person doesn’t. These mechanisms outlive individual managers and reduce reliance on heroics.
- None of this requires Amazon’s size. A team of five can write a press release; a team of five hundred still needs one.
What is Working Backwards about?
Working Backwards is an insider account by two former Amazon vice presidents of the internal operating mechanisms — working backwards from the customer, narrative memos, bar raiser hiring, two-pizza teams, and single-threaded leadership — that let Amazon consistently invent and ship at scale, adaptable by any team willing to adopt the discipline.
About the authors
Colin Bryar and Bill Carr spent a combined 27 years at Amazon and watched its internal operating systems take shape from the inside. Bryar spent two years as one of Jeff Bezos’s technical advisors before leading several of Amazon’s product and technology organizations. Carr joined in 1999 and spent more than fifteen years building the company’s digital media businesses, including Kindle, Amazon Music, and Amazon Video, as a vice president reporting directly to Bezos. After leaving, both became independent consultants helping other companies install the same mechanisms — and in Working Backwards, they translate what was previously tribal knowledge into a practical manual any team can adopt.
Key concepts at a glance
| Concept | What it means | Use it when |
|---|---|---|
| Working Backwards (PR/FAQ) | Draft the press release and FAQ before building anything | Kicking off any new product or feature |
| Narrative memo | A six-page written document, read in silence at the start of a meeting | Planning reviews and strategy proposals |
| Bar raiser | A trained interviewer, independent of the hiring team, with veto power | Every structured hiring loop |
| Two-pizza team | A team small enough to be fed by two pizzas, roughly ten people | Structuring product and engineering orgs |
| Single-threaded leader | One leader who owns one mission with no competing priorities | High-priority initiatives that keep stalling |
| Input metrics | Controllable process measures that predict outputs before they arrive | Building a weekly operating dashboard |
| Disagree and commit | Voice objections fully, then commit completely once a decision is made | Breaking decision-making gridlock |
| Bar-raising culture | Every new hire should raise, not just meet, the team’s average | Scaling a team fast without diluting quality |
Part 1: Working Backwards — Write the Press Release Before You Build
The mechanism that gives the book its title is also its most counterintuitive: before an Amazon team writes a line of code, they write the press release for the finished product. Not a brief, not a pitch deck — an actual press release, written in plain customer language, dated as if the product has already launched. Alongside it comes a Frequently Asked Questions document that answers the hardest external questions a skeptical customer might ask, and the hardest internal questions a skeptical executive might ask about cost, risk, and dependencies.
The logic is simple but rarely followed: it is far cheaper to discover a mediocre idea on paper than after months of engineering. If the press release reads as forgettable, generic, or unconvincing, the team has learned that in an afternoon instead of a quarter. Bryar and Carr describe teams revising a single press release dozens of times before it earns approval to move forward — most of the real thinking happens in that revision cycle, not in the eventual build.
Crucially, the press release is written from the customer’s point of view, not the company’s. It has to name a real problem, describe the solution in language a normal person would use, and include a believable customer quote. Teams that struggle to write a compelling one usually discover they don’t yet understand who they’re building for — which is a far cheaper realization to have on page one than at launch.
TGR Note: This is close in spirit to the argument in our summary of The Checklist Manifesto — a structured written artifact, drafted before high-stakes action, catches problems that ad-hoc judgment misses. The press release is Amazon’s version of a pre-flight check for an entire product line.
Part 2: Kill the Deck — Narrative Memos and the Silent-Reading Meeting
Around 2004, Bezos banned PowerPoint from Amazon’s senior meetings. In its place came the six-page narrative memo: a written document with a real introduction, real paragraphs, and a real argument, submitted before the meeting but read for the first twenty to thirty minutes of it, in total silence, by everyone in the room.
The reasoning is structural rather than stylistic. A slide of bullet points lets a presenter paper over gaps in logic with tone and body language — the audience fills in connections that were never actually made. A memo has nowhere to hide: if a sentence doesn’t follow from the one before it, everyone can see it in black and white, without a delivery smoothing it over. Silent reading also levels the room, letting junior staff absorb the same document at the same pace as the most senior executive in the room.
The format is demanding by design. Writing six pages of connected argument takes far longer than building twenty slides of fragments, and that difficulty is the point — it forces the author to actually resolve the hard tradeoffs on paper instead of waving at them out loud. Bryar and Carr note that the skill of writing these memos well is itself something Amazon deliberately trains and coaches, treating clear writing as a core leadership competency rather than a nice-to-have.
TGR Note: This connects directly to a core idea in our summary of How to Take Smart Notes: you don’t actually understand an idea until you can write it as a complete, connected sentence. The narrative memo applies that same principle to a whole team’s strategic thinking, not just one researcher’s notes.
Part 3: Protect the Bar — The Bar Raiser Hiring Process
Fast growth is usually where hiring quality quietly erodes — a team under pressure to fill seats starts saying yes to “good enough” candidates, and the average slowly drifts down. Amazon’s answer is the bar raiser: a specially trained interviewer, certified through a rigorous process, who sits in every hiring loop but has no stake in whether the role gets filled. Their only job is to ask whether this candidate raises the bar relative to the last several people hired into similar roles — and they hold explicit veto power. A hiring manager desperate to fill a seat cannot simply override them.
The interview process behind this is intentionally structured rather than instinctive: behavioral questions tied to Amazon’s leadership principles, independent write-ups from each interviewer before any group discussion happens, and a debrief that starts with the bar raiser’s read of the evidence rather than the hiring manager’s opinion. The goal isn’t to make hiring slower for its own sake — it’s to make the one decision that’s hardest to reverse (who joins the team) the one decision the company is least willing to rush.
Bryar and Carr are candid that this creates real friction — hiring managers sometimes resent losing a candidate they liked, and the process takes longer than an informal chat. But they argue the alternative, quietly lowering the bar under growth pressure, compounds into a much bigger problem once a team’s average quality has drifted without anyone deciding it should.
TGR Note: This pairs well with our summary of Rework, which makes the case for staying deliberately small rather than hiring reflexively. The bar raiser is Amazon’s mechanism for the same underlying instinct at much larger scale: every additional person should make the team better, not just bigger.
Part 4: Small Teams, Single Owners — 2-Pizza Teams, Single-Threaded Leadership, Input Metrics, and Disagree and Commit
The last cluster of mechanisms is about organizational structure once an idea has cleared the press-release stage. Amazon’s “two-pizza team” rule keeps teams small enough to be fed by two pizzas — roughly ten people or fewer — with real ownership over their own roadmap, code, and metrics. Smaller teams carry less coordination overhead: fewer meetings are needed to keep everyone aligned, because there are fewer people to align.
Big, ambiguous bets get a second structural safeguard: a single-threaded leader. This is one person, dedicated to one mission, with explicitly no other major initiative competing for their attention. Bryar and Carr point to Amazon’s biggest new businesses — including AWS in its early years — as cases where a leader freed from every other distraction was able to make faster, more consistent decisions than a committee or a part-time owner ever could.
Underneath both structures sits a measurement philosophy: track input metrics, the controllable steps in a process — like selection breadth, price, or defect rate — rather than only output metrics like total sales, which arrive too late to act on and can’t be directly steered. And when teams inevitably disagree about which inputs matter or how to prioritize them, Amazon’s leadership principle of “disagree and commit” gives them a way out of gridlock: state the disagreement clearly and completely in the room, then commit fully to the decision once it’s made, without quiet foot-dragging afterward.
TGR Note: This lines up closely with our summary of The E-Myth Revisited, which argues an owner should work on the business — building repeatable systems — rather than only in it. A single-threaded leader is exactly that: someone whose full-time job is building the system for one mission, not just executing inside it.
Who is Working Backwards best for — and who should read something else first?
Working Backwards is best for: product managers, startup founders scaling past ten or fifteen people, team leads drowning in status meetings, and operators who want Amazon’s actual internal playbook without hiring a consulting firm to reverse-engineer it.
Read something else first if:
- You’re a solo creator without a team yet — start with our summary of Rework for lean execution principles that don’t assume organizational scale.
- Your bottleneck is rigor in a specific high-stakes task rather than a whole planning process — start with our summary of The Checklist Manifesto.
- You haven’t yet systematized the business itself — start with our summary of The E-Myth Revisited before layering on Amazon-scale mechanisms.
Questions to reflect on
- Could you write a one-page press release for your next big project today? What would it force you to decide that you’ve been avoiding?
- What’s the last decision your team made off a slide deck that might have gone differently as a six-page memo?
- Do your teams have single, unambiguous owners — or does responsibility quietly diffuse across several people?
- Which of your metrics are inputs you actually control, and which are just outputs you’re hoping will improve?
- Where in your organization is disagreement going underground instead of being voiced and then resolved?
🔥 Ready to build Amazon’s operating system into your own team?
Get the full playbook — from press-release drafts to bar-raiser scorecards — straight from the two executives who built it.
How to apply Working Backwards (7-day plan)
- Day 1: Pick one upcoming project and write a one-page, customer-facing press release for it — no jargon, no internal acronyms.
- Day 2: Draft the FAQ. Answer the five hardest questions a skeptical customer or executive would ask.
- Day 3: Replace your next slide deck with a one-to-two-page narrative memo. Circulate it and ask people to read silently first.
- Day 4: Audit your team’s boundaries. Could the work be reorganized into one or two smaller teams with clearer single ownership?
- Day 5: Name a single-threaded leader for your most important, most-stalled initiative — and clear other priorities off their plate.
- Day 6: List three input metrics you could track weekly instead of only watching the final output number.
- Day 7: In your next contested decision, state your disagreement explicitly — then commit fully once the call is made, and hold the team to it.
Frequently asked questions
What is the Working Backwards process at Amazon?
Working Backwards is Amazon’s practice of starting any new initiative by writing a press release and FAQ document for the finished product before any building begins. The press release is written in plain customer language and describes the problem, the solution, and a believable customer reaction, as if the product had already launched. Teams revise the document — sometimes dozens of times — until it’s genuinely compelling on paper. Only once it clears that bar does engineering work start. The process is deliberately cheap and fast compared to building the wrong thing, and it forces teams to define the customer outcome before locking in any technical approach.
Why did Amazon ban PowerPoint?
Amazon’s leadership found that slide decks let presenters paper over gaps in logic with delivery, tone, and body language, while the audience filled in connections that were never actually stated. Around 2004, PowerPoint was replaced in senior meetings with six-page narrative memos, written in full sentences and paragraphs, that are read silently by everyone in the room for the first twenty to thirty minutes of a meeting. A written memo exposes weak arguments immediately because there’s no presenter to smooth them over, and it lets every attendee absorb the same information at the same pace before discussion begins.
What does a bar raiser do in Amazon’s hiring process?
A bar raiser is a specially trained, certified interviewer who joins a hiring loop but has no stake in whether the specific role gets filled. Their job is to judge whether a candidate raises the bar relative to recent hires in similar roles, and they hold explicit veto power over the hire — a hiring manager cannot simply overrule them to fill an open seat faster. The system exists because hiring quality tends to quietly erode under growth pressure, and an independent, incentive-free voice in the room is Amazon’s way of protecting long-term team quality even when a team urgently needs headcount.
What is a two-pizza team?
A two-pizza team is Amazon’s guideline for team size: small enough to be fed by two pizzas, generally around ten people or fewer. The idea is that smaller teams need far less coordination overhead than larger ones, because there are fewer people who need to stay aligned. Two-pizza teams typically own their own roadmap, codebase, and operational metrics end to end, rather than depending heavily on other teams to ship. This autonomy is what lets a large company like Amazon still move with the speed and ownership normally associated with a small startup.
What does single-threaded leadership mean?
A single-threaded leader is one person assigned to one mission or initiative, with no other major competing priority on their plate at the same time. Amazon uses this structure for its biggest, most ambiguous bets — AWS in its early years is one example the book discusses — because a leader who isn’t splitting attention across several initiatives can make faster, more consistent decisions and build institutional knowledge about the problem that a rotating or part-time owner never accumulates. It’s a direct structural fix for the common failure mode where important projects stall because everyone responsible for them is also responsible for several other things.
Is Working Backwards only useful for tech companies?
No — while the examples are drawn from Amazon’s retail and technology businesses, the mechanisms are domain-agnostic. Writing a press release before committing resources, replacing slide decks with structured written arguments, protecting hiring quality with an independent reviewer, and giving initiatives a single clear owner all apply to a marketing team, a nonprofit, or a five-person startup just as directly as they apply to Amazon. The book is explicit that these are meant to be adapted, not copied wholesale.
How is Working Backwards different from Amazon’s own published Leadership Principles?
Amazon’s Leadership Principles are the widely published values (Customer Obsession, Ownership, Bias for Action, and others) that show up in interviews and performance reviews. Working Backwards is about the operational mechanisms that actually put those values into practice day to day — the specific meeting formats, documents, hiring steps, and team structures that make principles like “customer obsession” real rather than aspirational. Bryar and Carr, both former Amazon vice presidents, wrote it specifically because the principles alone don’t explain how the company executes; the mechanisms in this book are the missing operational layer.
Related summaries
- Rework Summary & Review
- The Checklist Manifesto Summary & Review
- The E-Myth Revisited Summary & Review
- How to Take Smart Notes Summary & Review
See more in our best productivity books guide.
How we analyze books: We read the full text, cross-reference the author’s own interviews and published essays, and structure each summary around the book’s actual arguments rather than secondhand takes. Every internal link points to another TGR summary we’ve written the same way. Read our full methodology.