Why most product updates never reach customers
Most software teams ship something new every week or two. A new export option, a faster search, an integration customers asked for. Each one makes the product more useful, but most of them only show up in a pull request, a closed ticket, or a one-line changelog entry that nobody reads. Customers keep working around problems you already fixed, and prospects compare you against a version of your product that's months out of date.
The writing is rarely what stops the announcement. The harder part is the work around it:
- Someone has to notice what shipped, across tickets and pull requests written for engineers.
- Someone has to decide which changes a customer would care about and how loudly to announce each one.
- Someone has to translate each change into what a customer can now do, then adapt it for the changelog, the blog, an email, and social.
- Someone has to publish it all, send it, and check whether anyone noticed.
On a small team, that someone is usually the founder or a single marketer, and release announcements lose to whatever is more urgent that week. That's why this job suits an AI agent. It can read the engineering record every week, make the sorting decisions with knowledge of your customers, and have the announcements ready when you are.
Kite is an AI marketer. It researches your business, builds a growth strategy, and ships the work that brings you new customers. It already knows your product, your customers, and your brand voice, so it can turn each release into announcements that sound like your company. Here's how it works.
How Kite announces every product update
Kite starts with the record of what your team shipped. With GitHub or Linear connected, it reads the pull requests merged or the issues closed since the last announcement. Without them, it reads your public changelog, release notes, and documentation.
From that record, Kite picks out the changes a customer would notice and decides how big an announcement each one deserves. It writes the changelog entries and release notes, then turns the notable changes into a blog post, a customer email, and social posts. Each piece is written for its channel rather than copied from one place to the next. You review everything in one place, and Kite publishes the approved work to your website, sends the email through your email platform, and posts to your connected LinkedIn account.
After the announcements go out, Kite checks what each one earned and records what it learned. You can run this once, for example to catch up on releases that never got marketed, or put it on a weekly schedule so every release gets announced from then on.
- Find out what your team shipped
- Decide which changes deserve an announcement, and how big
- Write release notes and changelog entries customers actually read
- Turn one release into a blog post, an email, and social posts
- Announce the features you shipped but never marketed
- Measure what each announcement earned
Find out what your team shipped
Kite builds its list of changes from the place your team already records its work. In GitHub, it reads the pull requests merged in a given period, along with their titles, descriptions, authors, and merge dates. In Linear, it reads the issues your team moved to Done, including their descriptions, labels, comment threads, and attached screenshots. Kite also reads repository files such as a README or an existing changelog when it needs to understand what a change actually does.
If your team doesn't use either tool, or you'd rather not connect them, Kite works from what's public. It reads your changelog page, your release notes, and your documentation. You can also tell Kite what shipped in plain language, such as "We launched CSV export on the reports page and fixed the slow search."
Decide which changes deserve an announcement, and how big
Kite sorts every change by how much it matters to a customer, because a release is usually a mix of things customers will notice and things they never will. Say your team merged 23 pull requests in the last two weeks. Most of them are bug fixes, dependency updates, and code cleanup. Three of them change what a customer can do: CSV export on the reports page, a new Zapier trigger, and search results that load twice as fast.
Kite matches the size of each announcement to the size of the change:
- Every customer-facing change gets an entry in your changelog, so the full record stays current.
- Small improvements and fixes are grouped into a single roundup entry or a monthly "what's new" email rather than announced one by one.
- Notable features get their own blog post, a mention in the customer email, and a social post.
- Major releases get the full launch treatment, with a landing page, an announcement email, a launch post, and a short launch video. Kite's Launch a product or feature page covers that work in detail.
Kite makes these calls using what it knows about your customers. A change gets more attention when it answers a common objection from sales calls, closes a gap your competitors' comparison pages point to, or delivers something customers have been asking for. If you track feature requests from prospects as Linear issues, Kite knows which closed issues people were waiting for and can announce those first to the people who asked.
Write release notes and changelog entries customers actually read
Good release notes describe what a customer can now do, not how the code changed. Kite writes each changelog entry the way a customer would want to read it: what's new, who it helps, where to find it, and a link to the documentation when there is some. "Added CSV export to ReportsTable component" becomes "You can now export any report as a CSV file from the Download button in the top right of the report."
Kite writes in your brand voice and checks what each change does before describing it, reading the pull request or issue and any related files. It can reuse the screenshots your team attached to a Linear issue, or generate a simple image for the post in your brand's colors.
Kite publishes the entries where your changelog lives. On a website Kite builds and hosts, it can add a changelog section to the site's content system and publish each new entry there. If your site runs on Webflow, Contentful, Sanity, Storyblok, or a self-hosted Payload site, Kite publishes through that connection. If your developers keep the site in GitHub, Kite delivers the new entry as a pull request for them to merge.
For ideas on how other teams format their changelogs and update emails, see Changelog examples: product update pages and emails small SaaS teams can copy Coming soon .
Turn one release into a blog post, an email, and social posts
Kite adapts each notable release for every channel your customers and prospects actually read, so one change becomes several announcements, each written for where it appears.
- The blog post tells the fuller story. It explains the problem the feature solves, shows how to use it, and gives prospects a reason to take a second look. Kite publishes it on your website, where it also gives search engines and AI answer engines a current, public description of what your product does.
- The customer email tells people who already pay you what they can now do, and links straight to the feature or its documentation. Kite can send one email per major release or bundle the month's changes into a single "what's new" email. With Mailchimp connected, Kite creates the campaign, sends you a test, and schedules it once you approve. With Resend connected, it sends a broadcast to the segment you choose, such as everyone subscribed to product news.
- The LinkedIn posts reach prospects and the wider market. Kite writes one post for your company page and, when it fits, one in a founder's voice for their own profile. Each post leads with what the change means for the reader rather than the feature name. Kite can also write posts and threads for X.
Back in Linear, Kite can comment on each announced issue with a link to the published post, so anyone on the product team can see how their work was announced.
Announce the features you shipped but never marketed
The features you shipped months ago and never announced are still news to most of your customers. Kite can find them and announce them now. It reads your public changelog, release notes, and documentation, then looks through your blog and your company's LinkedIn posts for any sign that each change was announced. The result is a list of shipped features that never got marketed, starting with the ones most likely to matter to your customers.
From that list, Kite drafts announcements for your three most notable releases that never got marketed. Older features rarely need a launch-day post. Kite usually frames them as a "things you might have missed" roundup email, a blog post about a problem customers commonly have and the features that solve it, or a short series of posts that each highlight one capability.
Once the backlog is clear, Kite moves on to the recurring work, so new releases get announced as they ship and the backlog doesn't build up again.
Measure what each announcement earned
After each announcement goes out, Kite checks how it performed and uses the results to plan the next one. On a website Kite hosts, it reads page views and referrers for each blog post and changelog entry. In Mailchimp, it reads opens, clicks on each link, and unsubscribes for every campaign. In Resend, it reads delivery and engagement for each broadcast and ranks the links readers clicked most. On LinkedIn, it reads impressions, clicks, and reactions for your company page posts.
Kite turns those numbers into decisions. If customers keep clicking the documentation link in your update emails and ignoring the blog link, the next email sends them straight to the docs. If LinkedIn posts that show a feature in a screenshot earn more clicks than posts that only describe it, the next posts include one. Kite records what it learns in your team's knowledge base, so each round of announcements starts from what already worked with your audience.
What you get
A list of what shipped
The customer-facing changes from each period, sorted by how much each one matters to customers, with the internal changes set aside.
Changelog entries and release notes
Each change written in terms of what a customer can now do, published to your changelog.
A blog post for each notable release
The fuller story of the feature, published to your website.
Customer update emails
One email per major release or a monthly roundup, sent through Mailchimp or Resend to the right audience.
LinkedIn posts
Posts for your company page and, when it fits, a founder's profile, published after you approve them.
Announcements for features that never got marketed
Drafts for your three most notable unannounced releases, then the rest of the backlog.
A record of what worked
The page views, email clicks, and post engagement each announcement earned, and what Kite will change next time.
How to get started
Start by telling Kite what you want announced. You might say, "Announce our last three releases that never got marketed," or "Every Friday, write up what we shipped this week and draft the announcements." You can work with Kite in the Kite web app or in Slack.
Kite looks at your changelog and recent releases, proposes which changes deserve announcements and how big each one should be, and drafts the work. You review the drafts and approve them with the Approve or Publish button or a quick reply. Kite asks before it publishes a page, sends an email, or posts to social media, and you can give it more autonomy once you trust how it announces your work. If your public changelog is active and your social accounts are quiet, Kite may suggest this as the first piece of work it takes on when you sign up.
You can catch up on unannounced releases with nothing connected, because Kite can read your public changelog and documentation. Connect GitHub or Linear when you want Kite to see each release as soon as it merges or closes. Connect Mailchimp or Resend for customer emails and LinkedIn for posting. If your website runs outside Kite, connect your content system so Kite can publish changelog entries and blog posts there.
Integrations used to announce product updates
Kite uses two kinds of integrations for this work. The first tells it what your team shipped, and the second carries each announcement to the people who should hear about it. The blog and changelog publish to a website Kite hosts or through your connected content system.
Find out what shipped
Kite reads the pull requests merged in a period, with their titles, descriptions, and merge dates, plus files like a README or changelog. On a website your developers keep in GitHub, Kite delivers new changelog entries and blog posts as pull requests.
Kite reads the issues your team moved to Done, including comments and attached screenshots, and the project target dates for what ships next. After an announcement goes out, it comments on each announced issue with a link to the published post.
Email your customers
Kite writes the update email, sends you a test, schedules or sends the campaign to the right audience or segment, and reads the opens and link clicks afterward.
Kite sends update emails as broadcasts to the segment you choose, respects each contact's topic subscriptions, and reads which links readers clicked.
Common questions
What's the difference between release notes, a changelog, and a product update announcement?
A changelog is the running, dated record of every change to your product, usually on its own page. Release notes describe the changes in one specific release, often in more detail. A product update announcement is the marketing around a release, such as a blog post, an email, or a social post that explains why the change matters. Kite writes all three. It keeps the changelog complete and saves the announcements for the changes worth telling people about.
Should I announce small updates and bug fixes?
Yes, but not one at a time. Small improvements and fixes belong in your changelog, where customers who care can find them, and they work well grouped into a monthly roundup email. A single email about a minor fix trains customers to ignore your updates. A monthly email that lists ten small improvements shows them the product is getting better every week.
How often should I send product update emails?
Most small software teams do well with one roundup email a month, plus a separate email for each major release. That's frequent enough that customers hear about new features while they're still new, and rare enough that each email is worth opening. Kite can send the roundup on a monthly schedule and suggest when a release is big enough to deserve its own email. If your email platform supports topics or groups, customers can choose to get product news without your other marketing email.
Can Kite announce releases if we don't use GitHub or Linear?
Yes. Kite can work from your public changelog, release notes, and documentation, or from a plain description of what shipped. GitHub and Linear help because they show Kite each change as it happens, along with the descriptions and screenshots your team already wrote. Without them, Kite works with whatever record your team keeps.
Do product announcements help AI assistants recommend my product?
They can. ChatGPT, Perplexity, Gemini, and Claude can only describe the features they can find on public pages. A feature that's announced only inside your app, or not at all, is invisible to them, so they may describe your product as it was a year ago. Public changelog entries and blog posts give them a current description to draw on. Kite can also track how your company appears in AI answers and check whether the description changes after your announcements go live.