When I joined Amazon, Jeff had an idea: no team should be so large that it couldn’t be fed by two pizzas. In those early days, some teams were so small that one pizza would’ve been enough to get the job done. But it was never really about feeding hungry engineers. We could’ve just as easily said a “six sandwich team”, but sandwiches don’t evoke the same imagery as pizza. Pizza is what you order when you and your peers are crowded around the whiteboard late into the evening.

We wanted to keep teams small enough so that everyone in the room knew what everyone else was working on, without requiring meetings. Each member of the team owned the product. You had the autonomy to make decisions with as little bureaucracy as possible. You were empowered to move fast, to experiment, and to not be afraid of failure. If the decision was reversible, you didn’t need permission to make it. You made it, you learned from it, and if it was wrong, you reversed it. The cost of a wrong reversible decision is almost always lower than the cost of making that decision slowly.

As our customer base grew, so did the number of our teams. When you go from three services to over two hundred, you do not get to keep the same organizational structure. It’s simple physics: as systems grow, so does their entropy. Each service requires owners, and owners need to coordinate with the teams whose services they depend on. Org structures become layered, dependencies multiply, and approval cycles appear where none existed before. Suddenly, a team that used to own a problem end-to-end now needs alignment across multiple teams before they write a single line of code. At some moment, the inertia of any growing company begins to work against the very culture that made it successful. This doesn’t necessarily mean the quality of the product will suffer, but unless you fight it, it means your speed of delivery will decrease.  

Along with the two-pizza approach to manage team size, we used a unique approach to define our products—working backwards from the customer. I wrote about this back in 2006:

The Working Backwards product definition process is all about fleshing out the concept and achieving clarity of thought about what we will ultimately go off and build. It typically has four steps:

1. Start by writing the Press Release
2. Write a Frequently Asked Questions document
3. Define the customer experience
4. Write the user manual

We’ve achieved remarkable successes working backwards, and have solved real problems for millions of customers using feats of engineering that still amaze me to this day. Our teams are still sized around our two-pizza model. They still move fast and break things, but they wait until they have fully defined the problem and the entire business line clearly understands how they’ll solve it together.  

But there’s a shift happening in our industry, and I keep hearing stories across Amazon that are challenging me to think a bit differently about the process of bringing products to life. If you look at the four steps above, what they have in common is deep thinking about the problem space, then writing about it. Getting the idea out of your head and onto paper is how you hone the idea. You poke holes in it, discover what you don’t know, and share it with your peers to arrive at a shared understanding of what will be built. It’s hard work to write a crisp document, and nearly impossible if you don’t have clarity of mind about the customer problem you want to solve. But there’s another very deliberate reason we use writing at Amazon: writing allows anyone to build a product because it doesn’t require you to know how to code. A product manager, a UI designer, a business analyst, anyone with a well-written idea and compelling argument could define what gets built next.

But what happens when anyone with an idea can sit down with a coding agent and produce a functional shell of a product in a single evening?

In late January 2025, a handful of our scientists were talking among each other and realized they’d all been thinking about the same problem space independently. How do you give an agent memory that persists? How do you let multiple agents coordinate without a central bottleneck? How do you keep humans in control while the system scales? They needed an operating system for agents. They decided to get into a room together for a few days and see what they could come up with.

Thomas Delteil, who is a principal scientist on our Amazon Quick team, had been concerned by the pace at which good ideas were dying. The cycle of proposing an idea, waiting for discussion, building a proof of concept, benchmarking it, seeking visibility for it, then waiting again for the next round of approvals was killing ideas before they ever reached a single customer. So when the conversation turned to what they could build if they stopped waiting for permission, Thomas spent the entire night using Kiro to build the first prototype of what would become Amazon Quick Desktop. When he demoed it the next day, the first question from the team was “how do I get this on my laptop right now?” and the second was “what can I help with?” Within hours of first seeing it, the project had an owner for the activity feed, an owner for memory, an owner for the knowledge graph, and an owner for the agentic harness.

