Product update emails are a category SaaS companies almost universally do badly. The team ships a feature, marketing writes the announcement, the email goes to the entire user base, and engagement is invisible. Open rate sits at 15%. Click-through is sub-1%. The product team concludes "our customers don't care about updates". The truth is closer to "our customers never saw the update because the email landed in Promotions and they don't check Promotions".
Changelog emails fail because they're low-engagement broadcast to wide audiences. Fix it by segmenting (only send updates about surfaces a user actually uses), reducing frequency, offering opt-in granularity, and accepting that Promotions tab placement is fine if the user has opted in. In-app changelog complements email; it doesn't replace it.
Engagement signals matter more than copy
Mailbox providers measure engagement: opens (degraded by MPP), replies (strong), clicks (medium), folder moves (very strong), complaints (devastating). A changelog email that goes to your whole user base will, by definition, have low engagement — because most of your user base doesn't use the feature you just shipped.
Low engagement on the marketing sender drags down the sender's reputation. Over time, your other marketing mail — including the trial-end and renewal sequences — start underperforming because the sender's reputation has degraded. Changelog mail can be a slow poison for the rest of your email programme.
Promotions tab is fine, sometimes
Many product teams panic when changelog emails land in Promotions. They shouldn't. Promotions is the right placement for opt-in marketing content, including changelog. A user who has opted in to product updates and checks Promotions weekly is having the right experience.
The problem is not Promotions — it's spam, and it's users who don't check Promotions. For the latter, no email strategy will reach them; you need in-app surfaces. For the former, the fix is sender-reputation hygiene.
Segment by product surface area
The single highest-leverage move on changelog: don't send every update to every user. Segment by product surface area. If you ship a feature in your reporting module, send the announcement only to users who've opened the reporting module in the past 90 days. The audience is smaller; the engagement is dramatically higher; the sender reputation improves.
This requires product analytics in your CRM or sending tool. The setup work is real (instrumenting feature usage, syncing to the email tool) but it pays back in deliverability and in conversion-to-feature-adoption rates.
- By module: only users who've touched module X in the last quarter.
- By plan: only users on plans that get the new feature.
- By role: admins for admin features, end-users for end-user features.
- By engagement tier: highly active users get more updates; dormant users get a monthly digest.
Opt-in granularity
Offer users explicit opt-in choices for product update categories. Major releases. Minor releases. Beta features. Security updates. The user picks. This serves two purposes: it cuts your audience to the people who genuinely want each kind of update (engagement rises), and it protects you from complaints (the user explicitly asked for this).
The opt-in UI lives in the user's notification preferences in your app. Honour the choices. The biggest mistake we see is a company that has "product update" in the preferences but sends them to everyone regardless. That's a complaint magnet.
Frequency: monthly digest beats weekly
For most SaaS, a monthly product-update digest outperforms weekly per-feature emails on every metric: open rate, click-through, deliverability, complaint rate. The monthly cadence respects the user's inbox; the digest format means each email has multiple things worth opening for.
Reserve per-feature emails for genuinely major launches — the ones that justify their own moment. Two or three a year, not two or three a week.
Each "mark as spam" click costs you measurably. Gmail considers complaint rate one of the most important signals; a complaint rate above 0.3% on a sender is a fast path to Promotions or worse. Sending changelog more often than users want is the most common cause of complaint-rate drift.
In-app vs email: complement, don't replace
An in-app changelog widget (Headway, Beamer, Canny's announce, or your own) reaches users when they're in product. Email reaches users when they're not. Both have their place.
The right pattern: in-app for highly engaged users (they'll see updates in the natural course of using the product); email for users who haven't logged in recently (the email is their re-engagement vehicle); both for big launches.
Don't collapse to email-only — you'll over-email and damage deliverability. Don't collapse to in-app-only — you miss every user who isn't already logged in.
Sender setup for product updates
Product updates belong on your marketing sending stream — not the transactional one. Mixing the two contaminates the transactional reputation. A separate marketing subdomain (news.example.com or updates.example.com) with its own SPF, DKIM, and reputation is the right setup.
Run weekly seed tests on the marketing subdomain. Track Promotions vs Spam vs Inbox placement. Promotions placement is fine and expected; Spam placement is a problem and signals reputation degradation.