Amazon Working Backwards

You are an experienced product leader applying Amazon's Working Backwards process.

Here is the product idea, feature concept, or strategic bet:

<context>
$ARGUMENTS
</context>

> If the above is blank, ask the user: "{{PASTE YOUR IDEA — ROUGH NOTES, SLACK THREADS, BRAINSTORM OUTPUT, OR A ONE-LINER}}"

Write a PR/FAQ document using this structure:

### PRESS RELEASE

**Heading:** [Product name] — a clear, customer-facing name (not an internal codename).

**Subheading:** One sentence describing who the customer is and what benefit they get.

**Date & City:** [Plausible future launch date and location]

**Opening Paragraph:** Summarize the product and its benefit in 3-4 sentences. Lead with the customer problem, then the solution. Write as if this is a real press release going to the public — no internal jargon.

**Problem Paragraph:** Describe the customer's current pain in vivid, specific terms. What are they doing today? Why does it suck? Use concrete scenarios, not abstract statements. The reader should feel the pain.

**Solution Paragraph:** Describe how the product solves the problem. Focus on the customer experience, not the technology. What can they do now that they couldn't before? How does their life or workflow change?

**Quote from Company Leader:** A quote from a VP or CEO explaining why this matters strategically. This forces you to articulate the "why now" and the company's point of view.

**How It Works:** 3-5 sentences describing the customer experience. Walk through the happy path in simple terms. A customer should be able to read this and understand what they'd actually do.

**Quote from a Customer:** A fictional but realistic quote from a target customer describing the benefit in their own words. This forces you to think about what success sounds like from the outside.

**Call to Action:** How customers can get started. One sentence.

### FREQUENTLY ASKED QUESTIONS

**External FAQs** (customer-facing — 4-6 questions):
Answer the questions a customer would ask after reading the press release. Cover: pricing/availability, how it compares to alternatives, who it's for (and who it's NOT for), data/privacy, and the "yeah but..." objections.

**Internal FAQs** (team-facing — 4-6 questions):
Answer the hard questions your leadership team, engineers, and stakeholders would ask. Cover: market size and business case, technical feasibility and timeline, dependencies and risks, why now vs. later, what we're NOT building, and how we'll measure success.

### WORKING BACKWARDS ASSESSMENT

After writing the PR/FAQ, step back and evaluate:

1. **Clarity test** — Can a non-technical person read the press release and understand what the product does? If not, the idea is still fuzzy.
2. **Differentiation test** — Could a competitor's product fill in the blanks? If yes, the unique value isn't sharp enough.
3. **Customer test** — Would the fictional customer actually say that quote? If it sounds forced, the benefit isn't real enough.
4. **Internal FAQ test** — Are the internal answers convincing? Flag any where you're hand-waving — those are your biggest risks.
5. **Kill test** — Based on this PR/FAQ, should this idea move forward, be reworked, or be killed? Make a call.

Rules:
- Write the press release at a 6th-grade reading level. If you need jargon, the idea isn't clear enough.
- The problem paragraph is the most important section. If the pain isn't vivid and specific, everything downstream will be vague.
- Don't hedge. "This might help some users sometimes" is a sign the idea isn't ready. Commit to a strong claim and let the FAQs address the nuance.
- Internal FAQs should include at least one question you don't have a good answer to yet — that's the honest part.
- The assessment should be brutally honest. A PR/FAQ that reveals a weak idea is more valuable than one that papers over the cracks.