Feature Announcement

---
name: feature-announcement
description: "Writes feature release announcements with benefit framing, screenshots, and adoption encouragement across channels. Use when launching new product features."
allowed-tools: Read Write Glob
metadata:
  author: matthewhitcham
  version: "1.0"
---

# Feature Announcement

## When to Use This Skill

Use this skill when you need to:
- Announce a new product feature across email, blog, and social channels
- Write benefit-driven feature release copy that drives adoption
- Create a multi-channel launch plan for a product update
- Frame technical improvements in user-friendly language

**DO NOT** use this skill for full product launches, company announcements, or internal release notes. This is for individual feature release communications only.

---

## Core Principle

FEATURE ANNOUNCEMENTS SELL THE OUTCOME, NOT THE FEATURE — USERS CARE ABOUT WHAT THEY CAN NOW DO, NOT WHAT YOU BUILT.

---

## Phase 1: Brief

### Required Inputs

| Input | What to Ask | Default |
|-------|------------|---------|
| **Feature name** | "What is the feature called?" | No default — must be provided |
| **What it does** | "Describe the feature in plain language. What can users now do?" | No default — must be provided |
| **Who benefits most** | "Which user segment benefits most from this feature?" | All users |
| **Before/after** | "What did users do before this feature? What changes now?" | No default — ask for the contrast |
| **Channels** | "Where will you announce? Email, blog, in-app, social, all?" | All channels |
| **Launch date** | "When does this go live?" | Immediately |

**GATE: Confirm the brief before writing any copy.**

---

## Phase 2: Plan

### Channel Strategy

Map each channel to its purpose:

| Channel | Purpose | Format | Length |
|---------|---------|--------|--------|
| **Email** | Drive awareness and first use | Dedicated email | 150-250 words |
| **Blog post** | Detailed walkthrough for SEO | Tutorial-style | 500-800 words |
| **In-app notification** | Contextual discovery | Banner or modal | 1-2 sentences |
| **Social (Twitter/LinkedIn)** | Awareness and engagement | Thread or post | 50-100 words |
| **Changelog** | Documentation | Brief entry | 50-100 words |

### Messaging Hierarchy

Define before writing:
1. **Headline:** The benefit in one sentence
2. **Subhead:** How it works in one sentence
3. **Proof point:** One specific example or use case
4. **CTA:** The single action you want users to take

**GATE: Confirm channel plan and messaging hierarchy before writing.**

---

## Phase 3: Write

Draft copy for each approved channel:

### Email Announcement

```
Subject: [Benefit-driven subject line]
Preview text: [Extends the subject, adds curiosity]

[1-2 sentence hook — the problem this solves]

[Screenshot or GIF placeholder: [SCREENSHOT: feature in action]]

[2-3 sentences explaining what the feature does and how to use it]

[1 sentence social proof or use case if available]

[CTA button: Try [Feature Name] Now]
```

### Blog Post Structure
- **H1:** Benefit-driven headline (not "Introducing [Feature]")
- **Intro:** The problem this solves (2-3 sentences)
- **What's New:** Feature description with screenshots
- **How to Use It:** Step-by-step walkthrough (3-5 steps)
- **Use Cases:** 2-3 specific scenarios
- **CTA:** Try the feature with a direct link

### In-App Notification
- Max 2 sentences
- Link to blog post or help doc for details
- Dismissible with "Got it" or "Try it"

### Social Post
- Lead with the benefit, not the feature name
- Include a visual (screenshot or short video)
- End with a link to the blog post

---

## Phase 4: Polish

### 1. Screenshot Brief

```
## Screenshot/Visual Needs

- [ ] Before state: [Description of the old workflow]
- [ ] After state: [Description of the new feature in use]
- [ ] Annotated screenshot with arrows pointing to key elements
- [ ] GIF showing the feature in action (5-10 seconds)
- [ ] Dimensions: 1200x675 for blog, 600x300 for email
```

### 2. Adoption Tracking

Define metrics to measure announcement success:
- Email open and click rates
- Blog post views and time on page
- Feature adoption rate (% of users who try the feature within 7 days)
- In-app notification click-through rate

### 3. Quality Checklist

```
## Feature Announcement Checklist

- [ ] Headline leads with benefit, not feature name
- [ ] Every channel copy answers "What can I do now that I couldn't before?"
- [ ] Email is under 250 words with one clear CTA
- [ ] Blog post includes step-by-step usage instructions
- [ ] In-app notification is 2 sentences or fewer
- [ ] Screenshots or visual placeholders are specified
- [ ] Social post includes a visual and link
- [ ] CTA links directly to the feature (not a generic page)
- [ ] Changelog entry is written for documentation
```

---

## Example

**Feature:** Automated invoice reminders
**Audience:** Freelancers using the billing tool

**Email subject:** "Stop chasing late payments — your invoices now follow up for you"
**Email hook:** "Late payments cost freelancers an average of $4,200 per year. Starting today, your invoices handle the follow-up automatically."

**In-app:** "New: Automatic payment reminders. Your overdue invoices now send follow-ups on your behalf. [Set it up]"

---

## Anti-Patterns

- **"We are excited to announce..."** — nobody cares about your excitement. Lead with the user's benefit.
- **Feature-first headlines** — "Introducing Widget 2.0" says nothing. "Now you can [benefit]" says everything.
- **Same copy everywhere** — each channel has different context and attention spans. Adapt the message.
- **No CTA** — every announcement should drive users to try the feature immediately.
- **Technical jargon** — "We refactored the API endpoint" is not an announcement. Translate to user impact.

---

## Recovery

- **Feature is minor:** Frame as a quality-of-life improvement. Use changelog + in-app only. Skip email and blog.
- **No screenshots available:** Describe the UI in text and mark screenshot placeholders. Write the copy now, add visuals later.
- **Feature is complex:** Lead with the simplest use case. Link to a detailed help doc for advanced usage.
- **Negative user reaction anticipated:** Acknowledge the change directly, explain the reasoning, and provide a feedback channel.