Product update emails people read, and how often to send them

The short answer

Write about what changed for the reader, not what you built. Keep it to one to three items, send it when something worth saying has shipped, and let a quiet month pass without an email. Once a month is a good default for a small product.

How often

No number fits every product, but these hold up:

• Monthly if you ship steadily. Weekly only if every week has something your readers care about.
• Skip it when nothing shipped. Silence is better than filler.
• Keep a rhythm. Pick a day in the month and stick to it, so people know when to expect you.

What goes in one

1. A subject that says the thing: "Invoices can be emailed now", not "March update".
2. A first line that says what changed, in the reader's words.
3. One sentence on why it matters to them.
4. A link, or the exact place to click to try it.
5. Your name at the bottom.

Subject: Invoices can be emailed now

Hi Sam, you can now send an invoice from inside the app. Open one, press Send, and your customer gets it with a link to pay. Until now you had to download a PDF first, which was silly. Next month I'm working on reminders for late invoices. Reply to this email if you want them sooner.

What to avoid

• Commit messages. "Fix null check in billing webhook" tells a customer nothing.
• Every fix. Mention a fix only if people were affected and would care.
• "We're excited to announce." Say what happened.
• Screenshots with no words. Some mail apps hide images until the reader allows them.
• Emailing people who never asked for updates.

How Kicklace does it

Keep a list called Product updates. People join it from a form on your site, either your own form marked with data-kl-list and heard by the Kicklace tag, or a form Kicklace hosts for you (Your website and its forms). Every sign-up keeps the exact sentence the person agreed to, and every email carries a one-click unsubscribe.

The list's card on your Lifecycle map holds a regular email, every week, every other week or every month at 9:00. Its news comes from a variable that fills itself when the email goes out. It can read:

• what shipped, from your deploys and commits: each production deploy on Vercel becomes a release, and where GitHub is connected, the commit and pull request titles come with it, one dated line each (Deployments from Vercel);
• what changed on your website;
• lines and links you add yourself.

A week with nothing deployed sends nothing.

A deploy's title comes from its commit message, so it can read like one. That is why an email with a variable is read before it goes: its words wait on Home, under Needs you, as they will arrive. Approve it and it goes. Decline it and that time is skipped.

If the email reads your own notes, Kicklace asks you for them the day before it goes, by email and on Home. Paste your links with a line on each. Kicklace reads each page and writes two or three sentences around your line. If you give it nothing, nothing is sent.

Write it for me writes the regular email in your voice, and Send one now writes a one-off to the list when you have a big launch to announce. Nothing sends until you switch it on. Kicklace is free up to 1,000 contacts (pricing), and the demo lets you try it on your own site with no sign-up. To start from words that are already written, copy a product update email template. If you deploy on Vercel, see the Vercel deploy product update email.

FAQ

Should every release get an email?

No. Bundle small changes into the regular update and send a separate email only for something people have been waiting for. A fix that touched three users is a reply to those three, not a newsletter item.

Do I need Vercel or GitHub?

No. They are two sources for the variable. You can write the news yourself, add links, or let Kicklace read what changed on your website.

Who should get product updates?

People who asked for them. In Kicklace that is the people who joined your Product updates list, each with the sentence they agreed to. Email to a list never goes to anyone else.