What Is a PRFAQ? Amazon's Working Backwards Method Explained

PRFAQ means Press Release and Frequently Asked Questions. In Amazon’s Working Backwards method, a team writes a future customer-facing press release and an FAQ before product development to test who the customer is, what problem matters, what outcome the product should deliver, and which assumptions or risks still need evidence. AWS says Amazon product teams write the press release before requesting a budget, assembling a team, or writing code. The FAQ then covers customer questions and internal questions that affect the decision. This page explains those public facts without implying Amazon endorsement or reproducing an internal template.

​

The three parts of a PRFAQ

AWS’s product-management account of Working Backwards describes a one-page press release followed by an FAQ whose first half covers customer questions and whose second half covers internal questions. The exact section names and formatting used by other teams vary.

​

What the future press release does

The future press release states the desired launch as though the product already exists. It forces the author to name a customer, a problem, a useful outcome, and a believable path to value in language a customer can understand. It is not a real announcement and should not become unsupported sales copy. Every claim about the problem, demand, behavior change, price, or reliability creates a question that the FAQs must answer with evidence or mark as unresolved. AWS says the press release comes before budget, staffing, or code and must fit on one page. Its purpose is to simplify and focus the idea for the end customer. An AWS account of the Cloud Development Kit also says Amazon uses the PRFAQ mechanism to work backwards from customer needs when creating products and services.

​

Customer FAQs versus internal FAQs

Customer FAQs stay in the future customer’s language. They should cover the questions that would affect adoption or trust, such as use, value, price, privacy, security, reliability, compatibility, support, and recovery. Internal FAQs test the idea against current reality. They should cover evidence, alternatives, costs, staffing, technical uncertainty, operational load, legal or security constraints, measurement, and conditions that would stop or narrow the work. Do not move every difficult customer question into the internal section. A customer still needs an answer about data handling or failure behavior. The internal FAQ can then explain what the team must prove or build to make that customer answer true.

​

The writing and review cycle

1. Gather customer evidence before writing the future outcome. Use interviews, observed behavior, support records, usage data, experiments, and current alternatives.
2. Draft the press release in customer language. Keep the idea narrow enough that a reader can identify the customer, problem, outcome, and first use.
3. Write the customer FAQs. Treat each unclear or unsupported answer as a research question, not a reason to add vague confidence.
4. Write the internal FAQs. State the riskiest assumptions, feasibility gaps, costs, dependencies, alternatives, and stop conditions.
5. Review the document with the functions that own those claims. Ask for comments on exact text and record unanswered questions.
6. Revise the document and the supporting research. Proceed, narrow, revise, or park the idea when the evidence supports that decision.

Official AWS guidance says teams share these documents internally for perspective and use continuing customer feedback during development. The more detailed cycle of multiple drafts, cross-functional reviews, silent reading, discussion, and another revision is described by the Working Backwards guide written by former Amazon practitioners. Those meeting details are a practitioner convention, not a requirement for every team that uses a PRFAQ.

​

Evidence a reviewer should demand

A reviewer should be able to trace every material number and future claim to evidence, an owner, or an explicit test. An unanswered question can remain in a draft. A confident answer with no support is harder to review.

​

When to move beyond the PRFAQ

Proceed when the customer and problem are clear, the future outcome is useful, the major assumptions have evidence or bounded tests, and no known feasibility, security, legal, or business issue makes the promise false. The PRFAQ can still contain open questions if their owners and decision paths are explicit. AWS Prescriptive Guidance says teams can plan epics or user stories from the PRFAQ and target customer journey. Plannotator’s document boundaries are practical editorial guidance rather than universal Amazon terminology. Use the complete PRFAQ template and fictional example, then move accepted product intent into the PRD template. The PRD, technical specification, and implementation plan comparison explains the later documents.

​

Where PRFAQ practices vary

The public core is stable: start from the customer, write a future press release, answer customer and internal questions, review the idea, and do this before product development. Other details vary by team and source. Marcelo Calbucci’s PRFAQ 101 is another practitioner framework. It explicitly separates the press release, customer FAQs, internal FAQs, and an optional appendix, and says a PRFAQ precedes rather than replaces a PRD. Its page limits and formatting rules belong to that framework, not to an official Amazon standard.

​

Sources and independence

Primary Amazon and AWS sources used here are The Secrets to AWS Product Management, AWS Well-Architected guidance on customer needs, the AWS product strategy guide, and the AWS CDK Working Backwards account. Practitioner conventions are labeled and linked separately. Amazon, AWS, Working Backwards, and the PRFAQ Framework are named for identification. Plannotator is not affiliated with or endorsed by Amazon, AWS, Working Backwards, or PRFAQ Lab. Reviewed July 19, 2026. Researched and maintained by the Plannotator documentation team.