TL;DR
Working Backwards is Amazon's product development discipline: write the customer-facing press release and FAQ before any design or code work begins. If you cannot write a compelling one-page press release, the idea is not ready to build. The method inverts the typical sequence. Instead of building first and messaging later, you define the desired customer outcome first, then figure out what must be true to make that announcement real.
What Is Working Backwards?
Working Backwards is a product development method pioneered at Amazon during Jeff Bezos's tenure. Ian McAllister, a former Amazon director, brought it to wider attention through a 2012 Quora post that circulated widely across the product management community.
The output is a PR/FAQ: a simulated press release written as if the product has already shipped, plus an FAQ section that handles the hard questions customers, journalists, and internal skeptics will raise. The document is typically one to two pages. Amazon enforces this length deliberately. A document that cannot fit in two pages is a sign of unclear thinking.
Amazon applied this method before building Kindle, Amazon Prime, AWS, and Alexa. Teams that struggled to write a crisp press release were redirected to sharpen the idea. The friction is the point. If the value proposition is genuinely clear, a one-page press release should be straightforward to write.
The method inverts the standard product development sequence. Most teams start with technical feasibility, move to design, and figure out customer messaging last. Working Backwards starts with the customer announcement and works backward to determine what needs to be built to make that announcement true.
The PR/FAQ Structure
A PR/FAQ document has two distinct parts: the simulated press release and the FAQ. Both are written before development begins.
Headline. One sentence. Product name plus the customer benefit. Write it as if it will appear in a technology publication on launch day. Avoid internal product names and abbreviations.
Subheading. Two to three sentences. Who is this for, what does it do, and what is the single most important outcome. No jargon. If someone outside the industry cannot understand it, rewrite it.
Summary paragraph. Dateline, product name, the problem it solves, and the high-level solution. Written in past tense as if the launch just happened.
Problem paragraph. Describe the customer's current situation in specific, vivid terms. Avoid abstractions. "PMs at companies with more than 50 engineers spend three hours per week reformatting spreadsheets into slides for stakeholder updates" is specific. "Teams struggle with reporting" is not useful.
Solution paragraph. How the product changes the customer's experience. No feature lists. Focus on the before-and-after. If the problem paragraph is precise, the solution paragraph should feel like a direct answer.
Customer quote. A fictional quote from a customer you would want to see in a news article. If you cannot write a believable customer quote, the value proposition is still unclear.
Executive quote. A quote from a company leader. Explains why the company built this and why now.
Call to action. Where the customer goes next. A URL, a signup link, a waitlist.
FAQ (External). Three to five questions customers or press will ask. Pricing, compatibility, key limitations, and how this differs from existing alternatives.
FAQ (Internal). Three to five questions engineering, finance, legal, or marketing will ask. Build effort, risk, dependencies, and success metrics. These are often harder to write than the press release. That difficulty is informative.
Worked Example
A product team at a B2B SaaS company wants to build an AI critic that reviews product requirement documents before engineering handoff.
IdeaPlan Launches PRD AI Critic: Catch Spec Gaps Before They Reach Engineering
Product managers can now get a structured review of their PRDs in under 60 seconds, reducing back-and-forth with engineering during sprint planning.
San Francisco, May 2026 IdeaPlan today launched PRD AI Critic, a tool that reviews product requirement documents for completeness, ambiguity, and missing edge cases before they reach an engineering team. Product managers at mid-sized SaaS companies report spending an average of four hours per sprint resolving spec questions that should have been answered in the PRD. PRD AI Critic flags those gaps in one pass, with specific callouts and suggested rewrites.
"I used to get five Slack messages during sprint planning asking things the PRD should have covered," said Marcus, a Senior PM at a Series B fintech company. "PRD AI Critic caught three of those gaps before I even shared the doc. The first sprint I used it, we had zero spec clarification requests."
PRD AI Critic is available today for all IdeaPlan Pro subscribers. Users paste or upload their PRD, receive a structured review with a completeness score, flagged sections, and optional rewrites, and can share the reviewed doc directly with their engineering lead. No template required.
FAQ (External)
- Does it work with PRDs in any format? Yes. Paste text directly or upload a document. The tool extracts structure from any format.
- What does it flag? Missing acceptance criteria, ambiguous requirements, undefined edge cases, and sections that contradict each other.
- How is this different from asking ChatGPT to review my PRD? PRD AI Critic uses a structured evaluation rubric tuned for engineering handoff, not general writing quality.
FAQ (Internal)
- What is the engineering estimate? Six weeks for MVP with text input, four additional weeks for document upload.
- What is the success metric? 35% of active Pro subscribers use it at least once in the first 60 days post-launch.
- What is the biggest risk? PRDs vary significantly in format and depth. Quality of output may degrade on poorly structured inputs. Plan to tune on real user documents during beta.
The press release above took roughly 40 minutes to write. It immediately surfaces real questions: What counts as an "ambiguous requirement"? What does a completeness score measure? What formats does document upload support? Those questions should drive the product specification, not emerge during QA.
You can use IdeaPlan's PRD Generator to draft the underlying spec once the press release is approved, and Release Notes Generator to produce the actual launch announcement when the product ships.
When to Use Working Backwards
Working Backwards fits situations where the cost of building the wrong thing is high and the customer value proposition is not yet obvious to everyone in the room.
New product launches. Any initiative that requires dedicated engineering resources for more than one sprint benefits from a press release that forces alignment on what you are actually building.
Major feature launches. When a new capability changes the core user flow or requires onboarding changes, a press release helps stakeholders agree on the customer outcome before design begins.
Pivot decisions. When a team is debating whether to change direction, writing a press release for the proposed new direction makes the argument concrete. If the press release is unconvincing, the pivot may not be ready.
Executive alignment. When multiple senior stakeholders have competing assumptions about what a product does, a press release is a forcing function. It is easier to debate a document than a Jira backlog.
When NOT to Use Working Backwards
The method has overhead. For many situations, that overhead is not justified.
Small incremental improvements. A bug fix, a UX polish pass, or a minor configuration option does not need a press release. The exercise is for decisions where building the wrong thing wastes meaningful resources.
Technical or architectural decisions. Working Backwards is for customer-facing outcomes. A decision about database schema or API design does not have a customer quote.
Execution-only work. If the problem is validated and the team is aligned, additional alignment documents slow things down. Working Backwards is a discovery and alignment tool, not a substitute for getting work done.
Time-critical experiments. When you need to ship a quick validation test and can throw it away, writing a press release first adds friction that does not help.
Common Pitfalls
Writing features instead of outcomes. "Users can export reports in CSV, PDF, and XLSX" is a feature list. "PMs can share formatted progress reports with any stakeholder in under a minute" is an outcome. Press releases that read like spec bullets missed the point of the exercise.
Making the FAQ too easy. The FAQ is not for questions you already know how to answer. It is for the questions that make the team uncomfortable. If every FAQ entry is a single sentence, the document is not finished.
Skipping the narrative meeting. Amazon's review ritual requires attendees to read the document silently for 15 to 20 minutes before discussion begins. No slide decks, no presenter pitching. The document defends itself. Skipping the silent read and presenting the PR/FAQ as a deck produces a worse outcome.
Writing the PR after the decision. Some teams write the press release after building has started or a decision has been made. This produces an artifact that looks like Working Backwards but does none of the alignment work. If the press release was written to justify something already decided, it will not surface hard questions.
Abandoning the artifact post-build. Products evolve. When scope changes significantly, revisit the press release. A press release that no longer matches what is being built is a signal the team has drifted from the original customer commitment.
Working Backwards vs Alternatives
Working Backwards vs Jobs to Be Done. JTBD identifies the underlying customer motivation before any solution exists (input). Working Backwards translates that motivation into a specific, named customer outcome (output). The two methods work well in sequence: run JTBD discovery first to understand what job customers are trying to do, then write the press release to define the concrete outcome that addresses that job.
Working Backwards vs Business Model Canvas. The Business Model Canvas maps revenue streams, customer segments, cost structure, and key partnerships. It answers "Is this a viable business?" Working Backwards answers "Is this a compelling product for a specific customer?" Both are useful. For a new product, write the press release first to confirm customer clarity, then stress-test the business model.
Working Backwards vs Opportunity Solution Tree. An OST maps customer opportunities to candidate solutions and experiments. Working Backwards is a later-stage tool: once an opportunity is identified and a solution direction is chosen, the press release sharpens the specific outcome. Use an OST to explore the opportunity space, then use Working Backwards to commit to one path.
Working Backwards vs Design Sprint. A design sprint tests a prototype with real users in five days. Working Backwards tests the idea with internal stakeholders before any prototype exists. For large bets with high uncertainty, run Working Backwards to force internal alignment, then run a design sprint to validate the riskiest assumption with real users.
Tools That Help
Once the press release is approved and a direction is set, these tools support the next steps.
IdeaPlan's PRD Generator translates the press release into a structured product requirements document. The Working Backwards press release should directly inform the problem statement, customer context, and success criteria sections of the PRD.
Release Notes Generator handles the actual customer-facing announcement when the product ships. Having a press release written in advance makes release notes faster to produce because the core messaging is already done.
IdeaPlan Forge generates a structured product narrative from goals, context, and customer insight. Useful for teams working through the discovery phase before they are ready to write a press release.
Related Frameworks
- Jobs to Be Done: Use JTBD research to validate the customer problem before writing the press release
- Opportunity Solution Tree: Maps customer opportunities to potential solutions after the press release validates the goal
- Business Model Canvas: Stress-test the business model once the press release confirms customer clarity