press-release

name	press-release
description	Writes the Amazon-style working-backwards press release and FAQ for a product or feature before it's built. Use when a PM says "write the press release", "PR/FAQ", "working backwards doc", "let's write the launch announcement first", "what would we say when this ships", or wants to pressure-test whether an idea is worth building by trying to make it sound compelling to a customer.
tier	guided
time	45-60 min
inputs	the idea, who it's for, and what they can do after it exists that they couldn't before
outputs	projects/<project>/press-release.md

Press Release (Working Backwards)

Writes the announcement first, as if the thing already shipped, then the FAQ that survives a skeptical room. The output is a decision instrument, not marketing copy: if you cannot write a compelling press release, that is the finding.

Grounded in: Working Backwards — Colin Bryar & Bill Carr: start from the customer announcement and the FAQ, and let a weak press release kill a weak idea before it consumes a roadmap. The rule that does the work is the constraint — one page, customer language, no internal jargon, benefits stated as what the customer can now do.

When to use this

• At the start of a significant bet, before a spec exists and before engineering estimates anchor the conversation.
• When a proposal keeps getting described in internal terms and nobody can say what changes for a customer.
• To force a decision between three competing ideas — write all three, and the weak ones become obvious.
• Before a roadmap review where you need one page an exec can read cold.
• When an idea feels exciting but you suspect the excitement is internal, not customer-side.

Before you start (gather these)

• The customer — a specific segment or role, not "users". The press release is written to them.
• What they can do afterwards that they can't today — stated as a capability, not a feature.
• The evidence the problem is real — a number, a quote, a support volume, a lost deal.
• The hardest question a skeptic will ask — you'll need it for the FAQ, and if you don't know it, find it first.
• What already exists — the alternative the customer uses today, including doing nothing.

If two or more are missing, ask 2-4 sharp clarifying questions before writing. The one that matters most: "what can they do the day after this ships that they can't do today?" If the answer is a feature description rather than a capability, stay there until it isn't. When you already have the context, state an explicit Assumptions block up top so it can be corrected in one line.

Process

1. Write the headline as the customer would repeat it. One line, plain language, no product name games. If a customer wouldn't say it out loud to a colleague, rewrite it.
2. Write the sub-head: who it's for and the single benefit. One sentence. This is the piece that most often exposes a fuzzy target segment.
3. Write the problem paragraph in the customer's words. Use the actual language from tickets or interviews. Internal framing ("our activation funnel underperforms") is a tell that you're writing for yourself.
4. Write the solution paragraph as capability, not mechanism. What they can now do. Mechanism belongs in the FAQ, not here.
5. Add the two quotes. An internal leader quote that states why this matters strategically, and a customer quote that states what changed for them. Write the customer quote as if transcribed — if it sounds like marketing, the benefit isn't concrete enough yet.
6. Write the FAQ, hardest question first. Customer FAQ and internal FAQ separately. The internal FAQ is where cost, risk, what-we're-not-doing, and the thing you're least sure about live. An FAQ with no uncomfortable question in it is not finished.
7. Apply the kill test. Read the whole page as someone with no context. If it isn't compelling, say that plainly and recommend not building it — that is the skill working, not failing.

Output template

# [Headline — what the customer would say, one line]
### [Sub-head — who it's for and the one benefit, one sentence]

**[CITY] — [Month Day, Year]** — [Company] today announced [thing], which lets [specific customer] [do the new capability]. [One sentence on availability and price.]

## The problem
[2-4 sentences, in the customer's language. Lead with the evidence: the number, the volume, the quote. State what it costs them today.]

## What we built
[2-4 sentences. What the customer can now do, in order of how they'd experience it. Capability, not architecture. No internal terms.]

## What people are saying
> "[Internal leader quote — why this matters strategically, not how clever the tech is.]"
> — [Name, role]

> "[Customer quote — a concrete before-and-after in their own voice. Should sound transcribed, not written.]"
> — [Name, role, company]

## How to get started
[The first step a customer takes, in one or two sentences. If this is complicated, that's a product finding.]

---

# FAQ

## Customer questions
**[The question a real customer asks first]**
[Straight answer. No deflection.]

**What does it cost?**
[Answer, or state explicitly that pricing is undecided and when it will be.]

**What if [the obvious failure case]?**
[Answer.]

## Internal questions
**Why are we the right ones to build this?**

**What's the biggest risk, and what would we do if it happens?**

**What are we explicitly NOT building in v1?**

**What has to be true for this to work?** *(the riskiest assumption — name it, and the cheapest test of it)*

**What does this cost to build and run?** *(rough order of magnitude, stated as a range)*

**What are we saying no to by doing this?**

**What's the thing we're least sure about?** *(answer honestly — this is the most valuable line on the page)*

---

## Verdict
**Compelling? [yes / no / not yet]** — [one paragraph. If "not yet", say exactly what would have to change: a sharper segment, a bigger benefit, or better evidence the problem is real.]

Avoid (anti-patterns)

• Writing it after the spec. The whole value is that it comes first, when it can still change what you build. Written afterwards, it's a press release.
• Internal language in the customer section. "Leveraging our unified data layer" tells a customer nothing. If a term wouldn't survive being read to a customer, cut it.
• A fabricated customer quote that sounds like a brochure. Real people say concrete things: "I used to spend Monday morning chasing six people for updates. Now I read one digest."
• An FAQ of soft questions. If nothing in the FAQ is uncomfortable, you skipped the point of the exercise.
• Refusing to fail the kill test. A press release that can't be made compelling is the cheapest possible "no". Say so.
• Feature lists. Three benefits stated as capabilities beat ten features every time.
• Vague availability. "Coming soon" in a working-backwards doc hides the scoping conversation you need to have.

Tips

• 💡 Write the customer quote first. It's the hardest line on the page, and if you can't make it concrete, nothing downstream will be either.
• Read it out loud to someone outside the team. Watch where they look confused — that's the paragraph to rewrite.
• For example, if the headline needs a clause explaining what the product category is, your positioning isn't settled — run positioning before finishing this.
• Keep the whole thing to one page for the release plus two for the FAQ. The constraint is the mechanism; a three-page release proves nothing.
• Revisit it at launch. The gap between what you promised here and what actually shipped is the most honest retro input you'll get — feed it to spec-vs-shipped.