> ## Documentation Index
> Fetch the complete documentation index at: https://docs.plannotator.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# What Is a PRFAQ? Amazon's Working Backwards Method Explained
> A PRFAQ combines a future press release with customer and internal FAQs. Learn how Amazon's Working Backwards method uses it before product requirements and technical design.
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
| Part | Job | Questions it should answer |
| -------------------- | -------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| Future press release | Describe the proposed launch from the customer's point of view | Who is the customer? What problem changes? Why is the outcome worth choosing? How does the customer start? |
| Customer FAQ | Test the future customer experience | How does it work? What does it cost? What happens when it fails? How are privacy, security, support, and migration handled? |
| Internal FAQ | Test whether the organization should and can pursue the idea | What evidence supports it? What are the risks, costs, dependencies, alternatives, feasibility limits, and success conditions? |
AWS's [product-management account of Working Backwards](https://aws.amazon.com/executive-insights/content/product-management-at-amazon/) 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](https://aws.amazon.com/blogs/opensource/working-backwards-the-story-behind-the-aws-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](https://workingbackwards.com/resources/working-backwards-pr-faq/) 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
| Claim in the PRFAQ | Useful evidence | Review challenge |
| ------------------------------------- | ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| The customer has this problem | Interviews, observed work, usage data, support cases, incident records | Is the sample relevant, and does the evidence show the stated problem rather than a nearby one? |
| The problem is worth solving now | Frequency, severity, cost, delay, abandonment, willingness to change | What happens if the team does nothing for six months? |
| The proposed outcome is better | Prototype use, behavior tests, comparison with current alternatives | Did customers change behavior, or did they only say the idea sounded useful? |
| The customer journey is believable | Task tests, mockups, workflow observation, migration or setup proof | Where does the customer first get value, and where are they likely to stop? |
| The product can be built and operated | Technical spike, dependency proof, security review, cost model, support plan | Which unknown could invalidate the promised experience? |
| The business can sustain it | Price research, unit-cost model, adoption assumptions, staffing needs | Which variable has the greatest effect on viability? |
| The result can be measured | Baseline, metric definition, target, observation window, counter-metric | Could the metric rise while the customer outcome gets worse? |
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.
| Next document | Create it when | What it adds |
| ----------------------------- | ----------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| Product requirements document | The idea has earned continued work and the product boundary needs agreement | Users, journeys, goals, non-goals, observable requirements, acceptance criteria, and success measures |
| Technical specification | The team must define behavior or design that should remain true during and after implementation | Architecture, interfaces, data, failure behavior, security, compatibility, rollout, and verification |
| Implementation plan | The product boundary and enough design are accepted to sequence the current change | Affected systems, ordered work, dependencies, risks, and validation |
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](/templates/prfaq), then move accepted product intent into the [PRD template](/templates/product-requirements-document). The [PRD, technical specification, and implementation plan comparison](/compare/prd-vs-technical-specification-vs-implementation-plan) 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.
| Practice | How to treat it |
| --------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| `PRFAQ`, `PR/FAQ`, or `PR FAQ` spelling | Different spellings of the same document name |
| Exact page count | A useful constraint in some sources, not a universal public Amazon rule |
| Required headings or paragraph order | Template choices that should serve the decision rather than be copied as doctrine |
| Fictional customer or executive quotes | A common way to make the proposed benefit concrete, not evidence that a real customer agrees |
| Silent reading time and meeting format | Review conventions described by practitioners, adaptable to team size and context |
| Appendix contents | Supporting evidence when readers need it, not a place to hide the technical specification or implementation plan |
| Final decision label | Proceed, revise, narrow, or park are clear choices; each organization can name its decision process differently |
Marcelo Calbucci's [PRFAQ 101](https://www.theprfaq.com/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.
Start with copyable Markdown, one complete fictional software example, and reviewer notes for the claims that need evidence.
## Sources and independence
Primary Amazon and AWS sources used here are [The Secrets to AWS Product Management](https://aws.amazon.com/executive-insights/content/product-management-at-amazon/), [AWS Well-Architected guidance on customer needs](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/oa.ti.6-prioritize-customer-needs-to-deliver-optimal-business-outcomes.html), the [AWS product strategy guide](https://docs.aws.amazon.com/pdfs/prescriptive-guidance/latest/strategy-product-development/strategy-product-development.pdf), and the [AWS CDK Working Backwards account](https://aws.amazon.com/blogs/opensource/working-backwards-the-story-behind-the-aws-cloud-development-kit/). 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.*