
After I joined Amazon, Jeff had an concept: no staff must be so massive that it couldn’t be fed by two pizzas. In these early days, some groups have been so small that one pizza would’ve been sufficient to get the job achieved. But it surely was by no means actually about feeding hungry engineers. We may’ve simply as simply mentioned a “six sandwich staff”, however sandwiches don’t evoke the identical imagery as pizza. Pizza is what you order whenever you and your friends are crowded across the whiteboard late into the night.
We wished to maintain groups sufficiently small so that everybody within the room knew what everybody else was engaged on, with out requiring conferences. Every member of the staff owned the product. You had the autonomy to make selections with as little paperwork as potential. You have been empowered to maneuver quick, to experiment, and to not be afraid of failure. If the choice was reversible, you didn’t want permission to make it. You made it, you discovered from it, and if it was unsuitable, you reversed it. The price of a unsuitable reversible determination is sort of at all times decrease than the price of making that call slowly.
As our buyer base grew, so did the variety of our groups. Whenever you go from three companies to over 200, you don’t get to maintain the identical organizational construction. It’s easy physics: as techniques develop, so does their entropy. Every service requires homeowners, and homeowners have to coordinate with the groups whose companies they rely on. Org constructions grow to be layered, dependencies multiply, and approval cycles seem the place none existed earlier than. All of the sudden, a staff that used to personal an issue end-to-end now wants alignment throughout a number of groups earlier than they write a single line of code. At some second, the inertia of any rising firm begins to work towards the very tradition that made it profitable. This doesn’t essentially imply the standard of the product will undergo, however until you battle it, it means your pace of supply will lower.
Together with the two-pizza strategy to handle staff measurement, we used a singular strategy to outline our merchandise—working backwards from the shopper. I wrote about this again in 2006:
The Working Backwards product definition course of is all about fleshing out the idea and reaching readability of considered what we are going to in the end go off and construct. It sometimes has 4 steps:
- Begin by writing the Press Launch
- Write a Continuously Requested Questions doc
- Outline the shopper expertise
- Write the consumer handbook
We’ve achieved exceptional successes working backwards, and have solved actual issues for thousands and thousands of consumers utilizing feats of engineering that also amaze me to today. Our groups are nonetheless sized round our two-pizza mannequin. They nonetheless transfer quick and break issues, however they wait till they’ve totally outlined the issue and the whole enterprise line clearly understands how they’ll clear up it collectively.
However there’s a shift occurring in our business, and I maintain listening to tales throughout Amazon which might be difficult me to assume a bit otherwise concerning the strategy of bringing merchandise to life. Should you take a look at the 4 steps above, what they’ve in widespread is deep fascinated by the issue house, then writing about it. Getting the concept out of your head and onto paper is the way you hone the concept. You poke holes in it, uncover what you don’t know, and share it together with your friends to reach at a shared understanding of what’s going to be constructed. It’s exhausting work to jot down a crisp doc, and almost not possible in case you don’t have readability of thoughts concerning the buyer drawback you wish to clear up. However there’s one other very deliberate purpose we use writing at Amazon: writing permits anybody to construct a product as a result of it doesn’t require you to know learn how to code. A product supervisor, a UI designer, a enterprise analyst, anybody with a well-written concept and compelling argument may outline what will get constructed subsequent.
However what occurs when anybody with an concept can sit down with a coding agent and produce a practical shell of a product in a single night?
In late January 2026, a handful of our scientists have been speaking amongst one another and realized they’d all been fascinated by the identical drawback house independently. How do you give an agent reminiscence that persists? How do you let a number of brokers coordinate with out a central bottleneck? How do you retain people in management whereas the system scales? They wanted an working system for brokers. They determined to get right into a room collectively for just a few days and see what they may give you.
Thomas Delteil, who’s a principal scientist on our Amazon Fast staff, had been involved by the tempo at which good concepts have been dying. The cycle of proposing an concept, ready for dialogue, constructing a proof of idea, benchmarking it, searching for visibility for it, then ready once more for the following spherical of approvals was killing concepts earlier than they ever reached a single buyer. So when the dialog turned to what they may construct in the event that they stopped ready for permission, Thomas spent the whole night time utilizing Kiro to construct the primary prototype of what would grow to be Amazon Fast Desktop. When he demoed it the following day, the primary query from the staff was “how do I get this on my laptop computer proper now?” and the second was “what can I assist with?” Inside hours of first seeing it, the undertaking had an proprietor for the exercise feed, an proprietor for reminiscence, an proprietor for the data graph, and an proprietor for the agentic harness.
Inside every week, Swami Sivasubramanian, our VP of Agentic AI, noticed the prototype and gave the staff his full help. Three engineers joined. By the second week, that they had a software program growth supervisor and some extra engineers, reaching a roughly even break up between science and engineering. They have been deliberate about not scaling too quick. Every one that was introduced on was chosen as a result of that they had a selected ability, and so they needed to adapt to a tradition that was an entire departure from how the broader group operated. They have been anticipated to personal an issue and ship with autonomy, and possession meant the identical factor it has at all times meant at Amazon: you construct it, you personal it.
Leo Ohannesian, the product supervisor recruited to hitch the Fast staff 5 days into the trouble, had spent years working in organizations that began with a PRFAQ, would undergo overview cycles, safe funding, assign homeowners, and set timelines. On this early staff, there was none of that. Switching to a mannequin the place a small group of senior individuals have been totally trusted to make the correct selections produced a velocity he’d by no means skilled in his profession.
A giant driver of what made this tempo potential was that each individual on the staff used the product as their main AI assistant from day one. Thomas was constructing it the way in which he wished an assistant to be, and something he didn’t like, he mounted. Everybody on the staff operated the identical manner. They didn’t go away tough edges for a designer to easy out later or file a ticket for a frontend engineer to choose up within the subsequent dash. Should you observed one thing was unsuitable when you have been utilizing it, you owned it, and also you mounted it. Each code overview got here with a video of the expertise as a result of reviewing the code in isolation tells you nothing about whether or not the product feels proper to make use of. This was a deliberate inversion of how the staff had labored earlier than, the place you’d benchmark first and work out the expertise later. Right here, the rule was: don’t benchmark something till you’re proud of the expertise you may have.
Clare Liguori, a senior principal engineer who led the event of Kiro, spoke about her expertise at my re:Invent keynote final 12 months and lately wrote about this identical sample. Her remark is that when constructing a prototype takes days, not months, it makes extra sense to prototype earlier than writing. Her staff began utilizing their IDE full-time from the second the primary prototype labored, and advanced it each day based mostly on what they really wanted.
Writing remains to be as essential as ever, and it must be you doing the writing, not your AI. Writing forces you to assume clearly and confront gaps in your logic. What has modified is that writing is not the one solution to make an concept tangible. Coding brokers are compressing the time between defining the issue and having one thing actual in our arms to judge. It’s time to amend the way in which we take into consideration the method that’s introduced us this far. You’ll be taught extra in a single night of constructing than in two weeks of writing about what you assume will occur. Solely after you’ve frolicked with the prototype, used it the way in which a buyer would, and developed an actual understanding of what it might and can’t do, do you start the writing course of. The doc you produce after constructing is basically higher than the one you’d have written earlier than, as a result of it’s not grounded in your assumptions.
So how will we amend Working Backwards? When you may have conviction concerning the buyer drawback however have real uncertainty about whether or not your strategy will work, you begin by constructing a prototype. Then you definately use it the way in which a buyer would. You break issues, you discover the gaps your instinct missed, then you definitely share it with just a few colleagues, and if there’s pleasure round what you’ve constructed, you write the doc. Having one thing tangible to click on by means of as you write modifications the standard of the doc. You’re not describing one thing you’ve solely imagined in your head. You’re describing one thing that now exists and has been pressure-tested, and your writing will replicate that.
The Fast Desktop staff is not a handful of individuals in a convention room. They’ve grown to a number of hundred engineers, scientists, designers, and product managers. That’s the pure trajectory of a product that a whole lot of 1000’s of individuals now use day-after-day. Each staff that grows previous a sure threshold faces the identical gravitational pull towards the overhead I described earlier. The best way you battle that’s permitting your groups the liberty to function as a group of two-pizza groups, every with clear possession and the autonomy to make reversible selections with out asking permission. You battle it by holding the suggestions loop quick: construct, use, be taught, iterate. You battle it by hiring people who find themselves uncomfortable once they don’t personal their drawback end-to-end, and by giving them the instruments to behave on that discomfort.
Two pizzas have been at all times about possession tradition, and the instruments have caught as much as the tradition. What made the Fast Desktop staff profitable is similar factor that has at all times produced the perfect work I’ve seen at Amazon: a small group of people that trusted one another, owned the issue finish to finish, and acted on their conviction.
Now, go construct!
