Rigorous Problem Identification
Taken from Bill Carr's book - “Working Backwards: Insights, Stories, and Secrets from Inside Amazon”
At Amazon, teams often spend months working on a single paragraph of the PR/FAQ for a new product idea. This was the “problem paragraph”. Done well, it could lead to a successful product. Done wrong, it will lead to failure. Here is how to write a successful problem paragraph:
The “problem paragraph” defines the customer problem you’re solving. Without this, you will build a product that doesn’t address a customer pain point. It shows whether you truly understand your customer’s needs, not just your company’s capabilities.
To write this paragraph, start by precisely identifying the customer segment that will be served by your product. Great products are built for specific people with specific needs. For instance, designing a car for single urban professionals under 35 differs significantly from designing for suburban families with three kids and a dog.
If you think your product is for everyone, you’re mistaken.
A strong way to begin your paragraph is:
“Today, [customer segment] has [problem], which they currently solve using [methods A, B, and C]…”
Next, quantify the problem: → How large is the segment? (e.g., 17 million households) → What methods do they use? (e.g., 45% use A, 25% use B, 30% use C) → What are the tradeoffs? (e.g., speed, cost, quality)
Here’s an example for a hypothetical robot vacuum product:
“Today, 15 million busy urban and suburban professionals earning between $100,000 and $200,000 struggle to find the time and energy to keep their homes clean. Approximately 30% of these households use traditional vacuuming, which requires up to 2 hours per week. 55% hire a cleaner at a minimum of $50/week, and 15% use robot vacuums that cost $600 plus $100/year in maintenance, while leaving behind up to 30% of dust and dirt.”
This problem paragraph quantifies the customer problem in terms of money, time, and other metrics where possible (in this case, the dust and dirt left behind). The problem should always be quantified; otherwise, how can you assess the potential value of a product that solves it?
Well-defined customer problems are built on data-based insights. Insights are gleaned from swimming in data and metrics. This includes customer usage metrics, process or operations metrics, user interviews, demographic data, customer feedback, customer support data and anecdotes. The more data-based and specific your insight, the more accurate and helpful your problem paragraph will be. This is why the process can take months. However, distilling these quantified insights into a single paragraph gives you the best chance at building a truly useful product.
At Amazon, this paragraph was always the most debated section in a PR/FAQ. This is because getting the problem wrong is the worst mistake you can make in building a product. Everywhere else, you can pivot. But if the problem is incorrectly diagnosed, nothing else matters.
Today, many teams default to solution-centric approaches because rigorous problem identification is hard work. It requires swimming in data, talking to customers, and spending months on a single paragraph. But skipping this step means building features in search of problems, rather than solutions for well-understood customer pain points. The discipline may be difficult, but the alternative is worse: building products nobody needs.