A feature announcement page for one change worth explaining
Most features belong in a changelog line. A few deserve a page of their own: the ones that change how people use the product, open it to a new kind of customer, or that you'll want press and partners to write about. That page explains one change, shows it working, says who it's for and ends with one way to try it.
When a feature earns its own page
A dedicated page takes a day or two of someone's time to write and keep accurate, so be choosy. Good reasons:
- Existing users will need to change a habit, and support will want one link to send.
- It answers the objection that has been costing you sales ("does it work offline?").
- You're pitching it to journalists, newsletters or partners who need something to cite.
- You'll run an email or ad campaign about it and want a page that matches the message.
If none of those is true, a short entry on your changelog page does the job and stays easier to maintain.
The structure that works
- A headline that names the outcome, not the feature's internal name. "Invoices now chase themselves" tells more than "Introducing Auto-Remind".
- One sentence on who it's for and what they can now do that they couldn't before.
- The change in action: three annotated screenshots, with a link to a short video if you have one. Show the real interface, not a mock-up.
- How it works, in three or four steps, with any settings people need to turn on.
- What it doesn't do yet, honestly. Readers forgive limits; they don't forgive discovering them.
- Availability: which plans, which platforms, from what date, and whether it's rolling out gradually.
- One call to action: try it, update the app, or read the docs.
Put the date the page was published near the top. Feature pages get linked for years, and a reader arriving later should be able to tell how current it is.
Mistakes that make these pages age badly
| Problem | Fix |
|---|---|
| Screenshots of an interface that has since changed | Keep a list of feature pages and check them at each design change |
| "Coming next month" promises left on a page for a year | Avoid dates for future work, or come back and update them |
| A headline that only makes sense to the team | Test it on someone who doesn't work there |
| Several features crammed onto one page | One page per feature; a release roundup can link them |
| No route for people without access | Say plainly who has it and how others can get it |
Building it on Anticode
There are two good ways to set it up. For an occasional big launch, build a standalone landing page: describe the feature, who it helps and the call to action, and the Architect proposes the sections before it builds. Upload your screenshots and the model sees and places them; a demo video can't play on the page, so host it on YouTube or Vimeo and link to it. Publish it on its own address, or on a subdomain of your own domain on a paid plan.
If you'll announce features regularly, keep them in a CMS collection on your main site instead, with fields for headline, summary, availability and date. Each entry gets its own URL at /<collection>/<slug>, and the collection page becomes a list of past launches you can point press to.
Version history helps on launch day. Prepare the page in advance, then make last-minute changes in the visual editor or by asking in a sentence. If a late edit goes wrong, preview an earlier version and restore it. Before you publish, run the release checklist to see every publish check without going live. The Product Hunt launch checklist covers the day itself.
Limits
- No embedded players. Published pages can't embed YouTube or similar, and video files don't play on design-engine pages either, so link out to the video.
- No interactive product demo on a design-engine page, which runs no scripts. An interactive product demo can be built as a separate app with sample data.
- No scheduled publishing. Publish by hand when the feature ships.
- No access gating: published pages are public, so don't announce a feature before you're ready for anyone to read about it.
Questions people ask
Should the announcement go on the blog or its own page?
A blog post tells the story of the launch; a feature page explains the feature for as long as it exists. Many teams do both and link them.
How long should a feature announcement page be?
Usually short: a few hundred words with visuals. Put the detail in documentation and link to it.
Can I update the page after launch?
Yes. Edit it in place or ask for a change, and recent versions stay in version history.