90% of AWS Is Born from Customer Feedback - Working Backwards and Customer-Driven Innovation

We explain how the Working Backwards process and the Customer Obsession principle shape AWS service development. Learn about the innovation mechanism that starts with PR/FAQ documents and the process for incorporating customer feedback.

About 7 min readLast updated: 2026-10-29

The Fact That 90% Comes from Customer Feedback

AWS releases new services and features every day, and approximately 90% of them are developed based on customer feedback. This figure has been explicitly stated on the official AWS blog. When customers say "I want this feature" or "This part is hard to use," those voices are directly reflected in the product development roadmap. The remaining roughly 10% consists of innovations that anticipate latent needs customers haven't yet articulated, developed by observing technology trends and industry developments. These innovations identify friction points in the customer journey and create new features that surprise and delight customers.

Working Backwards - A Development Process That Starts from the Customer

Supporting this customer-driven innovation is Amazon's unique Working Backwards process. In typical product development, teams start from technology or ideas and think about "what can we build." Working Backwards reverses this by starting from "what does the customer need" and designing the product backward from there. The process consists of five stages: Listen (hear the customer's voice), Define (define the problem to solve), Invent (invent the solution), Refine (polish it), and Test & Iterate (test and iterate). This process eliminates the risk of building something that is technically possible but not what customers want.

PR/FAQ - Writing the Press Release Before Development

At the core of Working Backwards is a method called PR/FAQ. Before starting development of a new service or feature, the team first writes the press release that would be issued when the service is complete, along with answers to questions (FAQ) that customers and internal stakeholders would likely ask. The press release describes the value to customers, the problems being solved, and specific usage scenarios. By creating this document before writing a single line of code and reviewing it within the team, projects with unclear customer value can be identified early. Projects whose PR/FAQ isn't compelling don't proceed to development, no matter how technically interesting they are. This mechanism is one reason why AWS services are aligned with real-world use cases.

Customer Obsession as the Starting Point for Everything

AWS's customer-driven innovation is rooted in Customer Obsession (obsession with the customer), which is listed at the top of Amazon's Leadership Principles. The principle reads: "Leaders start with the customer and work backwards. They pay attention to competitors, but they obsess over customers." This principle is referenced in every aspect of hiring, evaluation, and decision-making, and is firmly established as organizational culture. Many of the new services announced at re:Invent are concrete solutions born from conversations with specific customers. The reason the story "We heard about problem X from customers and built service Y" is told at announcements is that this process has actually been followed.

How to Write a PR/FAQ Document

At the core of Working Backwards is the method of writing a press release for the finished product and anticipated questions and answers (PR/FAQ) before starting development. The press release describes, from the customer's point of view and without jargon, what the customer will be glad about. In the FAQ, you write out in advance the questions that customers and people inside the company would raise, and prepare the answers. Through this work, you can verify before you start building whether it can really solve the customer's problem and whether its value is clear. The aim of this method is to be able to uncover, at a low-cost stage, the ambiguities and contradictions that only become visible after the idea is put into writing.

The Process for Reflecting Customer Feedback

In customer-driven development, releasing a service is not the end; you continuously collect customer feedback and reflect it in improvements. You gather the requests and complaints of customers who have actually used the service and use them as material for deciding what you should build next. From the many requests, you identify the essential problems they have in common, prioritize them, and build them into development. By running an iterative cycle of releasing small, watching the response, and making repeated improvements, you can grow the service into a form that fits real needs rather than desk-bound imagination. Placing dialogue with customers at the center of development is the key to avoiding off-target feature development.

Applying It to Your Own Development

The Working Backwards way of thinking can also be applied to your own product development, regardless of scale. When you plan a new feature, you begin by trying to write "what will this improve for users?" in a short text from the user's point of view. Rather than starting from the technical means of implementation, you work backwards from the problem you want to solve and the value it will bring. In the process of writing out anticipated questions and preparing answers, you can notice weaknesses in the plan and points you have overlooked. By making a habit of putting value into words and verifying it before you build, you can reduce situations where something you put effort into building goes unused, and raise the hit rate of development.

The Benefits of a Customer-Driven Approach

A culture of developing with the customer as the starting point brings many benefits to an organization. First, you can reduce the waste of building features that nobody wants. Because value is verified in advance, you can concentrate resources on what is really needed. Second, because the criterion for decisions is unified around "what does this mean for the customer," internal discussions become constructive. Third, an attitude of sincerely facing customers' problems leads to long-term trust. Placing the customer's problems, rather than technical possibilities or internal convenience, at the starting point is itself the foundation for creating sustained innovation.

Summary

The fact that 90% of AWS services and features are born from customer feedback is made possible by the mechanisms of Customer Obsession and Working Backwards. PR/FAQ validates customer value before development, and the five-stage process designs products backward from the customer. The reason each service is aligned with real-world use cases despite offering at least 200 services is that this customer-driven approach is deeply embedded as organizational culture.

References (Official AWS Resources)

The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.

If this page and the official documentation disagree, treat the official documentation as authoritative.

Inside AWS Pricing - How Per-Second, Per-Millisecond, and Per-Request Billing Actually WorksDiscover how AWS's diverse billing granularities, including EC2's per-second billing, Lambda's per-millisecond billing, and S3's per-request billing, are measured, aggregated, and invoiced through the metering system.AWS's Culture of Price Reductions - The Flywheel and Economies of Scale Behind 100+ Price Cuts Since 2006This article analyzes AWS's culture of price reductions, which passes the benefits of scale on to customers, and the economies of scale, hardware generation transitions, and competitive strategy behind it. It also introduces major past price reductions and their impact.Why AWS Pricing Is So Complex - The Economics and Game Theory Behind Pay-As-You-GoWe break down the three-tier pricing structure of On-Demand, Reserved Instances, and Spot Instances through the lens of airline yield management and demand forecasting economics, explaining the rational reasons behind the complexity of AWS pricing.Cost Management with AWS Budgets - Budget Alerts and Automated ActionsSet alerts on both actual and forecasted values, and use Budget Actions to automatically apply IAM policies or stop instances. Integrate with Slack to raise cost awareness across the team.Cloud Cost Budget Management - Spending Control and Alerts with AWS BudgetsThis article explains budget settings / cost alerts / automated actions with AWS Budgets. It introduces how to choose between Budgets and Cost Explorer, how to select budget types, and organization-wide budget management through Organizations integration.Why CloudWatch Logs Costs More Than You Expect - The Cost Structure of Ingestion, Storage, and AnalysisThis article explains the pricing structure where CloudWatch Logs ingestion costs over 20 times more than storage, the cost explosions caused by VPC Flow Logs and Lambda logs, and optimization strategies using the Infrequent Access class and S3 export.Resource Optimization with AWS Compute Optimizer - Instance RightsizingAnalyzes CloudWatch metrics with ML and generates recommendations that optimize resource sizes for EC2 / Lambda / EBS / ECS Fargate. This article explains how to use Graviton migration recommendations and improve accuracy with enhanced metrics.Compute Resource Optimization - Rightsizing with AWS Compute OptimizerLearn about resource rightsizing with AWS Compute Optimizer. Covers recommendations for EC2, Lambda, EBS, and ECS on Fargate, cost savings estimates, and implementation steps.