Turn release notes into product announcements

Kite finds unannounced updates by matching every entry in your changelog to the blog post that announced it, if one exists. It reads your changelog or release-notes page and your blog, then checks each changelog entry against your post titles and dates.

Kite only counts a post as an announcement when it covers the same change. A post about the same part of the product but a different change doesn't count, and neither does a general roundup that never names the update. One release post can cover several entries, so a monthly "What's new" post that names five features counts as the announcement for all five.

Here's what that looks like for a fictional invoicing app called Tallyhouse. Its changelog lists twelve entries from the past three months, and its blog has two product posts. Kite matches "Custom invoice templates" to its launch post and three smaller features to a September roundup. That leaves eight entries nobody announced, including "QuickBooks sync now runs every 15 minutes instead of hourly" and "Clients can now pay invoices in 14 currencies."

If your changelog lives on a page Kite hasn't found, or you don't keep a public changelog at all, point Kite to where the record of shipped work lives. It can also read it from the tools your product team uses, as the next section explains.

Kite can read what your team shipped directly from GitHub or Linear, which catches updates that never made it into a changelog. Many teams only write release notes for the big changes, so the tools where the work happens hold a fuller record.

With the Kite GitHub App installed, Kite reads the releases, merged pull requests, and issues in the repositories you choose. A release with notes is the clearest signal. Pull request titles and descriptions fill in the rest, along with the reasoning engineers left behind.

With Linear connected, Kite reads completed issues and projects, including their descriptions and comments. A finished project in Linear often explains why the work mattered, who asked for it, and what problem it solves. That context is exactly what a good announcement needs and a one-line changelog entry leaves out.

Kite treats this record as raw material, not as copy. A pull request titled "Refactor sync worker queue" might be the reason QuickBooks sync got four times faster, and Kite's job is to connect the two and describe the result a customer would notice.

Kite decides how much attention each update deserves, because announcing everything at the same volume is nearly as bad as announcing nothing. It sorts the unannounced updates into three levels:

• Its own announcement. A blog post, social posts, and a mention in your next customer email, for changes that open a new use, reach a new kind of customer, or answer a common objection.
• A place in a roundup. A line or short paragraph in a monthly or quarterly "What's new" post, for real improvements that don't need a post of their own.
• The changelog only. Routine fixes and internal changes that customers don't need to hear about.

To make that call, Kite draws on what it already knows about your company from its research and your team's knowledge base. It looks at which customers the change affects and how many of them there are. It checks whether customers asked for it, using the feedback recorded in your knowledge base, the comments on the Linear issue, and the conversations in Slack if your team has added Kite there. It also asks whether the update strengthens a point in your positioning or closes a gap a competitor's comparison page points to.

In the Tallyhouse example, Kite gives the 14-currency payments update its own post, because it opens the product to international clients and the company's research shows "multi-currency" is a frequent question from prospects. It puts the faster QuickBooks sync and three smaller improvements into a roundup. It leaves a fix to a PDF margin in the changelog only.

Kite shows you this plan before writing anything, with a short reason next to each update. You can move an update up or down, or add context only you know, such as "Our biggest customer asked for this one, so let's make it a post."

Kite writes each announcement around what the customer can now do, not around what the engineering team built. It uses the release note, the pull request or Linear project behind it, and what it knows about your customers to explain who the change is for, the problem it solves, and how to use it.

For a feature that earns its own post, Kite usually writes:

• A blog post that opens with the customer's problem, explains the change in plain language, shows how to use it, and links to your documentation or the relevant page of your product.
• Social posts adapted to each channel, with suggested timing.
• A short section for your next customer email, or a standalone email when the update is big enough.
• A clearer changelog entry, if the original was written for engineers.

For a roundup, Kite writes one post that groups the updates by the job they help with, so a reader can skim to the part they care about. It writes in your brand's voice, using the tone and examples recorded in your knowledge base, and it keeps every claim to what the release actually does.

When a feature answers a question buyers search for, Kite can research the search demand first and shape the post so it also works as an answer to that question. Then the announcement keeps bringing in readers after launch week.

Kite publishes your announcements once you approve them. By default, it asks before publishing a page, sending an email, or posting on social media, and you approve in the conversation where the work began, in the Kite web app or in Slack. You can give Kite more autonomy later if you'd rather it publish routine roundups on its own.

On a website Kite built and hosts for you, it publishes the post and returns the live link. If your blog runs on Webflow or WordPress.com, Kite publishes through your connected account. If your site lives in a GitHub repository, Kite commits the new post to your default branch, or opens a pull request if that branch is protected. It shares the posts through your connected social accounts and returns links to each one.

After the announcements go live, Kite checks how they performed. On a site it hosts, it uses its built-in analytics to see visits to each post, where readers came from, and whether they clicked through to the product. For a site measured elsewhere, it reads the same numbers from your connected analytics product. Kite records what worked in your knowledge base, so the next round of decisions about what to announce, and how, starts from real results.

Kite can run this process on a schedule, so new updates are reviewed while the team still remembers why they shipped. You might ask Kite to check every Friday for anything that shipped that week, or on the first of each month to put together a roundup of the month's changes.

Each run starts by finding what shipped since the last one, then repeats the same steps: match it against what's been announced, decide what deserves attention, and bring you drafts to approve. Teams with Slack get the results in the channel they choose. Teams working in the Kite web app see each run as its own conversation there, or get the results by email.