Writing an Amazon-Style PR/FAQ with AI (Working Backwards)

What Working Backwards actually is

Amazon's Working Backwards method flips the usual build order. Instead of starting with requirements and hoping a good story falls out at launch, you write the launch story first — a press release, as if the product shipped today — then answer the hard questions it raises in an internal FAQ. Only after the PR/FAQ survives scrutiny do you write a PRD and start building.

The point isn't the press-release format. It's that a press release has nowhere to hide. A PRD can bury a weak idea in twelve pages of requirements; a press release needs a headline, a one-paragraph summary, and three genuine customer benefits in the first 200 words. If you can't write that paragraph honestly, you don't have a product yet — you have a feature list.

If the press release is boring to write, the launch will be boring to read. That's the whole diagnostic.

The PR/FAQ structure

A Working Backwards document has two halves, and PMs who skip the second half miss the point entirely:

• The press release (external voice). Headline, sub-headline, a summary paragraph, the problem, the solution, a customer quote, a "how to get started" line. Written for a customer, not your VP.
• The FAQ (internal + external). Internal questions your leadership would actually ask — cost, dependencies, why now, what's the metric, what could kill this. External questions a skeptical customer would ask — pricing, how it's different from existing options, what happens to their data. This half is where most of the thinking happens.

The press release takes twenty minutes to draft. The FAQ is where a good Working Backwards session earns its reputation — and it's also where an AI agent, used correctly, adds the most value: not writing prose, but generating the questions you'd rather not answer yet.

Step 1 — Ground the agent before you draft anything

Same rule as every other artifact: an agent with no context invents a customer, a price, and a market it has never seen. If you've already set up a context/ folder with your product, users, and company files (see how to write a PRD with Claude Code for the fifteen-minute setup), point the agent at it before asking for a press release. If you're starting fresh, do that interview first — a PR/FAQ grounded in nothing is just optimistic fiction with a headline.

Step 2 — Draft the press release, then attack it

Here's a starting prompt you can copy. It asks for both halves and, critically, tells the agent to challenge your inputs rather than flatter them:

Read the files in context/ first.

Write a Working Backwards PR/FAQ for the idea I describe below,
Amazon style. Structure:

PRESS RELEASE (external voice, max 1 page)
- Headline (one sentence, as a customer would read it)
- Sub-headline
- Summary paragraph (what it is, who it's for, the benefit)
- Problem (from the customer's point of view)
- Solution (how this solves it)
- A quote from a hypothetical customer
- A quote from someone on our team
- How to get started

FAQ
- 5 internal questions (cost, dependencies, why now,
  success metric, biggest risk) with honest answers
- 5 external questions a skeptical customer would ask
  (pricing, why not the existing alternative, data/privacy,
  what happens if it doesn't work, when it ships)

Two rules:
1. Ground every claim in my context files. If a metric,
   price, or constraint isn't in context/, ASK me — don't invent it.
2. After drafting, list the 3 weakest claims in the press
   release and explain why a skeptical exec would push back
   on each one.

Idea: [describe the product or feature in 2-3 sentences]

Rule #2 is the part most people skip when they try this with a generic chatbot. A press release that only flatters your idea is useless — the value of Working Backwards is adversarial, and a grounded agent that has read your actual metrics is far better at finding the soft spots than one guessing at a generic B2B SaaS narrative.

What a weak vs. strong answer looks like

The gap between a real Working Backwards session and a rubber-stamp one usually shows up in a single FAQ answer. Take the internal question "why now?" — the one most teams answer with a shrug dressed up as strategy.

• Weak: "Now is the right time because AI is transforming the industry and customers expect this kind of capability." This is true of almost any product at any point in the last two years. It answers nothing and would survive in any PR/FAQ regardless of the idea.
• Strong: "Three of our five largest accounts raised this exact gap in the last two QBRs, and our churn data shows accounts without a workaround are 1.4x more likely to lapse at renewal. Waiting another quarter means at least one more renewal cycle at risk." This is specific, falsifiable, and grounded in something the team actually tracks — the kind of answer a grounded agent can help you sharpen if you feed it real numbers, but can't invent on its own.

Push the agent explicitly for this distinction: "Rewrite each internal FAQ answer twice — once as a generic answer that could apply to any product, once grounded in a specific number or fact from my context files. Flag which one is stronger." That single instruction does more to raise the quality of a PR/FAQ than any amount of formatting polish.

Step 3 — Run the exec pushback pass

Once the FAQ answers exist, don't stop. Ask the agent to role-play the toughest person in your review: "You're a skeptical VP reading this FAQ. Ask three follow-up questions that expose gaps in the internal answers, then tell me honestly whether you'd greenlight this." A good agent will catch the same things a sharp exec catches — a success metric that's really a vanity number, a "why now" that's actually "why not never," a cost estimate with no real basis.

This is the same instinct behind why AI prompt packs fail PMs: a one-shot prompt that spits out a polished document isn't the win. The win is an agent that stays in the loop, keeps pushing, and doesn't let a weak idea slide through because the prose reads well.

Step 4 — Decide, don't just file it

A PR/FAQ has one job: help you decide whether to invest further. After the pushback pass, make an explicit call:

• Kill it. If the FAQ exposed a fatal weakness — no real customer benefit, cost that dwarfs the upside, a "why now" nobody believes — that's a win. You killed a bad bet before it cost engineering time.
• Rework it. If one or two answers are weak but the core idea holds, revise the press release and re-run the pushback pass. Don't rationalize weak answers just because you've already invested time in the doc.
• Move forward. If the press release is honestly compelling and the FAQ survives scrutiny, you now have a validated value proposition — feed it straight into an initiative doc and a PRD, grounded in the same context, so nothing you just learned gets lost in translation.

Where this fits in the bigger workflow

Working Backwards isn't a replacement for a PRD — it's a gate in front of one. The full sequence, if you're using an agent with grounded context, looks like: write the PR/FAQ → frame it as an initiative once it survives pushback → spec the PRD → slice into user stories. Each step reuses the same context files, so the customer benefit you argued for in the press release is still visible by the time an engineer reads the requirements — see how to write user stories with AI for that last step. That connected chain, not any single document, is what agentic product management actually buys you.

Common mistakes to avoid

• Treating the press release as the deliverable. It's a diagnostic tool. The FAQ, and the decision it forces, is the actual output.
• Skipping the pushback pass. A press release nobody challenged is just marketing copy with extra steps. Make the agent argue with you.
• Writing it after the PRD, not before. The entire point is to test the value proposition before requirements exist. Retrofitting a press release onto an already-scoped feature defeats the purpose.
• Letting the agent invent the price or the metric. Those are business judgment calls. If they're not in your context files, answer them yourself — don't let plausible-sounding fiction stand in.

FAQ