What is a PR-FAQ?
Amazon invented the PR-FAQ (Press Release + Frequently Asked Questions) as a forcing function for product thinking. Before any team writes a line of code, they write a press release as if the product had already shipped — describing it from the customer's perspective, not the builder's.
The FAQ section answers the hardest questions your team and your customers would ask. If you can't answer them before building, you're not ready.
It sounds simple. It's actually brutal. Most ideas fall apart when you try to write the customer quote. That's the point.
In AI-native development, the PR-FAQ is even more valuable — because the tool will happily generate whatever you describe. If your description is vague, your prototype will be vague. Spec-driven development starts here.
Press Release
Each section below is a copy-able template. Click "Show filled-in example" to see what a real one looks like.
[One sentence. What did you just launch? Use present tense, as if the product exists today. Write it for a journalist, not a VP.]
[One sentence. Expand the headline with one specific outcome or benefit. Concrete language, not marketing speak.]
[3-4 sentences. Describe the customer's pain before your product existed. Be specific about who feels it and what they currently do to cope.]
[3-4 sentences. How your product solves the problem. Be concrete about the mechanics, not abstract about the vision.]
[2-3 sentences. A real person saying what they couldn't do before, and what they can do now. Use a realistic name and role. No superlatives. No "game-changer." Just the outcome.]
[2-3 sentences. A quote from you or a leader on your team, explaining why you built this. Connect it to the customer problem — not the technology.]
[1-2 sentences. How they get started. Make it concrete.]
Internal FAQ
These are the questions your team should be able to answer before you build anything. If you can't answer them, you're not ready.
- WHO IS THE CUSTOMER, SPECIFICALLY?
Not "everyone who builds products." A specific person with a specific job and a specific pain. - WHAT IS THE DURABLE NEED?
The thing that would still be true in 10 years. Not the solution trend — the underlying need. - WHAT HAPPENS IF WE DON'T BUILD THIS?
Is this a must-have or a nice-to-have? Would the customer hire a competitor? Build it themselves? Live with it? - WHAT WILL WE *NOT* BUILD?
Scope discipline. What are we explicitly choosing to leave out of v1, and why? - HOW WILL WE KNOW IT'S WORKING?
One or two concrete success metrics. Usage, retention, referral, outcome. Pick what matters. - WHAT'S THE RISKIEST ASSUMPTION?
The thing that, if wrong, kills the product. Name it plainly. This becomes the first thing you test. - WHY NOW?
What changed in the world (tech, market, behavior) that makes this the right time to build this?
External FAQ
These are the questions a customer would ask in their first 30 seconds of reading the press release. Answer them directly and concretely.
- HOW IS THIS DIFFERENT FROM [OBVIOUS ALTERNATIVE]?
Compare to the thing the customer is already using, not to an idealized competitor. Be specific about the difference that matters. - HOW MUCH DOES IT COST?
Including "free" as an answer. Clarity over cleverness. - DO I NEED TO BE TECHNICAL TO USE IT?
The honest answer, not the marketing answer. - WHAT DOES IT INTEGRATE WITH?
Or: what do I give up by choosing this? - WHAT HAPPENS TO MY DATA?
Privacy, ownership, portability. Answer plainly. - HOW DO I GET STARTED?
The exact first action. URL, download, account creation.
How to use this in an AI coding tool
Don't paste the blank template into Kiro or Claude. Fill it in first, then paste the completed PR-FAQ as context for your spec generation.
Good prompt pattern:
Here is the PR-FAQ for the product I want to build.
[paste the filled-in PR-FAQ]
Based on this, generate:
1. A requirements document in EARS format covering the
minimum viable version
2. A proposed architecture
3. A task breakdown for the first 4 hours of build time
Do not invent features that aren't in the PR-FAQ. If something
is missing or ambiguous, ask me before proceeding.The last sentence matters. It turns the AI tool from an enthusiastic generator into a collaborator that pushes back.
Common mistakes to avoid
| Mistake | Why it kills the spec |
|---|---|
| Vague customer ("product people") | The AI tool will generate a vague spec. Garbage in, garbage out. |
| Feature list in the solution paragraph | The solution is an outcome, not a spec. Save features for the spec itself. |
| Aspirational quotes ("game-changer!") | No real customer talks like that. If you can't imagine it, the value prop isn't real. |
| Skipping the Problem paragraph | If you can't articulate the pain, you're building a solution looking for a problem. |
| Forgetting "what we will NOT build" | Scope creep starts before you write a single line of code. |
Use this template freely. Share it. Adapt it. If it helps you ship something, tag @ajbubb on LinkedIn.