Why the Best Product Teams Work Backwards From the Customer
Amazon’s “working backwards” product development philosophy — starting with the customer experience and working backwards to the technology, rather than starting with available technology and working towards a customer experience — has become one of the most influential product development frameworks in the industry. But “working backwards” describes more than a specific technique; it describes a consistent product development orientation that the most customer-centric product teams maintain across all their practices.
Working backwards isn’t a process to implement once; it’s a lens applied continuously to product decisions. And it’s harder to practice consistently than it sounds.
What Working Backwards Means in Practice
Working backwards starts with a specific, vivid picture of the customer experience the team wants to create — not “improved workflow efficiency” but “a user who finishes her weekly data reconciliation in 20 minutes instead of three hours, confidently knowing the numbers are accurate without manually checking each one.”
From this specific outcome, the team works backwards to define what the product must do to create that outcome, what technical capabilities are required, and what development investments are needed. The path goes: desired customer outcome → required product experience → necessary technical capabilities → development roadmap.
This reverses the conventional direction: available capabilities → product features → hoped-for customer outcomes.
Why the Direction Matters
The conventional direction — capabilities to features to hoped-for outcomes — consistently produces products that are technically excellent but fail to create the intended customer value. Features are built based on what’s possible and what sounds valuable, rather than based on working backwards from what would actually change customer behavior.
The working-backwards direction — outcomes to experience to capabilities to roadmap — keeps customer value as the constant anchor. Every development decision is evaluated against its contribution to the specific, vivid customer outcome the team has defined. Features that don’t contribute to that outcome don’t get built; features that do get built even when they’re technically challenging.
The Amazon Press Release Technique
Amazon’s most visible implementation of working backwards is the internal press release technique: before beginning development, the team writes a press release announcing the finished product as if it were being released today. The press release must describe the product in terms of the customer benefit it delivers, the specific problem it solves, and why the customer would be excited about it.
If the team can’t write a compelling press release — if the product doesn’t have a clear customer benefit to announce — the product isn’t ready to be built.
Applying Working Backwards Beyond Amazon
The working backwards orientation applies whether or not a team uses the press release technique specifically. It shows up in:
- Starting roadmap items with the user outcome rather than the feature name
- Writing acceptance criteria in terms of user behavior enabled rather than functionality implemented
- Measuring success by user outcome achieved rather than feature shipped
- Using user research to validate the outcome assumption before the solution assumption
Key Takeaways
Working backwards from the customer is the discipline of maintaining customer value as the constant reference point for product decisions — rather than allowing technology availability, engineering preference, or stakeholder requests to drive development toward features that may or may not create genuine customer value. Teams that maintain this orientation consistently produce products that customers adopt, use, and recommend with more enthusiasm than those that build from capability toward hoped-for outcomes.