You've spent two weeks building a feature your users have been asking for. You ship it. You send an email that says "We just shipped [Feature Name]!" You get 3 replies.
This is the standard experience. And it almost always comes down to the same mistake: the announcement was written from the builder's perspective, not the user's.
Why Feature Announcements Get Ignored
Feature announcement emails are usually structured like this:
- Subject: "New in [Product]: [Feature Name]"
- Body: "We're excited to announce that we've launched [Feature Name]. Here's what it does: [bulleted feature list]. We hope you enjoy it! — [Founder Name]"
This structure is about the team and what they built. It answers the question nobody asked ("what did you ship?") and doesn't answer the question everyone is implicitly asking ("why should I care about this right now?").
A feature announcement that gets opened, read, and acted on is structured entirely around the user: what can they do now that they couldn't do before, and why does that matter for them specifically?
The One Framing Shift That Changes Everything
Before you write the announcement, answer this one question: What specific problem does this feature solve for a specific user, in concrete terms?
Feature description: "We've added a Video Script Generator to Startkitz."
Outcome framing: "You can now generate a 60-second demo video script from your app URL — in the same place you generate your landing page and ad copy."
These say the same factual thing. But the second one is written for the user and tells them what they can do now — which is all they needed to hear.
Every element of your announcement should pass this test: is this about what we did, or about what you can do?
StartKitz
Get feature announcement copy generated from your URL
StartKitz generates feature announcement email, social post, and changelog copy — written from the user's outcome perspective, not the builder's feature perspective.
Generate your announcement →
Writing the Email Announcement
Subject line rules:
Use the feature or outcome name. Don't use "Product Update" or "Newsletter."
- ❌ "Product Update #12 — New Features"
- ✅ "New in Startkitz: Generate your demo video script in 60 seconds"
- ✅ "You can now generate video scripts in Startkitz"
The second and third are about what you (the user) can do. That's the subject line that earns opens.
Email structure:
- One line naming what's new — written as an outcome
- A specific 1–2 sentence description of the use case (the problem it solves)
- One direct link to try it
- Optional: context on why you built it (personal connection earns goodwill)
Example:
Subject: You can now generate demo video scripts in Startkitz
Hey [Name],
Video is the highest-performing content format for app launches right now — but writing a good 60-second demo script from scratch takes time most founders don't have.
Today we added a Video Script Generator to Startkitz. Paste your app URL and get a ready-to-record demo script: hook, product walk-through, and CTA — in under a minute.
→ Try it now: [Link]
This was the most-requested feature for the past two months. If you have feedback after trying it, hit reply — I read everything.
— Jason, Startkitz
Writing the Social Post Version
The social version of a feature announcement has different constraints: no subject line, no inbox relationship — just the first line determining whether they keep reading.
The best social announcement structure:
- First line: the outcome (not "we just shipped")
- Second line: the specific use case
- Third/fourth line: a small context detail that earns credibility
- CTA: direct link, not "check it out"
Example (LinkedIn/Twitter format):
You can now generate a demo video script for your app from a URL.
Most SaaS founders delay video because writing a good 60-second script takes 2 hours they don't have. Startkitz's new Video Script Generator does it in under a minute — hook, walkthrough, CTA, all from your app URL.
Built because it was our #1 feature request for 2 months straight.
→ Try it: [link]
In-App Notification Copy
The in-app notification is the highest-intent touch point — the person is already in the product. Keep it extremely short and action-focused.
"New: Generate demo video scripts — try it now →"
"Video scripts are live. Paste your URL and get a ready-to-record demo. → Try it"
The in-app notification has one goal: get them to try the feature, not describe it in detail.
The Changelog Entry
Your changelog is primarily a trust-building artifact. Potential customers check it to see whether you're actively building. Structure it clearly:
- Date + tag (NEW / IMPROVED / FIXED)
- 2–3 sentence description of what was added and what problem it solves
- Link to docs or a quick demo if relevant
Keep the changelog public-facing. It does more SEO and trust work than most founders realize.
What Channels to Use and When
For every shipped feature: In-app notification + email to active users + changelog entry.
For high-impact features: Add social post + email to full list + outreach to the users who specifically requested it (reply directly to the email where they asked).
The most underused channel: Direct reply to users who requested the feature. "Hey — you mentioned [feature] in a reply 3 weeks ago. We just shipped it. Here's how to try it: [link]." This converts at extremely high rates and builds lifetime loyalty.