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

GATE: Confirm the brief before writing any copy.

Phase 2: Plan

Channel Strategy

Map each channel to its purpose:

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.