/press-release

name: press-release
argument-hint: "[product or feature idea]"
description: Write an Amazon-style press release that defines customer value before building. Use when aligning stakeholders on a new product, feature, or strategic bet.
intent: >-
  Create a visionary press release following Amazon's "Working Backwards" methodology to define and communicate a product or feature before building it. Use this to align stakeholders on the customer value proposition, clarify the problem being solved, and test if the product story resonates—treating the press release as a forcing function for clarity and customer-centricity.
type: component
theme: pm-artifacts
best_for:
  - "Defining customer value before a line of spec gets written"
  - "Aligning stakeholders on what a launch actually promises"
  - "Killing a weak idea early by trying to write its announcement"
scenarios:
  - "We're about to build something big and I want to test whether the value is real"
  - "Stakeholders disagree about what this launch promises customers — write it as news"
estimated_time: "30-45 min"

Purpose

Create a visionary press release following Amazon's "Working Backwards" methodology to define and communicate a product or feature before building it. Use this to align stakeholders on the customer value proposition, clarify the problem being solved, and test if the product story resonates—treating the press release as a forcing function for clarity and customer-centricity.

This is not a marketing artifact for launch day—it's a planning tool that asks "If we shipped this perfectly, how would we explain it to the world?"

Input

**Works best with:** The product or feature idea, plus who it's for. **Also useful:** The customer problem, the headline benefit, and an internal quote-worthy point of view.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended `ARGUMENTS:` line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

**Arriving empty-handed? That works too.** The skill asks who the customer is and what changes for them on launch day — the two things a working-backwards press release cannot fake.

**Example invocation:** `Amazon-style press release: instant expense approval for field technicians, launching Q3.`

Key Concepts

The Amazon Working Backwards Framework

Popularized by Amazon, the Working Backwards process starts with a press release and FAQ before any code is written. The press release must:

• Be written from the customer's perspective
• Focus on the problem solved, not the features built
• Be short (1-1.5 pages)
• Be compelling enough that customers would want the product

Press Release Structure

A standard press release follows this format:

1. **Headline:** Clear, benefit-focused product announcement 2. **Dateline:** City, state, date 3. **Introduction paragraph:** What's being launched, who it's for, key benefit 4. **Problem paragraph:** Customer problem the product solves 5. **Solution paragraph:** How the product addresses the problem (outcomes, not features) 6. **Quote from company leader:** Vision, customer commitment 7. **Additional details:** Supporting benefits or data 8. **Boilerplate:** Company background 9. **Call to action:** How to learn more 10. **Media contact:** Press contact information

Why This Works

• **Customer-first thinking:** Forces you to articulate value from the customer's perspective
• **Clarity forcing function:** If you can't write a compelling press release, the product idea may be weak
• **Alignment tool:** Stakeholders can read and react to the vision before engineering starts
• **Decision filter:** If a feature wouldn't make it into the press release, question its priority

Anti-Patterns (What This Is NOT)

• **Not feature-centric:** Don't list specs—focus on customer outcomes
• **Not internal jargon:** Write for customers, not engineers
• **Not vague:** "Revolutionizes productivity" is fluff; "Reduces report generation time from 8 hours to 10 minutes" is real
• **Not marketing spin:** Be honest about what the product does

When to Use This

• Defining a new product or major feature
• Aligning stakeholders on vision before development
• Testing if a product idea is compelling
• Pitching to execs or securing buy-in

When NOT to Use This

• For trivial features (don't over-engineer small tweaks)
• After you've already built the product (too late)
• As actual launch-day press release (this is a planning doc, not final marketing copy)

---

Application

Use `template.md` for the full fill-in structure.

Step 1: Gather Context

Before drafting, ensure you have:

• **Product/feature description:** What are you building?
• **Target customer/persona:** Who is this for? (reference `skills/proto-persona/SKILL.md`)
• **Problem statement:** What customer problem does this solve? (reference `skills/problem-statement/SKILL.md`)
• **Key benefits:** What outcomes does it deliver?
• **Competitive context:** How is this different from alternatives? (reference `skills/positioning-statement/SKILL.md`)
• **Company mission/values:** How does this fit the company's vision?

**If missing context:** Run discovery, define the problem statement, or clarify positioning first.

---

Step 2: Draft the Headline

Create a clear, benefit-focused headline:

"[Product/Feature Name] by [Company] Aims to [Main Benefit/Goal]"

**Quality checks:**

• **Benefit-focused:** Does it say what the customer gets, not just what you built?
• **Specific:** "Aims to simplify workflows" is vague; "Aims to cut invoice processing time by 60%" is specific
• **Memorable:** Can someone repeat this headline in a conversation?

**Examples:**

• ✅ "Acme Workflows Launches Invoice Automation to Cut Processing Time by 60% for Small Businesses"
• ❌ "Acme Launches New Product with AI Features"

---

Step 3: Write the Dateline and Introduction

[City], [State], [Cou