Announce a feature on X, LinkedIn and Reddit

You shipped something. The pull request is merged, the release is tagged, and the hardest part of the week is done. Then comes the part many makers skip: telling anyone.

A feature that is not announced reaches the users who happen to stumble on it. An announcement copied word for word to three platforms reaches a few more, and sounds wrong on at least two of them. This guide gives you one way to write the announcement once, and adapt it three times.

Decide whether it is worth a post at all

Not everything you ship deserves an announcement, and posting about everything trains people to ignore you.

A rough sort that works:

• A feature: something users can now do that they could not do before. Announce it.
• An improvement: something they could do, now faster or nicer. Announce it if people asked for it, or if you can show the difference.
• A fix: mention it in the changelog. Announce it only when the bug was visible and annoying, as a short "this is fixed, sorry".
• An internal change: dependencies, refactoring, tests. Nobody outside needs a post.

If you publish releases on GitHub, your release notes already contain this sorting in rough form. GitHub can generate them from merged pull requests, grouped by label (GitHub's documentation explains the categories). A changelog written for people, in the spirit of Keep a Changelog, makes the announcement half-written before you start.

Write the core once

Before thinking about platforms, answer four questions in one sentence each:

1. What can people do now? In their words, not yours. "Export 50 invoices in one click", not "batch processing pipeline".
2. Who asked for it, or who is it for?
3. What does it look like? A screenshot, a ten-second recording, a before and after.
4. Where do they go to try it?

Those four sentences are the raw material. Each platform gets a different cut of them.

X: one idea, shown

On X, people scroll fast and decide in a line. What tends to work for a feature:

• Lead with the result, not with "We are excited to announce".
• Show it. A short screen recording does more than three paragraphs.
• Keep it to one idea. If the release has three features, pick one, or post three times over the week.
• Say something human: who asked, how long it took, what you got wrong first.

Shipped: [what people can do now, in one line].

[One concrete detail: a number, a limit, a shortcut.] [Who asked for it], so here it is.

[screen recording or screenshot]

[your tagged link]

Some makers put the link in a reply instead of in the post itself, on the belief that posts with links are shown less. Platforms do not publish how they rank posts, so treat this as something to test with your own audience, not as a rule. Either way, tag the link.

LinkedIn: the reason behind the feature

LinkedIn readers give you a few more seconds and expect a little more context. The feature is the occasion; the story is why it exists.

• Open with the situation, not the product: the customer request, the problem you kept seeing.
• Use short paragraphs with white space. One idea per paragraph.
• Be modest. "Small feature, big time saver" reads better than a superlative.
• End with a question only if you want the answer.

[A situation your reader recognizes, in one or two lines.]

[Number] of our users asked for the same thing last month: [the request, in their words].

So we built it. You can now [what people can do].

It took [honest effort: two evenings, three attempts]. The part we got wrong at first: [one lesson].

[your tagged link]

You can read how a post did in LinkedIn's own post analytics (LinkedIn's help page describes them). Those numbers stop at the click. What happened on your site afterwards is yours to measure.

Reddit: a contribution, not an announcement

Reddit is the platform where an announcement written as an announcement does worst. Communities have rules about self-promotion, and readers have a sharp eye for marketing copy. Read the rules of the community first, and Reddit's own rules.

What works is turning the feature into something useful to the community:

• A lesson: what you learned building it.
• A question: a real design decision you are unsure about.
• A before and after, with screenshots, in a community that enjoys them.

I added [feature] to my [kind of product] after [number] users asked. Here is how it works, and what I am unsure about

Context: [one or two lines about the product and who uses it].

The request: [what users wanted, and why the obvious solution did not work].

What I built: [plain description]. [Screenshot.]

What I am unsure about: [a real open question].

Would love feedback, especially from people who [have the problem].

[your tagged link]

The guide on turning a Reddit post into customers goes further into choosing a community and handling comments.

Give each announcement its own link

Three posts, three links. If all three point to the same untagged address, you will know that the release brought traffic, and nothing about which post did.

Add a short tag to each:

• yoursite.com/?ut=x-batch-export
• yoursite.com/?ut=li-batch-export
• yoursite.com/?ut=reddit-batch-export

Point the link at the page where the feature can be seen or tried, not at your home page. A visitor who clicks on "export 50 invoices in one click" and lands on a generic headline has to find the feature again by themselves, and many will not.

When you connect GitHub to upTake, this step is done for you: each release that is a feature or an improvement gets drafts per channel, each with its own tagged link. You still edit and post them yourself. The GitHub integration page lists what is read, which is release notes, pull request titles and commit messages, never your code.

Read the results after a few days

Give the posts three days, then compare them on what they brought, not on reactions.

Then keep one note per release: which channel brought signups for this kind of feature. After a handful of releases a pattern appears. Visual features may do best on one platform, workflow features on another. That pattern is specific to your product and your audience, which is why borrowed advice only goes so far.

Timing, and what not to do

• Post when you can reply. The hour matters less than being there for the first comments.
• Spread the three posts over two or three days instead of firing them together. You get three chances to be seen, and you can reuse what you learned from the first.
• Do not announce what is not live. "Coming soon" posts spend attention you will want on launch day.
• Do not paste the changelog. A list of eleven items is a list nobody reads. Pick one.
• Do not skip the changelog either. It is where returning users look, and it costs you two lines.

The short version

1. Sort what you shipped: feature, improvement, fix, internal.
2. Write the four core sentences once.
3. Cut them three ways: shown on X, explained on LinkedIn, contributed on Reddit.
4. Give each post its own tagged link, to the page where the feature lives.
5. Compare signups, not likes, three days later.

Announcing takes twenty minutes when the core is written. Not announcing costs you the users who would have wanted the feature and never heard of it.