> ## 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.
# PRFAQ Template: A Complete Working Backwards Example
> Copy a complete PRFAQ template in Markdown, use a filled fictional software example, and see what reviewers should challenge before a PRD.
A PRFAQ template structures a future press release followed by customer and internal frequently asked questions. Teams use it before a product requirements document (PRD) to test whether a product idea describes a valuable customer outcome, has enough evidence, and can survive questions about feasibility and risk.
Amazon calls this Working Backwards. AWS says its product-development process begins with a Press Release and Frequently Asked Questions document that states the product's customer value before development starts. The [Working Backwards PRFAQ framework guide](/frameworks/amazon-working-backwards-prfaq) explains the method and separates Amazon and AWS facts from later practitioner conventions.
## Copy the PRFAQ template
This Plannotator-authored Markdown template preserves the public core of the method without copying a proprietary Amazon template. Replace every bracketed prompt and delete questions that do not affect the decision.
```md theme={null}
# [Product or initiative] PRFAQ
Status: Draft | In review | Proceed | Revise | Parked
Owner: [Person responsible for the document]
Last updated: [Date]
Decision needed by: [Date]
Evidence reviewed: [Research, usage data, support records, or experiments]
## Future press release
### [Headline that states the customer outcome]
[One-sentence subheadline naming the customer and the benefit.]
**[City], [future launch date]**: [Product or company] today announced
[product or initiative], which helps [specific customer] achieve [outcome].
### Customer problem
[Describe the problem from the customer's point of view. State how customers
handle it today and why the current options fall short. Cite evidence.]
### Product and customer outcome
[Explain what the product does and how the customer's situation changes. Keep
the focus on the result rather than an internal feature list.]
### How it works
[Describe the smallest believable customer journey from starting point to
value. Include the main failure or recovery path when it affects trust.]
### Fictional customer quote
> "[A clearly labeled fictional quote that explains the before-and-after
> experience in the customer's own words.]"
>
> [Fictional customer name and role]
### Availability and getting started
[State who can use it, the expected launch scope, price or access model if
known, and the first action a customer takes.]
## Customer FAQ
### Who is this for?
[Name the customer segment and the context that makes the problem urgent.]
### What problem does it solve?
[Answer in the customer's language and connect the claim to evidence.]
### How does it work?
[Explain the customer-visible workflow without relying on internal jargon.]
### Why would a customer change from the current option?
[Name the current alternatives, switching cost, and specific improvement.]
### What does it cost?
[State the proposed price, pricing basis, or the evidence still needed.]
### How are privacy, security, and reliability handled?
[Answer the customer questions that could block adoption. Do not promise an
unverified control or service level.]
### What happens when it does not work?
[Describe limits, recovery, support, and any safe fallback.]
## Internal FAQ
### What evidence shows this problem is worth solving now?
[Link interviews, observed behavior, usage data, support cases, market data,
or experiments. State the sample and its limits.]
### Which assumptions could make the idea fail?
[List the riskiest customer, usability, business, technical, legal, or
operational assumptions and how the team will test each one.]
### What alternatives did we consider?
[Include the customer's current workaround, doing nothing, and materially
different product approaches. Explain why this proposal is stronger.]
### What is the smallest useful launch scope?
[Name the required customer outcome and the features or segments excluded.]
### What is hardest to build or operate?
[State the main feasibility questions, dependencies, and evidence already
available. Leave detailed design for the technical specification.]
### What must be true for the business to support it?
[State the cost, price, adoption, staffing, and operational assumptions that
affect the decision.]
### How will we measure the customer outcome?
[Define the primary outcome, baseline, target, observation window, and a
counter-metric that would expose harm.]
### What could harm customers or the company?
[Cover material privacy, security, safety, legal, support, reputation, and
operational risks with an owner or evidence path.]
### What would make us stop, revise, or delay?
[Write explicit decision conditions instead of assuming every drafted idea
must be built.]
### What remains unanswered?
[List each open question with an owner and the evidence or date needed.]
## Decision
Decision: Proceed to PRD | Revise and review again | Park
Decision owner: [Person]
Reason: [Evidence-based reason]
Conditions: [Research, prototype, policy, or scope condition]
## Evidence and appendix
- Customer evidence: [links]
- Usage or support evidence: [links]
- Prototype or feasibility evidence: [links]
- Financial or operating model: [links]
- Related decisions: [links]
```
## Complete fictional PRFAQ example
The example below is for **RelayCheck, a fictional software product**. Every company, quote, interview, metric, price, and technical claim is invented to demonstrate the document. None is Plannotator product behavior or market evidence.
```md theme={null}
# RelayCheck PRFAQ
Status: In review
Owner: Maya Chen, fictional product lead
Last updated: 2026-07-19
Decision needed by: 2026-08-07
Evidence reviewed: 14 fictional interviews, nine fictional webhook incidents,
and a six-team fictional prototype cohort
## Future press release
### RelayCheck catches breaking webhook changes before customers do
SaaS platform teams can compare proposed event changes with the contracts their
customers rely on and fix breaking changes before deployment.
**San Francisco, October 15, 2027**: RelayCheck today announced a contract
review service for software teams that publish webhooks. RelayCheck examines a
proposed event-schema change in continuous integration, identifies customer
fields that would break, and returns a report linked to the exact code change.
### Customer problem
SaaS teams often learn that a webhook changed only after a customer's billing,
fulfillment, or reporting process fails. In nine fictional incidents reviewed
for this example, teams had a schema description or release checklist, but the
description had drifted from production events. Engineers then compared logs,
support tickets, and code by hand while customers waited for a fix.
### Product and customer outcome
RelayCheck gives the team one review before deployment. It compares the proposed
JSON event shape with versioned customer contracts, explains which consumers
could be affected, and links each warning to the changed field. Teams can fix a
breaking change, publish a new event version, or record why the change is safe.
### How it works
A team installs the RelayCheck GitHub App or runs the command-line client in its
existing CI job. The team uploads schemas or sanitized example payloads for the
events it wants to protect. On each pull request, RelayCheck reports removed
fields, incompatible type changes, and newly required values. If RelayCheck
cannot infer a safe result, it asks for review instead of blocking deployment.
### Fictional customer quote
> "RelayCheck showed that our small rename would break two customer billing
> jobs. We versioned the event before release instead of explaining an outage."
>
> Priya N., fictional platform engineering manager at Northstar Billing
### Availability and getting started
RelayCheck launches for GitHub-hosted repositories that publish JSON webhooks.
Plans start at a fictional price of $49 per protected service each month. A team
can connect one repository, import one event schema, and run a pull-request
check without routing production webhook traffic through RelayCheck.
## Customer FAQ
### Who is this for?
RelayCheck is for SaaS platform teams whose customers or partners consume JSON
webhooks. It is most useful when several external systems depend on event fields
and a breaking change would cause customer work or support incidents.
### What problem does it solve?
It finds incompatible webhook changes before deployment. It does not replace
runtime monitoring or guarantee that every customer integration is correct.
### How does it work?
RelayCheck stores a versioned contract for each protected event. During CI, it
compares the proposed contract with the current one and comments on the pull
request with the affected fields and consumers. The team can then make the
change compatible, create a new event version, or record a reviewed exception.
### Why would a customer change from the current option?
Teams can keep manual checklists and contract tests. RelayCheck is intended for
teams whose checklists drift and whose tests do not cover external consumers.
Adoption depends on whether its report is more accurate and faster than the
team's current review, which the pilot must prove.
### What does it cost?
The proposed fictional launch price is $49 per protected service each month,
including 1,000 pull-request checks. The pilot tests whether service count is a
clear pricing unit before the price is final.
### How are privacy, security, and reliability handled?
RelayCheck does not need production webhook traffic. Teams can provide schemas
or sanitized examples. The launch design encrypts stored contracts, limits
repository access to selected repositories, records contract changes, and lets
an administrator delete the stored data. These claims require a security review
and failure test before launch.
### What happens when it does not work?
An unavailable or uncertain check reports that it could not reach a decision.
The team can use its existing review and CI process. RelayCheck does not block a
deployment merely because its service is unavailable.
## Internal FAQ
### What evidence shows this problem is worth solving now?
Fourteen fictional interviews covered SaaS teams with 3 to 40 public webhook
events. Nine teams described at least one breaking-change incident in the prior
year. Six provided sanitized schemas for a prototype, and five asked to run it
on a live repository. The sample came from the founders' network, so it does not
yet show demand outside small and midsize SaaS companies.
### Which assumptions could make the idea fail?
The largest assumption is that teams keep contracts current enough for a diff
to help. The second is that RelayCheck can keep false warnings low across real
JSON payloads. The pilot will measure weekly contract updates, reviewed checks,
false warnings, and changes made because of a report.
### What alternatives did we consider?
Teams can use consumer-driven contract tests, hand-maintained schemas, release
checklists, runtime monitoring, or a managed webhook gateway. Contract tests are
strong when every consumer participates. A gateway sees real traffic but adds a
runtime dependency. RelayCheck tests whether a CI-only product can help teams
that cannot require every external customer to run a contract suite.
### What is the smallest useful launch scope?
The launch supports JSON webhook contracts, GitHub pull requests, a command-line
fallback, field removal, incompatible type changes, newly required values, and
reviewed exceptions. It excludes XML, event delivery, payload transformation,
runtime proxying, GitLab, and automatic customer notifications.
### What is hardest to build or operate?
Flexible JSON payloads can make an optional field look required or hide a type
change behind inconsistent examples. The team must define a conservative
comparison model and prove it against the six pilot schema sets. Repository
permissions and data deletion also need tests before the product handles a
customer repository.
### What must be true for the business to support it?
At the proposed price, a protected service must cost less than a fictional $8
per month to operate and support at launch. At least 8 of the first 15 pilot
teams must run checks weekly, and at least 4 must accept the proposed paid plan.
The price, cost ceiling, and conversion threshold are hypotheses.
### How will we measure the customer outcome?
The primary pilot outcome is the share of reviewed pull requests where a team
changes or versions a webhook after a valid RelayCheck finding. The target is at
least 10 such decisions across 15 teams in six weeks. The counter-metric is a
false-warning rate below 5% of reviewed findings. The team will also record
check failures and median review time.
### What could harm customers or the company?
RelayCheck could expose repository metadata, retain sensitive example fields,
or create false confidence when a consumer dependency is missing. The security
owner must approve the permission and deletion model. Product copy and reports
must state that a clean result covers only the contracts supplied to RelayCheck.
### What would make us stop, revise, or delay?
Park the idea if fewer than 8 of 15 pilot teams run it weekly. Revise the schema
model if more than 5% of reviewed findings are false warnings. Delay launch if
the security review cannot confirm repository isolation and complete deletion.
### What remains unanswered?
- Product owner by 2026-07-31: Is protected service count a clear pricing unit?
- Engineering owner by 2026-07-28: Can the comparison model handle the six
pilot schema sets with fewer than 5% false warnings?
- Security owner by 2026-08-04: What repository metadata must be stored?
## Decision
Decision: Proceed to a PRD if the three open questions meet their conditions.
Decision owner: Fictional product director
Reason: The interviews and prototype show a repeated problem, but pricing,
comparison accuracy, and data handling still need bounded proof.
Conditions: Meet the pilot-use threshold, false-warning limit, and security
review before accepting product requirements.
## Evidence and appendix
- Customer evidence: Fictional interview summary, 14 participants
- Incident evidence: Fictional incident review, nine events
- Prototype evidence: Fictional six-schema comparison report
- Financial model: Fictional pilot unit-cost worksheet
- Related decisions: None yet
```
## Reviewer notes on the example
| Example claim | What the reviewer should challenge |
| -------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| Nine teams described a prior incident | Ask how the incidents were selected, what broke, and whether webhook changes caused the failures |
| Five of six prototype teams asked for a live trial | Separate polite interest from installing the product and using it in a real pull request |
| A CI-only check avoids a runtime dependency | Test whether current contracts are complete enough to catch the failures customers care about |
| Fewer than 5% false warnings | Define the denominator, who labels a warning false, and whether missed breakages also need a limit |
| \$49 per protected service | Ask whether customers understand the pricing unit and whether the proposed price covers support and compute |
| Proceed after three conditions | Confirm who records the result and whether a failed condition sends the idea back to research or ends it |
The press release makes the outcome easy to inspect. The customer FAQ tests whether the future experience is clear. The internal FAQ carries the evidence, assumptions, constraints, and stop conditions that prevent the press release from becoming unsupported sales copy.
## PRFAQ versus PRD
| Question | PRFAQ | PRD |
| -------------- | ----------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| Main job | Test a future customer outcome and whether the idea deserves continued work | Define the accepted product problem, scope, requirements, and success measures |
| Typical timing | Before detailed product requirements or technical design | After the product idea has enough evidence and a stable boundary |
| Core contents | Future press release, customer FAQs, internal FAQs, evidence, risks, open questions | Users, journeys, goals, non-goals, observable requirements, acceptance criteria, metrics |
| Exit | Proceed, revise, or park the idea | Begin or update technical design and implementation planning |
A PRFAQ does not replace a PRD. If review shows a clear customer, credible problem evidence, a useful outcome, and no fatal feasibility or business gap, move the accepted boundary into a PRD. Use the [product requirements document template](/templates/product-requirements-document) for that next document.
## Review this in Plannotator
Save the copied template as `prfaq.md`, then open the existing Markdown for comment and editing:
```bash theme={null}
plannotator annotate prfaq.md
```
Follow the current document-review workflow for local Markdown, URLs, or folders.
Plannotator reviews the document you provide. It does not generate a PRFAQ. Use [Plannotator Workspaces](/workspaces/review-plans-and-technical-decisions) when several people and agents need to annotate, edit, and version the same planning document.
## Sources and reuse notes
AWS describes the Amazon process in [The Secrets to AWS Product Management](https://aws.amazon.com/executive-insights/content/product-management-at-amazon/): a one-page future press release comes before budget, team assembly, or code, and the FAQ covers customer questions followed by internal questions. The [AWS Well-Architected guidance](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/oa.ti.6-prioritize-customer-needs-to-deliver-optimal-business-outcomes.html) says development begins with a PRFAQ and recommends customer research, internal review, and a continuing feedback loop. The [AWS product strategy guide](https://docs.aws.amazon.com/pdfs/prescriptive-guidance/latest/strategy-product-development/strategy-product-development.pdf) places epics or user stories after the PRFAQ and customer journey.
The detailed draft and meeting practices in the [Working Backwards PR/FAQ guide](https://workingbackwards.com/resources/working-backwards-pr-faq/) come from former Amazon practitioners and are not an official universal Amazon template. This page uses those practices as labeled context, not as requirements. Amazon, AWS, and Working Backwards are named for identification. Plannotator is not affiliated with or endorsed by Amazon or AWS.
*Reviewed July 19, 2026. Written and maintained by the Plannotator documentation team.*