Working Backwards: How Every Product Manager Can Start from the Customer
Working Backwards is a product development framework pioneered at Amazon where a product manager begins by writing a mock press release describing the finished product from the customer's perspective. The team then works backwards from that ideal experience to define requirements, surface risks, and build only what's needed. It replaces speculative roadmaps with a forcing function for customer-centric clarity before any code is written.
Overview
Working Backwards is a product development philosophy that inverts the typical build sequence. Instead of starting with a technology capability or business objective and searching for a customer problem it might solve, a product manager begins by describing the ideal end-state customer experience, then reasons backwards through what must be true for that experience to exist. The method's signature artifact is the PR/FAQ: a one-page mock press release announcing the product as if it were already launched, paired with a detailed FAQ addressing both customer questions and internal stakeholder concerns. Jeff Bezos and early Amazon leadership teams developed this approach in the early 2000s as a direct response to a failure mode they kept observing: teams would invest months engineering a solution, only to discover it solved a problem customers didn't actually have, or solved it in a way customers didn't value. The press release format was chosen deliberately because it forces concreteness. You cannot write a convincing announcement for a product that has no clear customer benefit, and you cannot hide behind vague strategy language when you're writing for an imaginary newspaper reader. Colin Bryar and Bill Carr, both long-tenured Amazon executives, documented the method extensively in their 2021 book "Working Backwards: Insights, Stories, and Secrets from Inside Amazon," giving outsiders the first detailed look at how the process actually runs internally.
The underlying mental model is deceptively simple: if you can't write a compelling press release about a product, you don't understand the product well enough to build it. This claim goes deeper than it first appears. It asserts that written narrative is a superior medium for testing ideas compared to slide decks, wireframes, or verbal pitches. A slide deck lets you gloss over logical gaps with bullet points. A narrative forces you to connect ideas into a coherent story, and gaps become immediately visible. Amazon famously banned PowerPoint in product meetings, replacing it with six-page narrative memos, and the PR/FAQ is the most structured expression of that writing-first culture.
Working Backwards sits in contrast to several other product frameworks. Lean Startup's build-measure-learn loop encourages rapid experimentation with MVPs, assuming you'll learn what customers want through iteration. Working Backwards argues that many costly pivots can be avoided by doing the hard thinking upfront, before any building begins. Design Thinking shares Working Backwards' empathy for the customer but focuses more on divergent exploration and prototyping. Working Backwards is more convergent: it asks you to commit to a specific customer narrative and then stress-test it through critique. Jobs-to-be-Done theory provides a complementary lens for understanding customer motivation, but it doesn't prescribe a specific artifact or decision-making process the way Working Backwards does with the PR/FAQ.
Since its origins at Amazon, the method has been adopted and adapted well beyond Seattle. Stripe, Twilio, and other developer-focused companies have adopted variations of the press release exercise. Product teams at startups use lightweight versions with a one-paragraph press release and a handful of FAQ questions to test ideas in a single afternoon. The core insight, that forcing yourself to articulate the customer's experience before you design the solution, has proven durable across industries, team sizes, and product types. The method works best when a product manager is facing genuine ambiguity about what to build, not when the solution is already well-understood and the challenge is execution. It rewards intellectual honesty, comfort with rewriting, and a willingness to kill ideas that sound exciting internally but produce unconvincing press releases.
For product managers specifically, Working Backwards provides something rare: a structured process for the fuzziest phase of product work, the moment before you commit to building. Most frameworks focus on prioritization (RICE, ICE), delivery (Scrum, Kanban), or validation (Lean Startup). Working Backwards focuses on the decision to pursue an idea at all, and it gives the product manager a concrete artifact to rally alignment around. Teams using Hamster can run the full PR/FAQ workflow with AI agents that help draft, critique, and iterate these documents before a single line of code is written.
How It Works
Step 1: Identify the specific customer problem
Before writing anything, clearly articulate who the customer is and what problem they face today. Be specific: 'marketing managers at mid-size e-commerce companies who spend 6+ hours per week manually compiling performance reports from five different analytics tools' is useful. 'Businesses that want better analytics' is not. Talk to actual customers or review support tickets, forum posts, and sales call recordings to ground this in reality rather than assumption. You've done this step well when you can describe the customer's current pain in their own words, with enough specificity that a stranger could identify whether a given person matches the description. A common mistake is defining the customer too broadly ('everyone who uses the internet') because it makes the subsequent press release impossibly vague.
Step 2: Draft the mock press release
Write a one-page press release announcing the finished product as if it has already launched. The structure follows a standard press release format: a headline that names the customer benefit, a subheadline summarizing the product, a dateline, a problem paragraph, a solution paragraph, a quote from a company leader, a description of how the product works, a quote from a customer, and a call to action. Write it in plain, jargon-free language that a customer could understand. '). Resist the temptation to list features. Focus on the experience and the outcome. This draft will feel rough, and that's expected. The value emerges through revision, not through getting it right the first time.
Step 3: Write the external FAQ
List five to ten questions a customer would ask after reading the press release. These should include pricing, availability, compatibility, migration from existing solutions, data privacy, and support. Answer each one directly and honestly. If you don't know the answer, write 'TBD' and flag it as a risk, because each TBD represents an unresolved decision that will eventually need resolution. The external FAQ tests whether you've thought through the customer's full decision journey, not just the moment of first excitement. You know this section is done when a skeptical customer reading it would have no major unanswered concerns. A common variation is to segment FAQs by customer persona if the product serves multiple audiences with different concerns.
Step 4: Write the internal FAQ
This section addresses the questions your internal stakeholders will raise: engineering feasibility, cost projections, timeline, legal and compliance risks, competitive response, cannibalization of existing products, and organizational capability gaps. The internal FAQ is often longer and more detailed than the external FAQ because it's doing the heaviest analytical work. Each answer should include evidence or reasoning, not just assertions. 'We believe this is technically feasible' is weak. 'The core technology exists in our recommendation engine; the primary new work is the API layer, estimated at 6-8 engineer-weeks based on a spike completed in Q3' is strong. This step is where many weak ideas die, and that's by design. Watch for the temptation to downplay risks in order to keep the idea alive.
Step 5: Circulate for written critique
Share the complete PR/FAQ document with a cross-functional group: engineering leads, designers, finance, marketing, legal, and senior leadership as appropriate. Ask reviewers to read the document in full before the review meeting and to prepare written feedback. At Amazon, review meetings begin with silent reading, even if the document was pre-circulated, to ensure everyone has the full context before discussion. Written critique is superior to verbal critique because it forces reviewers to commit to specific observations and prevents the loudest voice from dominating. You know this step is working when reviewers surface assumptions you hadn't considered and ask questions your FAQ doesn't yet answer.
Step 6: Revise based on feedback
Rewrite the PR/FAQ incorporating the strongest critiques. This is not a cosmetic editing pass. Substantive feedback should change the scope, the customer definition, the stated benefits, or even the fundamental premise of the product. Expect to go through three to five revision cycles for significant initiatives. Each cycle should result in a tighter, more honest, more specific document. The most common failure here is treating critique as adversarial rather than collaborative. If a reviewer exposes a fatal flaw in the customer narrative, that's a success for the process, even though it feels like a setback. Stop revising when new review sessions produce minor refinements rather than structural changes.
Step 7: Make the go/no-go decision
Present the final PR/FAQ to the decision-makers who can approve resourcing. The document itself is the primary input to the decision, not a supplementary deck or a verbal summary. Decision-makers should be able to approve, reject, or request further iteration based on the document alone. If the decision is 'go,' the PR/FAQ becomes the north star for the project: design decisions, scope negotiations, and launch criteria all reference back to the customer experience described in the press release. If the decision is 'no-go,' archive the document. Many good ideas are simply not the right idea at the right time, and a well-written PR/FAQ that was rejected can be revisited when circumstances change.
When to Use
- When your team has multiple potential product directions and no shared clarity about which one will create the most customer value. The PR/FAQ forces each option into a concrete narrative that stakeholders can compare side-by-side, which is far more effective than debating abstract strategies in meetings.
- When you're building a net-new product or entering a new market where you don't have existing usage data to guide decisions. Without behavioral signals to analyze, the Working Backwards process substitutes rigorous upfront thinking about the customer experience for the metrics you don't yet have.
- When your organization suffers from 'solution-first' culture, where engineering or leadership regularly shows up with technology ideas and expects the product manager to find a customer problem for them. The PR/FAQ gives the product manager a structured, respected mechanism to redirect the conversation toward customer outcomes.
- When a product initiative requires significant cross-functional investment (engineering, design, marketing, legal, partnerships) and alignment failures during development would be extremely costly. The PR/FAQ serves as a single artifact that every function can react to before resources are committed.
- When you're a product manager preparing to pitch an initiative to senior leadership and need a document format that communicates customer value, addresses risks, and demonstrates thorough thinking in a compact package. The PR/FAQ is purpose-built for this kind of high-stakes internal communication.
When Not to Use
- When the problem and solution are both well-understood and the primary challenge is execution speed. For incremental improvements, bug fixes, or known feature gaps where customers are explicitly requesting a specific capability, the overhead of a full PR/FAQ process adds friction without adding insight. The method's value comes from resolving ambiguity, and when ambiguity is low, it becomes bureaucracy.
- When you need rapid experimentation to discover what customers want through observed behavior rather than imagined scenarios. If you're in an early-stage startup running daily experiments with a handful of users, the build-measure-learn loop will teach you things that no amount of narrative writing can anticipate. Working Backwards assumes you have enough customer understanding to write a credible press release, and sometimes you simply don't yet.
- When your organization lacks the cultural willingness to kill ideas based on weak documents. If leadership will override the PR/FAQ process and greenlight pet projects regardless of the narrative quality, the method becomes theater. Teams go through the motions of writing press releases for ideas that were never at risk of being rejected, which wastes time and erodes trust in the process.
- When the product is a platform or infrastructure component whose value is indirect and difficult to express in customer-facing language. A press release announcing a new internal data pipeline or a refactored API gateway will read awkwardly because the 'customer' is another engineering team, and the 'benefit' is reduced latency or improved reliability. These are real and important, but the PR/FAQ format distorts more than it clarifies in this context.
- When your team is smaller than three people and communication overhead is near zero. The PR/FAQ's primary function is to create alignment across people with different mental models. If your entire team is two engineers and a designer sitting next to each other, a whiteboard conversation may achieve the same clarity in twenty minutes that a PR/FAQ achieves in two days.
Examples
Example: B2B SaaS team evaluating a new analytics dashboard product
A 30-person SaaS company serving e-commerce brands had been fielding requests for a standalone analytics product from existing customers. ' During the internal FAQ, the engineering lead identified that real-time data ingestion from 12 different ad platforms would require 4 additional engineers for 6 months, far exceeding the team's capacity. The finance lead pointed out that the addressable market at the proposed $99/month price point would take 3 years to reach break-even. After two revision cycles, the team narrowed the scope to a reporting add-on for their existing product at $29/month, which required only 2 engineers for 8 weeks. The scoped-down version launched and reached profitability in 4 months. The product manager later reflected that without the internal FAQ, they would have committed to the larger vision and burned through runway before discovering the unit economics didn't work.
Example: Startup founder testing a consumer mobile app concept
A solo founder considering a meal-planning app for busy parents spent one afternoon writing a mini PR/FAQ. ' Her initial differentiator, AI-powered suggestions, was already offered by three competitors. She revised the press release three times over two days, each time trying a different angle. On the third attempt, she found her hook: integration with local grocery store inventory so every suggested meal could be made with ingredients available for same-day pickup. This specificity changed the entire product scope and go-to-market strategy. She later said the PR/FAQ saved her from building 'yet another meal planner' and gave her a story investors could immediately understand.
Example: Enterprise platform team deciding between two infrastructure investments
A platform engineering team at a 500-person fintech company had budget for one major investment: either a new developer portal to improve internal API discoverability, or a self-service data pipeline tool for analysts. The VP of Engineering asked each project's sponsor to write a PR/FAQ. The developer portal PR/FAQ was compelling but vague on measurable outcomes, stating 'developers will find APIs faster' without quantifying current search time or expected improvement. ' During the joint review session, leadership approved the data pipeline project because its press release told a clearer customer story with measurable impact. The developer portal sponsor was asked to revise and resubmit with concrete metrics. Six months later, the data pipeline tool had reduced engineering support tickets by 40%, closely matching the PR/FAQ's projections.
Example: Growth-stage startup using Working Backwards for international expansion
A 120-person project management SaaS company was debating whether to localize their product for the Japanese market. ' The external FAQ revealed that the team had no answers for three critical questions: how the product would handle Japanese business calendar conventions, whether the existing permission model supported the hierarchical approval workflows common in Japanese companies, and what the customer support model would be across time zones. The internal FAQ estimated localization at $800K and 9 months with no existing partnerships or distribution channels in Japan. After two review cycles, the team decided to instead pursue German localization, where they already had 200 organic sign-ups, a partnership lead with a German consulting firm, and fewer product adaptation requirements. The PR/FAQ process turned a 'which country feels exciting' conversation into a 'which country has the strongest evidence of customer pull' decision.
Skills in This Method
Iterating PR/FAQ Documents Through Multiple Feedback Cycles
How to revise and strengthen a PR/FAQ document through successive rounds of leadership and cross-functional feedback, knowing when the document is ready to greenlight development.
Drafting the FAQ Section of a PR/FAQ Document
How to write both external (customer-facing) and internal (stakeholder-facing) FAQs that stress-test assumptions, address risks, and surface hard questions early in the product process.
Running PR/FAQ Review and Critique Sessions
How to facilitate Amazon-style narrative review meetings where stakeholders silently read the PR/FAQ document and then provide rigorous, structured feedback to sharpen the product concept.
Identifying Minimum Requirements by Working Backwards from Launch
How to use the Working Backwards process to ruthlessly scope down to the minimum set of technology, infrastructure, and features needed for a viable customer experience.
Using Working Backwards Thinking in Product Manager Interviews
How to apply customer-obsessed, Working Backwards reasoning to answer product sense, strategy, and prioritization questions in product manager interviews.
Writing Internal Press Releases for Product Concepts
How to craft a compelling, customer-centric internal press release that articulates the product vision, target customer, problem, and solution before any development begins.
Defining the Desired Customer Experience Before Building
How to start from the ideal end-state customer experience and systematically work backwards to identify the features, services, and technology required to deliver it.