press-release
Write an Amazon-style press release that defines customer value before building. Use when aligning stakeholders on a new product, feature, or strategic bet.
What this skill does
## 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?" ## 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: ```markdown "[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 ```markdown [City], [State], [Country], [Date] — Today, [Company], a [type of organization], announced [key news], a [brief description]. This [product/feature] is set to [main benefit], addressing [key customer problem]. ``` **Quality checks:** - **Concise:** 2-3 sentences max - **Customer problem mentioned:** Don't jump to solution—name the problem first --- ### Step 4: Explain the Problem ```markdown [Product/feature] solves [specific customer problem]. According to [source or customer insight], [supporting data or quote that validates the problem]. ``` **Quality checks:** - **Specific problem:** Not "inefficiency" but "manual invoice processing takes 8 hours per month" - **Validated:** Include data, customer quotes, or research to prove the problem is real --- ### Step 5: Describe the Solution (Outcome-Focused) ```markdown [Product/feature] addresses this by [how it solves the problem—focus on outcomes]. [Quote from company leader]: "[Insert quote that emphasizes customer value, not features]." ``` **Quality checks:** - **Outcome-first:** "Reduces processing time" not "includes OCR technology" - **Quote is visionary:** Should reflect customer empathy and company values --- ### Step 6: Add Supporting Details ```markdown In addition to [key benefit], [product/feature] also [additional benefits]. According to [statistic or source], [supporting data]. ``` **Quality checks:** - **Data-driven:** Use numbers where possible (time savings, cost reduction, etc.) - **Customer-centric:** Still focused on "what they get," not "what we built" --- ### Step 7: Include Boilerplate ```markdown [Company], founded in [year], is a [type of company] known for [main products/services]. With a focus on [company mission or values], [Company] has [achievements or milestones]. ``` --- ### Step 8: Add Call to Action and Media Contact ```markdown For more information about [product/feature], visit [website] or contact [media contact name] at [contact info]. **Media Contact Information:** [Name] Title: [Title] Phone: [Phone] Email: [Email] ``` --- ### Step 9: Test the Press Release Ask these questions: 1. **Would a customer care?** If you sent this to a target customer, would they want to learn more? 2. **Is the problem clear?** Can someone who's never heard of your product understand the pain point? 3. **Are benefits measurable?** Can you prove the claims (time savings, cost reduction, etc.)? 4. **Is it jargon-free?** Could your mom understand it? 5. **Does it pass the "so what?" test?** If someone reads this and says "so what?" you haven't articulated value. If any answer is "no," revise. --- ## Examples See `examples/sample.md` for full press release examples. Mini example excerpt: ```markdown **Headline:** "Acme Launches SmartInvoice to Cut Processing Time by 60%" **Problem:** Small businesses spend 8 hours/month on manual invoices **Solution:** Automates extraction and approvals to save time ``` --- ## Common Pitfalls ### Pitfall 1: Feature List Instead of Benefits **Symptom:** "Includes AI, ML, OCR, NLP, and real-time sync" **Consequence:** Customers don't care about features—they care about outcomes. **Fix:** Translate features to benefits: "AI-powered automation reduces invoice processing time by 60%." --- ### Pitfall 2: Vague Problem Statement **Symptom:** "Solves inefficiency in workflows" **Consequence:** No one recognizes themselves in this problem. **Fix:** Be specific: "Small business owners spend 8 hours/month manually entering invoice data." --- ### Pitfall 3: Jargon-Heavy Language **Symptom:** "Leverages cutting-edge ML models to optimize enterprise-grade workflows" **Consequence:** Customers can't understand what you're saying. **Fix:** Write like you're explaining it to a friend: "Automatically handles invoices so y
Related in Sales & CRM
process-mapper
IncludedUse when a BizOps lead, COO, or process-improvement owner needs to document an end-to-end business process (procurement, employee onboarding, incident handoff, customer-onboarding, claims adjudication) in BPMN-style notation, measure cycle times by stage, surface where work spends most of its time waiting vs. being worked, and quantify the gap between processing time and total elapsed time. Pairs Lean / Six Sigma / Theory-of-Constraints canon with deterministic stdlib-only Python tools to produce a process map, a ranked bottleneck list (with severity + root-cause hypothesis), and a cycle-time analysis (P50, P90, value-add ratio, Little's-Law throughput). Distinct from sales-pipeline, system-reliability (SLO), and strategic-OKR work — this is tactical process documentation for internal operations.
payment-integration
IncludedIntegrate payments with SePay (VietQR), Polar, Stripe, Paddle (MoR subscriptions), Creem.io (licensing). Checkout, webhooks, subscriptions, QR codes, multi-provider orders.
customer-success-manager
IncludedMonitors customer health, predicts churn risk, and identifies expansion opportunities using weighted scoring models for SaaS customer success
sales-engineer
IncludedAnalyzes RFP/RFI responses for coverage gaps, builds competitive feature comparison matrices, and plans proof-of-concept (POC) engagements for pre-sales engineering. Use when responding to RFPs, bids, or proposal requests; comparing product features against competitors; planning or scoring a customer POC or sales demo; preparing a technical proposal; or performing win/loss competitor analysis. Handles tasks described as 'RFP response', 'bid response', 'proposal response', 'competitor comparison', 'feature matrix', 'POC planning', 'sales demo prep', or 'pre-sales engineering'.
customer-success-manager
IncludedMonitors customer health, predicts churn risk, and identifies expansion opportunities using weighted scoring models for SaaS customer success
sales-engineer
IncludedAnalyzes RFP/RFI responses for coverage gaps, builds competitive feature comparison matrices, and plans proof-of-concept (POC) engagements for pre-sales engineering. Use when responding to RFPs, bids, or proposal requests; comparing product features against competitors; planning or scoring a customer POC or sales demo; preparing a technical proposal; or performing win/loss competitor analysis. Handles tasks described as 'RFP response', 'bid response', 'proposal response', 'competitor comparison', 'feature matrix', 'POC planning', 'sales demo prep', or 'pre-sales engineering'.