Amazon in 2006: should a retailer sell servers?

The context, in plain terms

In 2006, Amazon is known as an online retailer that has grown from books to nearly everything. To run at that scale it has built a large internal, service-oriented infrastructure. The decision on the bench is whether to turn that internal machinery into a product for outsiders: rent storage and computing power to any developer, as a metered, pay-as-you-go utility.

The move takes shape as two services. Amazon S3, launched in March 2006, rents storage. Amazon EC2, launched in beta in August 2006, rents compute by the hour, with the ability to scale up under load and back down to save cost. The idea traces back to internal work: by late 2003 the company had identified storage, compute and databases as infrastructure it could one day offer to others. This is a departure, a retailer selling raw computing as a utility rather than selling goods.

This case replays that 2006 fork as a decision to test, using only what was known at the time. The panel gathers the people who would react then: Amazon's retail leadership, Wall Street analysts, developers at startups and larger companies, the board, and infrastructure incumbents. What follows is what the bench surfaced in the moment, not what history later recorded.

A panel split down the middle

The Kapari bench ran a simulated panel of 58 voices against Amazon's decision to sell computing as a utility. The range is split almost in two: 25 voices support the move, 27 are hostile to it, and only 6 sit in doubt. This is not a soft consensus, it is a real divide, with roughly as many voices for as against. The engine replayed the simulation three times and the split held across all three passes, which points to a genuine fault line rather than a one-off draw.

A believer among the doubters

One signal stands out inside Amazon itself. The retail leadership group, taken as a whole, leans against the move: it reads as a distraction from the core business. Yet one voice there, an infrastructure believer, breaks with its own camp and argues for it. This crossover voice, a dissent coming from inside the group that is supposed to resist, is the one to sit with first, because it often carries the argument the room is talking itself out of. The other signal is the weighing of the room: the infrastructure incumbents react loudly against the idea, but at about 13 percent of the panel they carry little weight in the verdict. Their noise is worth understanding, it does not decide the outcome.

Doubt about execution, the real friction

The dominant friction the engine reads is not whether the idea is good, it is doubt about execution: can a retailer really run a public computing utility, bill it by the hour, keep it up, and support outside developers? That doubt is strongest among the infrastructure incumbents, who question whether a bookstore belongs in their business. It is the friction to defuse before exposing the decision widely: the case has to be made on operational credibility, not on vision alone.

Adjust: how the decision gets through

The bench returns Adjust, with a High reception risk. It follows from a panel split almost evenly and a single dominant friction, doubt about execution, rather than from a rejection of the idea itself. The way through is built from the signals. Start with the believer inside retail leadership: that crossover voice already holds the internal argument, and hearing it in full either sharpens the plan or hardens conviction against the group's caution. Answer the incumbents on execution, not on vision, even though they carry little weight, so their noise does not set the narrative. And treat the near-even split as the real message: a decision this divisive gets through by proving operational credibility to the doubters, not by out-arguing the believers. The split held across three passes, which is what makes this a fault line to manage, not a coin toss.

Questions about this case

Related cases