Back to blog

How to announce a new feature on X (7 templates that work)

By Naod Tadele · · 6 min read

Loudcode guideHow to announcea new feature

You shipped something. You open X and write "New feature: bulk export is live!" Twelve people see it. Two of them are your co-founders.

Feature announcements fail for one reason: they describe the feature, not the change in someone's day. Here's how to fix that, with templates you can copy.

The rule: lead with the person, not the feature

Nobody wants "bulk export". They want to stop exporting rows one by one at 11pm. Start with the before, then the after.

Example post
Exporting a month of invoices used to take 40 clicks. Now it's one button. Bulk export is live in Nightshift for every plan.

The feature name comes last. The pain comes first.

7 templates

1. The before and after. What it was like, what it's like now.

Example post
Before: copy every incident into Slack by hand. After: Nightshift posts one summary when the alert fires. Shipped today.

2. The "you asked for it". Credit the people who asked. It shows you listen.

Example post
11 of you asked for dark mode. It's live. Thank you for being patient (and persistent).

3. The tiny demo. One screenshot or 10-second video, one line of text. Visual features almost always do better with an image.

4. The decision behind it. Why you built it this way, and what you didn't build.

Example post
We almost built a full dashboard for this. Then we watched 5 people use the beta. All they wanted was one number. So that's what shipped: one number, on the home screen.

5. The number. If the feature moved something, say what.

Example post
Since we shipped grouped alerts, on-call engineers get about a third of the pings they used to.

Only use real numbers. If you don't have one yet, use a different template.

6. The question. Ship, then ask what's next.

Example post
Bulk export is live. Next: scheduled exports or a Zapier integration? Which one would you actually use?

7. The small one. Not every update needs drama. A short, honest post about a small fix keeps you visible between big launches.

Example post
Small one: search now remembers your last filter. It's been annoying me for weeks.

Five mistakes to avoid

  • Version numbers as the hook. "v2.4.1" means nothing to a stranger.
  • Lists of ten changes. Pick the one that matters most. Save the rest for a thread or your changelog.
  • No context. Say what your product is in a few words. Most people seeing the post have never heard of it.
  • A link as the first thing. Put the point in the post. Add the link in a reply if you need it.
  • Waiting for the perfect moment. The best time to announce a feature is the day you ship it, while you still remember why it was hard.

Make it a habit, not a project

The hardest part isn't the template. It's remembering to post after every release. That's why we built Loudcode: it reads your commits and releases on GitHub, and drafts the announcement in your voice with your product's context, so a stranger understands it. You review it and post it, or queue it for later.

For more, see how to turn GitHub commits into posts people read.

You ship the code. We write the posts.

Your commits, revenue, traffic and a 30-second weekly check-in become build-in-public posts for X, in your voice. You approve every post.

Keep reading

All posts