Within a week, Swami Sivasubramanian, our VP of Agentic AI, saw the prototype and gave the team his full support. Three engineers joined. By the second week, they had a software development manager and a few more engineers, reaching a roughly even split between science and engineering. They were deliberate about not scaling too fast. Each person who was brought on was selected because they had a specific skill, and they had to adapt to a culture that was a complete departure from how the broader organization operated. They were expected to own a problem and deliver with autonomy, and ownership meant the same thing it has always meant at Amazon: you build it, you own it. 

Leo Ohannesian, the product manager recruited to join the Quick team five days into the effort, had spent years working in organizations that started with a PRFAQ, would go through review cycles, secure funding, assign owners, and set timelines. On this early team, there was none of that. Switching to a model where a small group of senior people were fully trusted to make the right decisions produced a velocity he’d never experienced in his career.

A big driver of what made this pace possible was that every person on the team used the product as their primary AI assistant from day one. Thomas was building it the way he wanted an assistant to be, and anything he didn’t like, he fixed. Everyone on the team operated the same way. They didn’t leave rough edges for a designer to smooth out later or file a ticket for a frontend engineer to pick up in the next sprint. If you noticed something was wrong while you were using it, you owned it, and you fixed it. Every code review came with a video of the experience because reviewing the code in isolation tells you nothing about whether the product feels right to use. This was a deliberate inversion of how the team had worked before, where you’d benchmark first and figure out the experience later. Here, the rule was: don’t benchmark anything until you’re happy with the experience you have.

Clare Liguori, a senior principal engineer who led the development of Kiro, spoke about her experience at my re:Invent keynote last year and recently wrote about this same pattern. Her observation is that when building a prototype takes days, not months, it makes more sense to prototype before writing. Her team started using their IDE full-time from the moment the first prototype worked, and evolved it daily based on what they actually needed.

Writing is still as important as ever, and it should be you doing the writing, not your AI. Writing forces you to think clearly and confront gaps in your logic. What has changed is that writing is no longer the only way to make an idea tangible. Coding agents are compressing the time between defining the problem and having something real in our hands to evaluate. It is time to amend the way we think about the process that’s brought us this far. You will learn more in one evening of building than in two weeks of writing about what you think will happen. Only after you’ve spent time with the prototype, used it the way a customer would, and developed a real understanding of what it can and cannot do, do you begin the writing process. The document you produce after building is fundamentally better than the one you would have written before, because it’s no longer grounded in your assumptions. 

So how do we amend Working Backwards? When you have conviction about the customer problem but have genuine uncertainty about whether your approach will work, you start by building a prototype. Then you use it the way a customer would. You break things, you find the gaps your intuition missed, then you share it with a few colleagues, and if there’s excitement around what you’ve built, you write the doc. Having something tangible to click through as you write changes the quality of the document. You’re no longer describing something you’ve only imagined in your head. You’re describing something that now exists and has been pressure-tested, and your writing will reflect that.

The Quick Desktop team is no longer a handful of people in a conference room. They’ve grown to several hundred engineers, scientists, designers, and product managers. That is the natural trajectory of a product that hundreds of thousands of people now use every day. Every team that grows past a certain threshold faces the same gravitational pull toward the overhead I described earlier. The way you fight that is allowing your teams the freedom to operate as a collection of two-pizza teams, each with clear ownership and the autonomy to make reversible decisions without asking permission. You fight it by keeping the feedback loop short: build, use, learn, iterate. You fight it by hiring people who are uncomfortable when they don’t own their problem end-to-end, and by giving them the tools to act on that discomfort. 

Two pizzas were always about ownership culture, and the tools have caught up to the culture. What made the Quick Desktop team successful is the same thing that has always produced the best work I’ve seen at Amazon: a small group of people who trusted each other, owned the problem end to end, and acted on their conviction.

Now, go build!