Once I joined Amazon, Jeff had an thought: no staff must be so giant 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 carried out. Nevertheless it was by no means actually about feeding hungry engineers. We may’ve simply as simply stated a “six sandwich staff”, however sandwiches don’t evoke the identical imagery as pizza. Pizza is what you order while 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 attainable. 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 realized from it, and if it was mistaken, you reversed it. The price of a mistaken reversible determination is nearly all the time decrease than the price of making that call slowly.
As our buyer base grew, so did the variety of our groups. If you go from three companies to over 2 hundred, 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 must coordinate with the groups whose companies they depend upon. Org buildings 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 in opposition to the very tradition that made it profitable. This doesn’t essentially imply the standard of the product will undergo, however except you struggle it, it means your pace of supply will lower.
Together with the two-pizza method to handle staff measurement, we used a singular method 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 attaining readability of thought of what we’ll in the end go off and construct. It usually has 4 steps:
- Begin by writing the Press Launch
- Write a Ceaselessly Requested Questions doc
- Outline the shopper expertise
- Write the consumer handbook
We’ve achieved exceptional successes working backwards, and have solved actual issues for tens of millions of shoppers 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 all the enterprise line clearly understands how they’ll clear up it collectively.
However there’s a shift taking place in our business, and I preserve listening to tales throughout Amazon which might be difficult me to assume a bit in another way concerning the strategy of bringing merchandise to life. Should you have a look at the 4 steps above, what they’ve in widespread is deep fascinated by the issue area, 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 along with your friends to reach at a shared understanding of what’s going to be constructed. It’s arduous work to jot down a crisp doc, and practically inconceivable in the event you don’t have readability of thoughts concerning the buyer downside you wish to clear up. However there’s one other very deliberate cause we use writing at Amazon: writing permits anybody to construct a product as a result of it doesn’t require you to know easy methods to code. A product supervisor, a UI designer, a enterprise analyst, anybody with a well-written thought and compelling argument may outline what will get constructed subsequent.
However what occurs when anybody with an thought 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 downside area 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 a number of days and see what they might 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 thought, ready for dialogue, constructing a proof of idea, benchmarking it, in search of 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 might construct in the event that they stopped ready for permission, Thomas spent all the 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 challenge had an proprietor for the exercise feed, an proprietor for reminiscence, an proprietor for the information graph, and an proprietor for the agentic harness.
Inside per 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 particular ability, and so they needed to adapt to a tradition that was a whole 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 all the time meant at Amazon: you construct it, you personal it.
Leo Ohannesian, the product supervisor recruited to affix the Fast staff 5 days into the hassle, had spent years working in organizations that began with a PRFAQ, would undergo assessment 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 attainable was that each individual on the staff used the product as their major 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 approach. They didn’t depart tough edges for a designer to clean out later or file a ticket for a frontend engineer to choose up within the subsequent dash. Should you seen one thing was mistaken whilst you have been utilizing it, you owned it, and also you mounted it. Each code assessment 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 pleased with the expertise you’ve got.
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 not too long ago wrote about this identical sample. Her statement 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 developed it day by day based mostly on what they really wanted.
Writing remains to be as necessary 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 approach to make an thought tangible. Coding brokers are compressing the time between defining the issue and having one thing actual in our palms 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 study extra in a single night of constructing than in two weeks of writing about what you assume will occur. Solely after you’ve hung out with the prototype, used it the way in which a buyer would, and developed an actual understanding of what it could possibly 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 can we amend Working Backwards? When you’ve got conviction concerning the buyer downside however have real uncertainty about whether or not your method will work, you begin by constructing a prototype. Then you definitely use it the way in which a buyer would. You break issues, you discover the gaps your instinct missed, you then share it with a number of colleagues, and if there’s pleasure round what you’ve constructed, you write the doc. Having one thing tangible to click on by way 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 tons of of hundreds of individuals now use each day. Each staff that grows previous a sure threshold faces the identical gravitational pull towards the overhead I described earlier. The best way you struggle 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 struggle it by protecting the suggestions loop quick: construct, use, study, iterate. You struggle it by hiring people who find themselves uncomfortable after they don’t personal their downside end-to-end, and by giving them the instruments to behave on that discomfort.
Two pizzas have been all the time 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 all the time produced the very best 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!