What Amazon's product actually is
Jeff Bezos founded Amazon in 1994 in Bellevue, Washington, as an online bookstore. The choice of books as the starting category was deliberate: books have a standard format (ISBN), low unit cost, and a catalogue so large that no physical store could stock everything. An online store with a warehouse and a fulfillment operation could offer everything a physical bookstore couldn't. By the early 2000s, Amazon had expanded to CDs, DVDs, electronics, toys, and eventually everything. By the 2020s, the company had extended into cloud computing (AWS), digital streaming, advertising, logistics, grocery, and hardware. It was one of the five largest companies in the US technology sector.
The simplest description of Amazon's product strategy is: understand what the customer wants before they can articulate it, and deliver it faster than they expect. Every major product bet Amazon has made follows this pattern. And the mechanism through which Amazon executes it is data science — not as a department or a feature, but as the primary product architecture.
The Amazon that most users interact with is a front end. The product underneath is a system of prediction models that determines what appears on your homepage, what price you're shown, how quickly your order can arrive, and what you're likely to buy next. Data science isn't a tool Amazon uses — it's what Amazon is built on.
The Decision: instrument the customer, not just the transaction
Most e-commerce companies in the late 1990s collected transaction data: what was bought, by whom, at what price, when. Amazon collected that too. What distinguished Amazon's approach was the decision to collect and act on behavioral data that preceded and followed the transaction: what pages were browsed, in what order, for how long; what searches were entered that didn't convert; what items were added to wish lists and then not purchased; what a customer who bought X also looked at before deciding.
This data is not about what customers said they wanted. It is about what customers actually did, including the failures — the searches that found nothing, the items added to carts and abandoned. Behavioral data from failures is often more informative than behavioral data from conversions, because it reveals the gap between what the platform currently offers and what the customer was actually looking for.
The recommendation system Amazon built from this data — "Customers who bought X also bought Y" — accounts for an estimated 25-35% of Amazon's total revenue. This is not a marginal feature. It is a primary revenue mechanism, and it is built entirely on the pattern recognition that becomes possible when you have transactional and behavioral data from hundreds of millions of customers across every product category.
Anticipatory shipping — Amazon's patented system that moves products to warehouses before orders are placed — is the same logic applied to logistics. If the behavioral data predicts with sufficient confidence that a customer in Bangalore is likely to order a specific coffee grinder in the next two days, Amazon moves that grinder to the warehouse closest to that customer before the order is placed. When the order comes in, the last-mile delivery time collapses. A two-day ship becomes a same-day ship. The prediction cost (holding extra inventory near predicted demand) is lower than the revenue benefit (customer retention from faster delivery). The model only works if the prediction accuracy is high enough — which is why it required years of transaction data to be viable.
What Worked / What Failed
The recommendation engine worked because Amazon invested in it as infrastructure before it generated direct revenue. In the early 2000s, collaborative filtering at the scale of Amazon's catalogue was computationally expensive and technically non-trivial. Amazon built the capability before the ROI was obvious, which meant they were running a functioning recommendation system when competitors were still hand-curating editorial picks. By the time the ROI was obvious, Amazon had years of training data that made the models significantly more accurate than anything a new entrant could build.
The dynamic pricing system worked as a margin optimisation strategy with a user experience benefit: price-sensitive customers see lower prices at the right moment; the platform captures higher margins from customers with lower price sensitivity. The optimisation is silent from the user's perspective — most users experience Amazon's pricing as "usually fair" without understanding that the price they see is personalised. This invisibility is a feature, not a failing. An optimisation system that users can see and react to strategically is less effective than one that operates below the threshold of conscious attention.
What failed, and what generated significant regulatory and public scrutiny, was the use of third-party seller data in private label strategy. Amazon marketplace sellers generate transaction and search data that flows into Amazon's data infrastructure. Amazon's private label team (Amazon Basics, etc.) had access to this data and could use it to identify product categories where demand was high and margins were attractive, then launch Amazon-branded products that competed directly with the sellers whose data had identified the opportunity. This was not illegal but it violated the implicit contract under which third-party sellers chose to list on the platform. The trust failure had measurable consequences: sellers began withholding their best products from Amazon Marketplace and investing in direct-to-consumer channels.
What a PM should take from this
The Amazon case is the clearest available example of data science built into product architecture from the beginning, rather than layered on as a capability afterward. The recommendation engine, anticipatory shipping, and dynamic pricing are not features that could be added to a generic e-commerce platform — they are the platform. The product that users experience is the output of prediction models that Amazon spent a decade building and training. Removing those models would not leave Amazon as a slower e-commerce site. It would leave Amazon as a worse product than any competitor who kept them.
This is the distinction between data science as product infrastructure and data science as product feature. A feature is something you add to improve a product that already works. Infrastructure is something the product doesn't function without. Building data science as infrastructure requires the investment before the ROI is clear, which is the decision most organisations find hardest to make and sustain.
The second lesson is about the compounding advantage of behavioral data over time. Amazon in 1998 had transaction data from a small catalogue of books. Amazon in 2005 had behavioral data from millions of customers across every major product category. Amazon in 2015 had that data plus thirteen years of model refinement, labeling infrastructure, and prediction accuracy improvement. Each year's data makes the models better. Better models increase conversion. Higher conversion generates more data. This loop is not a network effect in the traditional sense — it doesn't require other users to be valuable — but it compounds in the same way. The businesses that get displaced by Amazon-scale data systems are rarely defeated on product quality. They are outcompeted on prediction accuracy over time.