After I joined Amazon, Jeff had an concept: no staff needs to 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 might’ve simply as simply mentioned a “six sandwich staff”, however sandwiches don’t evoke the identical imagery as pizza. Pizza is what you order if 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 forms as doable. 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 resolution is nearly 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 providers to over 2 hundred, you don’t get to maintain the identical organizational construction. It’s easy physics: as methods develop, so does their entropy. Every service requires house owners, and house owners must coordinate with the groups whose providers they rely on. Org constructions grow to be layered, dependencies multiply, and approval cycles seem the place none existed earlier than. Abruptly, 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 until you struggle it, it means your velocity of supply will lower.
Together with the two-pizza method to handle staff dimension, we used a novel 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 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 Regularly Requested Questions doc
- Outline the shopper expertise
- Write the consumer handbook
We’ve achieved exceptional successes working backwards, and have solved actual issues for hundreds of thousands of consumers utilizing feats of engineering that also amaze me to at the present time. 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 complete enterprise line clearly understands how they’ll resolve it collectively.
However there’s a shift occurring in our business, and I preserve listening to tales throughout Amazon which are difficult me to assume a bit otherwise concerning the strategy of bringing merchandise to life. For those who have a look at the 4 steps above, what they’ve in frequent is deep excited about 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 arduous work to put in writing a crisp doc, and practically inconceivable when you don’t have readability of thoughts concerning the buyer drawback you wish to resolve. 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 the best way to code. A product supervisor, a UI designer, a enterprise analyst, anybody with a well-written concept and compelling argument might outline what will get constructed subsequent.
However what occurs when anybody with an concept can sit down with a coding agent and produce a purposeful 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 excited about the identical drawback house independently. How do you give an agent reminiscence that persists? How do you let a number of brokers coordinate with no 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 couple of 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, looking for visibility for it, then ready once more for the subsequent 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 complete evening utilizing Kiro to construct the primary prototype of what would grow to be Amazon Fast Desktop. When he demoed it the subsequent 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 mission 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 talent, they usually 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 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 evaluation cycles, safe funding, assign house owners, 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.
An enormous driver of what made this tempo doable was that each individual on the staff used the product as their major AI assistant from day one. Thomas was constructing it the best way he wished an assistant to be, and something he didn’t like, he fastened. Everybody on the staff operated the identical means. They didn’t depart tough edges for a designer to easy out later or file a ticket for a frontend engineer to select up within the subsequent dash. For those who observed one thing was mistaken when you have been utilizing it, you owned it, and also you fastened it. Each code evaluation 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 could 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 not too long ago wrote about this similar sample. Her commentary 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 every day primarily based on what they really wanted.
Writing remains to be as necessary as ever, and it needs to 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 now not the one method to make an concept 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 best way 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 hung out with the prototype, used it the best way 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’ll have written earlier than, as a result of it’s now not grounded in your assumptions.
So how can we amend Working Backwards? When you could have conviction concerning the buyer drawback however have real uncertainty about whether or not your method will work, you begin by constructing a prototype. Then you definately use it the best way a buyer would. You break issues, you discover the gaps your instinct missed, you then share it with a couple of 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 now 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 mirror that.
The Fast Desktop staff is now 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 bunch of 1000’s of individuals now use on daily basis. Each staff that grows previous a sure threshold faces the identical gravitational pull towards the overhead I described earlier. The way in which you struggle that’s permitting your groups the liberty to function as a set of two-pizza groups, every with clear possession and the autonomy to make reversible selections with out asking permission. You struggle it by retaining the suggestions loop brief: construct, use, be taught, iterate. You struggle 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 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!
