# Press Release > 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. - Skill: `sidsaladi9/press-release` (Agent Skill) - Install (CLI): `npx skillmds@latest add sidsaladi9/press-release` - Raw SKILL.md: https://api.skillmd.com/api/skills/sidsaladi9/press-release/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: Sidsaladi9 (https://skillmd.com/u/sidsaladi9) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/sidsaladi9/press-release --- # 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 ```markdown # [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`.