# Changebot.ai > Agent-first changelog publishing. Get started for free — product and marketing teams use Changebot so customers, sales, and support can see what shipped, with hosted changelogs, widgets, custom domains, Slack publishing, MCP/API access, and paid repo-aware agent automation that can also give non-technical teams product-change context. Product changelog: https://updates.changebot.ai/changebot ## Pages - [Changebot.ai — The Agent-First Changelog](https://www.changebot.ai/): Get started for free. Product and marketing teams use Changebot so customers, sales, and support can see what shipped — with a hosted changelog, embeddable widget, custom domains, and agent-native publishing. - [Product — Agent-First Changelog Publishing](https://www.changebot.ai/product/): Publish product updates from MCP/API workflows for free, then add paid codebase integrations when you want Changebot to write updates, answer product-change questions, and automate recaps. - [Changebot Agent — Write Updates With Product Context](https://www.changebot.ai/product/agent/): Use the Changebot Agent to write customer-ready updates, brief support and sales on what changed, and publish when the answer should become a changelog post. - [Changebot MCP — Publish From Claude Code and AI Chat](https://www.changebot.ai/product/mcp/): Use Changebot through MCP-compatible AI tools to write, review, and publish changelog updates without leaving your workflow. - [Changelog Publishing — Hosted Pages, Widgets, MCP, Slack](https://www.changebot.ai/product/publishing/): Publish product updates to a hosted changelog, embeddable widget, Slack, custom domain, MCP, or API for free. - [Integrations — MCP, GitHub, Bitbucket, Slack & More](https://www.changebot.ai/product/integrations/): Changebot plugs into MCP/API publishing workflows for free, then connects to codebase tools for paid Changebot-written updates, source-aware answers, and automation. - [Problems We Solve](https://www.changebot.ai/product/problems-we-solve/): Your team ships constantly but customers have no idea. Changebot closes the gap with an agent-first changelog workflow. - [Security — Practical Controls for Agent Workflows](https://www.changebot.ai/product/security/): Read-only access, scoped permissions, encryption, audit logging, and human review for customer-facing updates. - [Why Changebot? — Proof of What Shipped](https://www.changebot.ai/solutions/product-marketing/): Product and marketing teams use Changebot to turn shipping into customer-visible proof: a hosted changelog, widget, and a record sales, support, and AI systems can use. - [Pricing — Free Publishing, $99/Repo Agent Automation](https://www.changebot.ai/pricing/): Write and publish updates for free through hosted changelogs, widgets, custom domains, Slack, MCP, and APIs. Upgrade for Changebot-written updates, source-aware answers, and automation. - [Best Changelog Software in 2026 - Changelog Tools Compared](https://www.changebot.ai/best-changelog-software/): Compare the best changelog software and changelog tools in 2026. Widget tools, feedback suites, and agent-first product update software, mapped by the job they actually do. - [Customers](https://www.changebot.ai/customers/): See how teams use Changebot to publish agent-first changelogs, keep customers informed, and turn shipping velocity into proof. ## Comparisons - [Compare Changebot](https://www.changebot.ai/compare/): Dated feature and pricing matrix across every changelog tool Changebot is compared with. - [AnnounceKit Alternative: Changebot vs AnnounceKit](https://www.changebot.ai/compare/announcekit/): An AnnounceKit alternative for changelog publishing. Compare Changebot vs AnnounceKit on hosted changelogs, widgets, custom domains, Slack, and MCP/API. Free to start. - [Beamer Alternative: Changebot vs Beamer](https://www.changebot.ai/compare/beamer/): A Beamer alternative for changelog publishing. Compare Changebot vs Beamer on hosted changelogs, widgets, custom domains, Slack, MCP/API, and no MAU billing. - [Canny Alternative: Changebot vs Canny](https://www.changebot.ai/compare/canny/): A Canny alternative for changelogs. Canny is a feedback portal with a changelog on every plan. Changebot is changelog-first: free publishing, then $99/repo for drafts from what shipped. - [Headway Alternative: Changebot vs Headway](https://www.changebot.ai/compare/headway/): A Headway alternative for changelog publishing. Compare Changebot vs Headway on hosted changelogs, widgets, custom domains, Slack, and MCP/API, then $99/repo agent automation. - [LaunchNotes Alternative: Changebot vs LaunchNotes](https://www.changebot.ai/compare/launchnotes/): A LaunchNotes alternative for changelog publishing. Compare Changebot vs LaunchNotes on hosted changelogs, widgets, custom domains, Slack, and MCP/API. Free to start. ## Glossary - [Changelog Glossary](https://www.changebot.ai/glossary/): Plain definitions of the terms that come up when teams publish product updates: changelogs, release notes, changelog widgets, llms.txt, and the Model Context Protocol. - [What is a changelog?](https://www.changebot.ai/glossary/changelog/): A changelog is a dated, public record of the changes made to a product, listed newest first. Software teams publish one so customers, sales, and support can see what shipped without asking engineering. A changelog entry usually names the change, explains who it affects, and links to documentation. - [What are release notes, and how do they differ from a changelog?](https://www.changebot.ai/glossary/release-notes/): Release notes are a written summary of what a specific release contains, published when that release ships. A changelog is the running list of those releases over time. Release notes describe one version in depth; a changelog is the archive readers scroll through. - [What is a changelog widget?](https://www.changebot.ai/glossary/changelog-widget/): A changelog widget is an embeddable component that shows recent product updates inside an application, usually behind a bell icon or a "What's new" link. It pulls from the same entries as the hosted changelog page, so one published update appears in both places. - [What is llms.txt?](https://www.changebot.ai/glossary/llms-txt/): llms.txt is a plain-text file at the root of a website that gives large language models a curated, Markdown-formatted map of the site's most useful content. It was proposed by Jeremy Howard in 2024 and is a convention, not a standard: no model is obliged to read it. - [What is MCP?](https://www.changebot.ai/glossary/mcp/): The Model Context Protocol is an open standard, introduced by Anthropic in November 2024, that lets AI assistants connect to external tools and data sources through a common interface. An MCP server exposes tools; an MCP client such as Claude Code or ChatGPT calls them on the user's behalf. ## Blog - [Blog](https://www.changebot.ai/blog/): All posts on changelog strategy, product communication, and Changebot updates. - [Changelog Best Practices: A Ten-Point Checklist](https://www.changebot.ai/blog/changelog-best-practices-checklist/): Ten checks for a changelog that customers actually read — audience, cadence, grouping, language, dates, links, feeds, discoverability, review, and machine access. - [Changelog Examples: Five Formats and What Makes Them Work](https://www.changebot.ai/blog/changelog-examples/): Five changelog formats with written-out examples — the dated feed, the grouped release, the single-feature post, the maintenance roundup, and the API changelog — and when each one fits. - [Changelog vs Release Notes: What Is the Difference?](https://www.changebot.ai/blog/changelog-vs-release-notes/): A changelog is the running dated list of what changed; release notes are the narrative for one release. Here's how the two differ in audience, format, and cadence, and when you need both. - [How to Publish a Changelog From GitHub](https://www.changebot.ai/blog/how-to-publish-a-changelog-from-github/): Four ways to turn GitHub history into a published changelog — GitHub Releases, a CHANGELOG.md file, a generator in CI, or an agent that drafts entries — and how to pick between them. - [Release Notes Template: Four Formats You Can Copy](https://www.changebot.ai/blog/release-notes-template/): Four copy-paste release notes templates — standard release, single feature launch, bug fix roundup, and breaking change — with guidance on when to use each. - [Introducing the Changebot Agent](https://www.changebot.ai/blog/introducing-the-changebot-agent/): Changebot is becoming the agent-first changelog: write, edit, review, and publish product updates from the workflow you already use. - [Publish Your Changelog From Claude Code](https://www.changebot.ai/blog/publish-your-changelog-from-claude-code/): A practical example of the Changebot MCP workflow: ask for an update, review the draft, and publish without leaving your agent surface. - [The Agent-First Changelog](https://www.changebot.ai/blog/the-agent-first-changelog/): The next changelog is not a CMS you remember to update. It is a publishing layer your agents can write to. - [I created this process and now it's eating me alive](https://www.changebot.ai/blog/i-created-this-process-and-now-its-eating-me-alive/): You championed release notes when nobody else would. Now you're the permanent owner. Here's why the 'person who cares' always gets stuck. - [AI made you ship 10x faster. Your communication didn't keep up.](https://www.changebot.ai/blog/ai-made-you-ship-10x-faster/): AI coding tools have accelerated engineering output dramatically. But nobody built the communication layer to match. The gap is widening. - [AI can't tell your biggest feature from a dependency update](https://www.changebot.ai/blog/ai-cant-tell-your-biggest-feature-from-a-dependency-update/): Generic AI tools treat all code changes equally. They over-index on PR volume, can't distinguish customer impact from internal cleanup, and the output sounds like a robot wrote it. - [Your deploy message in Slack is not a changelog](https://www.changebot.ai/blog/your-deploy-message-in-slack-is-not-a-changelog/): Developer posts 'released this morning' in Slack. A week later, nobody can find it. Here's why Slack-as-changelog fails and what to do instead. - [We are doing stuff. Trust us.](https://www.changebot.ai/blog/we-are-doing-stuff-trust-us/): Your team ships features every week. Your customers have no idea. When there's no single place to point people to, trust erodes even when the work is getting done. - [The five rewrites problem](https://www.changebot.ai/blog/the-five-rewrites-problem/): Every release cycle, the same update gets rewritten five times for five audiences. Here's why that's killing your product team's bandwidth. - [The customer always comes back](https://www.changebot.ai/blog/the-customer-always-comes-back/): SaaS customers are canceling to vibe-code their own tools. They're also coming back a month later. Here's why the build-it-yourself era is a blip, not a trend. - [The fifteen-minute illusion](https://www.changebot.ai/blog/the-fifteen-minute-illusion/): Your changelog process only takes fifteen minutes. But that number is hiding the real cost of how your team communicates what shipped. - [Proof of Shipping: The New Table Stakes for Vendor Evaluation](https://www.changebot.ai/blog/proof-of-shipping/): Prospects check your changelog before they book a demo. Investors want evidence of velocity. A stale update history says 'abandoned' louder than any pitch deck can overcome. - [What 15 hackathon apps taught us about the future of customer communication](https://www.changebot.ai/blog/what-15-hackathon-apps-taught-us/): When 15 teams at an AI hackathon independently built customer success tools, it confirmed something we've believed for a while: customer communication is the next frontier for AI. - [The changelog is always the last thing you update](https://www.changebot.ai/blog/the-changelog-is-always-the-last-thing-you-update/): Ship the code. Update the docs. Update the marketing page. Then, if there's time, update the changelog. Here's why 'afterthought' is the default and how to fix it. - [Sharing screenshots of your changelog drafts is a red flag](https://www.changebot.ai/blog/sharing-screenshots-of-your-changelog-drafts-is-a-red-flag/): When your team reviews changelog entries by taking screenshots of drafts and pasting them into tickets, the tool has become the bottleneck. - [Product Marketing Is the Ascendant Discipline in 2026](https://www.changebot.ai/blog/product-marketing-is-the-ascendant-discipline/): Top-of-funnel SEO content is dying. LLMs are the new discovery channel. The companies that win are the ones writing about what their product actually does, not chasing keywords. - [Top-of-Funnel Content Is Dead. Product Updates Are Your New Growth Channel.](https://www.changebot.ai/blog/top-of-funnel-is-dead/): Traditional SEO blog posts won't save you. In a world where prospects ask LLMs for recommendations, the companies with the most detailed product content win. - [Developers Lose 10 Hours a Week to Status Theater](https://www.changebot.ai/blog/developers-lose-10-hours-a-week-to-status-theater/): Your engineering team spends 5-10 hours every week in meetings explaining what they built. Then you wonder why they're not shipping fast enough. - [Your Commit Messages Were Never Meant for Customers](https://www.changebot.ai/blog/your-commit-messages-were-never-meant-for-customers/): The gap between what developers write in commit messages and what customers need to hear about your product is wider than you think. Here's why that matters. - [The Non-Technical Founder's Update Problem](https://www.changebot.ai/blog/the-non-technical-founders-update-problem/): You know your product is shipping. You just can't see it. When every customer update requires interrupting your engineering cofounder, most updates don't happen. - [The Year-End Review You're Dreading](https://www.changebot.ai/blog/the-year-end-review-youre-dreading/): Every January, product teams face the same grueling ritual: sifting through months of work to compile what actually shipped. There's a better way to approach year-end retrospectives. - ["I Had No Idea This Exists": The Feature Awareness Problem](https://www.changebot.ai/blog/i-had-no-idea-this-exists/): Your team shipped the feature. You announced it. And customers still don't know it exists. Here's why the gap between shipping and awareness is bigger than you think. - [Many Repositories, Many Products: The Holistic View Nobody Has](https://www.changebot.ai/blog/the-holistic-view-nobody-has/): When your product spans five repositories, three teams, and two technology stacks, no single person can see the full picture of what shipped. Here's why that's a communication crisis. - [Product Marketing Across 20 Products](https://www.changebot.ai/blog/product-marketing-across-20-products/): Most PMM advice assumes you own one product. But what happens when you're responsible for 10, 20, or 100? The playbook breaks down. Here's how to scale without losing your mind. - [The 100-Page Update Doc Nobody Reads](https://www.changebot.ai/blog/the-100-page-update-doc-nobody-reads/): Every quarter, product marketing teams assemble massive update documents for events and stakeholder reviews. They take weeks to compile, and nobody reads them end-to-end. There's a better way. - [The Meeting You Shouldn't Have to Attend](https://www.changebot.ai/blog/the-meeting-you-shouldnt-have-to-attend/): There's a difference between meetings where you contribute and meetings where you're just extracting information. Product marketers shouldn't have to join calls just to learn what shipped. - [Feeding Your AI Agents: Why Product Updates Need Structure](https://www.changebot.ai/blog/feeding-your-ai-agents-why-product-updates-need-structure/): AI-forward companies are building internal agents for sales enablement, support, and more. But these agents are starving for reliable product change data. Here's how to fix that. - [Why Your Release Notes Still Sound Like a Changelog](https://www.changebot.ai/blog/why-your-release-notes-still-sound-like-a-changelog/): Most teams list what changed. Few explain why customers should care. Here's how to transform technical changes into customer value. - [When Do You Announce a Feature That's Only 10% Rolled Out?](https://www.changebot.ai/blog/when-do-you-announce-a-feature-thats-only-10-percent-rolled-out/): Feature flags and staged rollouts create a communication timing problem. Traditional release notes assume binary shipped/not-shipped. CI/CD requires a new mental model. - [The Draft-to-Publish Workflow That Actually Works](https://www.changebot.ai/blog/the-draft-to-publish-workflow-that-actually-works/): PMs draft. Marketing refines. Here's how to automate the drafting without losing the positioning control that makes release notes effective. - [Why You Can't Vibe-Code Your Way to Good Release Communication](https://www.changebot.ai/blog/why-you-cant-vibe-code-release-communication/): Teams think they can cobble together ChatGPT + scripts + Slack bots for release updates. Here's why that approach falls apart, and what it's actually worth to solve this problem properly. - [Writing the Update Is Only Half the Battle](https://www.changebot.ai/blog/writing-the-update-is-only-half-the-battle/): Most teams think the hard part is writing product updates. The real challenge? Getting them where they need to go. - [The Vendor Security Dance: How Both Sides Can Move Faster](https://www.changebot.ai/blog/the-vendor-security-dance/): Security reviews don't have to stall deals for weeks. Here's how vendors and buyers can structure evaluations that work for security teams without killing momentum. - [Getting Paid to Build Is Easy. Getting Credit for It? Hard.](https://www.changebot.ai/blog/getting-paid-to-build-is-easy/): Your team is shipping features every week. Your customers think you haven't improved the product in months. Here's why the credit gap exists, and what it costs you. - [Five Hours Down to Five Minutes: The Monthly Recap Problem](https://www.changebot.ai/blog/from-five-hours-to-five-minutes/): Monthly product recaps shouldn't take days. Here's why they do, and how to reclaim that time. - [Why Every Engineer Hates Jira (And How We Made It Worse)](https://www.changebot.ai/blog/why-every-engineer-hates-jira/): Jira became the most hated tool in engineering because every team added their own fields and requirements. Here's how it happened and what to do instead. - [The Release Communication Death Spiral: More Meetings Won't Fix It](https://www.changebot.ai/blog/the-release-communication-death-spiral/): When teams don't know what's shipping, they add meetings, which leaves less time to document, which means even more meetings. Here's how to break the cycle. - [Why Your Bug Fixes Deserve Their Own Announcements](https://www.changebot.ai/blog/why-bug-fixes-deserve-announcements/): Most companies only announce new features. But your customers already saw the bug. Here's why you should tell them you fixed it. - [The Support Team's Secret Channel: When Your Own Team Doesn't Know What Shipped](https://www.changebot.ai/blog/the-support-teams-secret-channel/): Support teams often create workarounds just to learn about small releases. This signals a systemic communication failure that affects everyone. - [The PM Accountability Gap: Why Documentation Falls Through the Cracks](https://www.changebot.ai/blog/the-pm-accountability-gap/): Product managers hate documentation. They know it's important, but it's never urgent enough to rank highly. Here's why this gap exists and what to do about it. - [What to Ask Before Giving an AI Tool Access to Your Code](https://www.changebot.ai/blog/what-to-ask-before-giving-ai-code-access/): A vendor checklist before you grant an AI tool repo access: what they read, what they send to LLMs, secrets handling, retention, and breach response. - [Product Manager Fiction: Why Your PRDs Aren't the Source of Truth](https://www.changebot.ai/blog/product-manager-fiction/): PRDs and specs describe a future that may never exist. The code that ships is your actual tether to reality. Here's why this disconnect matters. - [The Hybrid Workplace's Hidden Product Challenge: Keeping Distributed Teams in Sync on What's Shipping](https://www.changebot.ai/blog/the-hybrid-workplaces-hidden-product-challenge/): Remote and hybrid work solved the location problem, but created a new one: how do you keep distributed teams informed about what's actually getting built? - [Signal vs. Noise: What Customers Actually Care About](https://www.changebot.ai/blog/signal-vs-noise-what-customers-care-about/): Not every code change is worth announcing. Database indexes, infrastructure tweaks, and internal refactors are valuable work but noise to customers. Here's how to filter. - [When changelogs Become Customer Retention Tools (Beyond Mere Obligations)](https://www.changebot.ai/blog/changelogs-as-customer-retention-tools/): Most companies treat changelogs as a checkbox. Smart companies use them to save at-risk accounts and prove ongoing value. Here's how. - [The PM as Automation: Why Product Managers Build Systems That Break](https://www.changebot.ai/blog/the-pm-as-automation/): PMs create bespoke spreadsheets and processes to track what's shipping. Then they become the automation themselves. Here's why that doesn't scale. - [The Missing Knowledge Graph: Why No One Knows What Shipped](https://www.changebot.ai/blog/the-missing-knowledge-graph/): Organizations have rich data in GitHub, Jira, Docs, and Slack. But none of it connects. Here's why the missing knowledge graph is your biggest communication problem. - [High-Velocity PMM Without More Meetings](https://www.changebot.ai/blog/high-velocity-pmm-without-more-meetings/): How product marketing can stay ahead of rapid engineering output without living in standups, Slack threads, or demo day. - [CodeRabbit vs Product-Aware Summaries](https://www.changebot.ai/blog/coderabbit-vs-product-aware-summaries/): Why product framing beats commit-level blurbs when support and marketing need customer impact. - [Brand-Voice-Aware AI](https://www.changebot.ai/blog/brand-voice-aware-ai/): How Changebot learns your company's voice so release updates sound like your team wrote them. - [Investor Updates From Code](https://www.changebot.ai/blog/investor-updates-from-code/): How Changebot turns your shipped code into investor-ready updates that prove progress and build confidence. - [B2C Cadence Control](https://www.changebot.ai/blog/b2c-cadence-control/): Avoiding churn by right-sizing app updates for millions of users while keeping support fully briefed. - [Backlog to Spotlight](https://www.changebot.ai/blog/from-backlog-to-spotlight/): How Changebot's Recaps and Spotlights turn buried product work into customer-ready updates. - [The Development Hell Death Spiral (and how to escape it)](https://www.changebot.ai/blog/the-development-hell-death-spiral-and-how-to-escape/): When big dev projects stall your roadmap, the real danger is the communication death spiral that follows. - [The Soul of Your Company](https://www.changebot.ai/blog/the-soul-of-your-company/): Your product announcements reveal the soul of your company—are you a slow turtle or a cool rabbit with sunglasses? - [How GitHub Squeezes The Juice From Their Updates](https://www.changebot.ai/blog/how-github-squeezes-the-juice-from-their-updates/): GitHub publishes 29 updates per month—here's how they squeeze maximum value from their changelog with relentless consistency and smart distribution. - [How Linear uses its changelog to announce product updates](https://www.changebot.ai/blog/how-linear-uses-product-updates-to-create-yell-from-the-rooftop-fans/): I analyzed 192 Linear changelog entries. They stay public, ship about 3 times a month, and explain the why. Here's what to copy. - [Changelogs: The PM's Secret Weapon](https://www.changebot.ai/blog/changelogs-the-pms-secret-weapon/): Five ways product managers turn ordinary release notes into a customer magnet that prevents churn and drives expansion revenue. - [Here's how Github uses their developers to write better changelogs](https://www.changebot.ai/blog/heres-how-github-uses-their-developers-to-write-better-changelogs/): Getting customer quotes slows down your changelog—here's how GitHub uses developer quotes to maintain speed while building trust. - [This to That](https://www.changebot.ai/blog/this-to-that/): Watch us transform minimal commit messages into compelling customer updates that actually resonate. - [How to Update Your Changelog Before a Price Increase](https://www.changebot.ai/blog/how-to-update-your-changelog-before-a-price-increase/): Raising prices with an empty changelog is asking for churn—here's how to avoid that mistake. - [Who's responsible for customer updates?](https://www.changebot.ai/blog/whos-responsible-for-customer-updates/): Your team isn't updating customers enough—here's how to figure out who should actually own this critical responsibility. - [How Cringe Should Customer Updates Be?](https://www.changebot.ai/blog/how-cringe-should-customer-updates-be/): Finding the right balance between boring corporate speak and over-the-top enthusiasm in your customer updates. - [The Art of the Update](https://www.changebot.ai/blog/the-art-of-the-update/): The complete guide to writing product updates that prevent churn, attract customers, and prove your value. ## Full content # Changebot.ai - The Agent-First Changelog URL: https://www.changebot.ai/ Description: Product and marketing teams use Changebot so customers, sales, and support can see what shipped. Hosted changelog, embeddable widget, and agent-native publishing from the tools you already use. NOW FREE MCP POWERED # The Agent-First Changelog Product and marketing teams use Changebot so customers, sales, and support can see what shipped — drafted from the agent they already use. Claude Code, ChatGPT, Slack, Codex, or the Changebot Agent. Shipping becomes customer-visible proof. In short Changebot is an agent-first changelog tool for product and marketing teams. Publishing is free: a hosted changelog page, an embeddable widget, a custom domain, Slack, and MCP/API publishing. For $99 per repository per month, the Changebot Agent reads your GitHub or Bitbucket history and drafts each update for review. Agent directly to changelog agent session $ write an update for last month Changebot Found 8 customer-facing changes. Changebot Drafted customer, support, and Slack versions. $ publish the customer version done Changelog published. Widget refreshed. → Review URL Ready ### May product update New billing exports, faster onboarding checks, and cleaner reporting filters are ready for customers. 8 changes · 3 audiences · review approved Changelog Widget Slack [Get Started for Free](https://app.changebot.ai/signup) [Choose Your Path](/start) [🛡️ Read-only access, scoped permissions, and human review Learn more →](/product/security) ## What is Changebot? Changebot is the changelog for product and marketing teams who need shipping to show up as customer-facing proof. It turns product changes into update posts that sales, support, customers, and AI systems can actually find. It's built for the product and marketing teams at software companies — the people who have to turn shipping into a story customers, sales, and support can use, not just another task to clear. Why sign in with Google? You sign in with Google to securely create and access your account without a separate password. Changebot only requests your basic profile information — your name and email — to authenticate you and set up your workspace. ### How it works 1. 1 Sign in with Google to create your account and workspace. 2. 2 Connect your repositories, or write updates in the AI tool you already use. 3. 3 Generate and review AI-drafted, customer-facing release notes. 4. 4 Publish to your hosted changelog, website widget, or Slack. ## Get Started for Free. Add Power When You Need It. 1 ![Developer shipping code with merge checkmark](/_astro/step1.p4IbPHBY_Z1yq3Qa.webp) ### Publish for Free Draft in whatever agent or chat tool you use, then publish to a hosted changelog and embeddable widget at no cost. 2 ![AI magnifying glass filtering signal from noise](/_astro/step2.4QAAN6Pk_Z1zLnj6.webp) ### Use the MCP Connect Changebot to Claude Code, ChatGPT, Slack, Codex-style tools, or your own agents so drafts can become published updates. 3 ![Code transforming into readable document](/_astro/step3.BCwATKe7_Z1fQJBu.webp) ### White-Label the Changelog Add your logo, remove Changebot branding, customize the widget, and put release notes on your own domain. 4 ![Central hub publishing to multiple channels](/_astro/step4.Dn3cyG_a_2akcoR.webp) ### Connect Your Codebase When you want deeper automation, Changebot reads GitHub or Bitbucket, finds customer value, and drafts weekly or monthly updates. ## Start Where You Are Free changelog today, deeper automation when you need it Today ### Publish your first update - Write in the Changebot Agent or your AI chat tool - Post to a hosted Changebot page - Embed the widget in your site for free Day 5 ### Make it yours - Add your brand voice and update categories - Put the changelog on your own domain - Share review links before publishing Day 30 ### Automate the cadence - Connect GitHub or Bitbucket - Ask for weekly or monthly release notes - Route updates to Slack and customer channels ## Life without Changebot vs Life with Changebot ![Workflow before Changebot](/_astro/before-changebot.CjWdDpx8_ZOOK.webp) ❌ You ship a feature. Sales is still pitching last quarter. ❌ Support finds out from the customer. ❌ Customers think nothing is happening. ❌ Competitors announce a similar feature. They get the credit. ❌ Marketing has no source of truth for what shipped. ❌ Prospects can't see proof of velocity. ![Workflow with Changebot](/_astro/after-changebot.Cl-j7s6J_np8kl.webp) ✅ You ask the agent for the update product and marketing need. ✅ Changebot turns the work into customer language. ✅ You review, edit, and approve before it goes live. ✅ Support, sales, and customers share one living changelog. Benefits ## One Record of What Shipped. Product and marketing should not lose the story of what changed. Changebot gives those teams a durable record of what shipped, so support, sales, customers, and agents work from the same source of truth. ### What Changebot Does #### Publishes From Your AI Tools Use MCP, Claude Code, ChatGPT, Slack, or your own workflow to draft the update. Changebot turns that draft into a published changelog entry for free. ★ #### Gives You a Real Changelog Start with a free hosted page, embeddable widget, custom domain, Slack publishing, and MCP/API access. → #### Understands What Shipped Upgrade to the $99/repo agent when you want Changebot to read source context, identify customer value, draft daily or weekly updates, and give support, sales, and product source-aware answers. ### The Outcomes #### Stop Copy-Pasting Between Tools Linear, Claude, Slack, and your terminal can all help write the message. Changebot is the place that actually publishes it to a durable URL. ~ #### Show Proof of Shipping Prospects, customers, and internal teams can see the steady drumbeat of what changed instead of guessing from stale docs or buried Slack messages. ↗ #### Feed Humans and Agents A structured update history helps support, sales, customers, and AI assistants answer the same question: what changed, when, and why does it matter? ★ ## What Our Customers Say > I showed someone our changelog during a demo and his jaw hit the floor when he saw we shipped 10 updates in the past 3 weeks. It's now a core part of our messaging. > > **Alkarim Lalani, CEO** at Rollout > Our new changelog has been a competitive super power for all of our portfolio companies. Now we're driving the market messaging. Changebot is the first product we install for any new acquisition. > > **Paul Lynch, CEO** at Import.io [See how teams use Changebot →](/customers) ## Frequently Asked Questions What is Changebot? Changebot is a changelog publishing tool for product and marketing teams. Publishing is free: a hosted changelog page, an embeddable widget, a custom domain, Slack distribution, and MCP/API publishing. The paid tier connects to GitHub or Bitbucket so Changebot drafts customer-facing updates from what actually shipped. How does Changebot work? Sign in with Google to create a workspace. Write updates yourself, draft them in the AI tool you already use, or connect a repository and let Changebot draft from commits, pull requests, and releases. Every update goes through draft, review, and approval before it publishes to your changelog page, widget, or Slack. Do I need to connect my code to use Changebot? No. Publishing works without any repository access: write the update yourself or push it from Claude Code, ChatGPT, Codex, or the API. Connecting GitHub or Bitbucket is only required for the paid agent features that read what shipped and draft the update for you. Which AI tools can publish to Changebot? Any MCP-compatible tool, including Claude Code, ChatGPT, Slack, Codex-style agents, and your own agents. Changebot exposes an MCP interface and an API, so the agent writes the draft and Changebot handles review, publishing, and distribution. Where do published updates go? A hosted changelog page on your own domain, an embeddable in-app widget with 15+ themes and full CSS customization, Slack, RSS and Atom feeds, webhooks, and the API. One update publishes to every destination. How is Changebot different from other changelog tools? Two ways. Publishing is free rather than the thing you pay for, and Changebot is agent-first: it is built to be written to by AI tools over MCP, and the paid agent reads your repositories to draft updates from real changes instead of only helping you edit text you already wrote. Will the updates read like AI slop? Commit messages sent straight to a language model produce unusable output, which is why Changebot builds product context before it writes: it groups related changes, identifies what is customer-facing, and drafts in your categories and voice. Every update is a draft until a human reviews and approves it. Can I see a real example? Yes. Changebot publishes its own changelog with Changebot at https://updates.changebot.ai/changebot, and the comparison pages link to specific entries as proof of individual features. ## Not ready to sign up? Sign up for our newsletter — we'll send you our (Changebot generated) updates to keep you in the loop. Subscribe # Best Changelog Software in 2026 - Changelog Tools Compared URL: https://www.changebot.ai/best-changelog-software/ Description: Compare the best changelog software and changelog tools in 2026. Widget tools, feedback suites, and agent-first product update software, mapped by the job they actually do. Last updated: 2026-09-18 Changelog Tools 2026 # Best Changelog Software in 2026 Changelog tools are not one category. Widget products help you announce updates you write by hand. Feedback suites add a changelog next to voting boards. Agent-first software drafts from what shipped. This page is a map, not a scored ranking. In short The best changelog software depends on the job. Beamer, Headway, AnnounceKit, and LaunchNotes are widget and announcement tools for updates you write by hand. Canny is a feedback suite with a changelog attached. Changebot is agent-first: free publishing, then $99 per repository for updates drafted from your commits. [How to pick a tool](#how-to-pick) [Start free](https://app.changebot.ai/signup) ## Three Jobs, Three Buckets Start with the job. Then open the comparison for the tools in that bucket. [Write it yourself ## Widget and announcement tools Right fit if you only need a widget or hosted page and will write updates by hand. Jump to tools →](#widget-tools) [Collect votes ## Feedback suites with a changelog Right fit if voting boards and a public roadmap are the job, and a changelog is a side surface. Jump to tools →](#feedback-suites) [Draft from what shipped ## Source-aware, agent-first changelog Right fit if product updates are a revenue lever and you want drafts from what shipped, or a free place to publish words you already wrote. Jump to tools →](#agent-first) ## Widget and announcement tools Hosted changelog plus an in-app widget. You write every post. Extra engagement features vary by product and plan. ### Beamer Free / $59/mo Starter User engagement platform with changelog, NPS, and feedback tools Pick Beamer if you want a user engagement platform around announcements: in-app posts plus extras such as push notifications, NPS, or feature voting. You write every update. Beamer bills by monthly active users. [Changebot vs Beamer →](/compare/beamer) ### Headway Free / $29/mo Pro Simple changelog tool for SaaS products Pick Headway if you want a simple, manual changelog. It is a hosted page and a basic widget. You write the posts. Pro starts at $29/mo. [Changebot vs Headway →](/compare/headway) ### AnnounceKit $79/mo User communication and changelog tool Pick AnnounceKit if you want a changelog and announcement widget and will write updates yourself. Segmentation and subscriber email sit on higher paid plans. Plans start at $79/mo. [Changebot vs AnnounceKit →](/compare/announcekit) ### LaunchNotes $249/mo Enterprise product communications platform with changelog, roadmap, and feedback Pick LaunchNotes if you want an enterprise product communications portal (changelog plus roadmap and feedback) and can start at $249/mo for 2 users. Updates are still written by hand. [Changebot vs LaunchNotes →](/compare/launchnotes) ## Feedback suites with a changelog The product is a feedback portal. A changelog ships on the same plan. Writing updates is still a markdown editor. ### Canny Free / $79/mo Pro yearly Feedback portal with boards, votes, a public roadmap, and a changelog Pick Canny if you need feedback boards, votes, a public roadmap, or Autopilot to capture and triage feedback. Canny includes a changelog on every plan. Autopilot does not read GitHub or Bitbucket and draft customer-facing updates. Canny bills by tracked users. [Changebot vs Canny →](/compare/canny) ## Source-aware, agent-first changelog The changelog is the product. Free publishing is the top of funnel. The paid agent reads source systems and drafts customer-facing updates. ### Changebot Free / $99/repo Agent-first changelog. Free publishing, then $99/repo for drafts from GitHub and Bitbucket. Pick Changebot if you want a hosted changelog, widget, custom domain, Slack, and MCP/API publishing for free, and you may later pay $99/repo for an agent that reads GitHub or Bitbucket and drafts customer-facing updates. Free changelog users are the top of funnel. Qualified buyers treat shipping as a revenue lever. [See pricing →](/pricing) This page maps the category by job. For a dated, feature-by-feature grid of every tool side by side, see the [changelog tool comparison matrix](/compare). Pricing and feature claims verified September 18, 2026 against each vendor's pricing page. ## Best Changelog Software: FAQ What is the best changelog software in 2026? There is no single best changelog tool, because these products do three different jobs. Pick a widget and announcement tool (Beamer, Headway, AnnounceKit, LaunchNotes) if you will write every update by hand, a feedback suite (Canny) if voting boards and a public roadmap are the real job, and agent-first software (Changebot) if you want updates drafted from what shipped. What is the difference between changelog software and a feedback tool? Changelog software publishes what already shipped to customers through a hosted page, an in-app widget, and feeds. A feedback tool collects requests and votes before anything ships. Canny is a feedback portal that includes a changelog on every plan, so teams evaluating it as a changelog are buying a feedback suite first. Is there free changelog software? Yes. Changebot publishes for free: hosted changelog, embeddable widget, custom domain, Slack publishing, RSS, and MCP/API access. Beamer, Headway, and Canny also have free tiers with limits on active users or features. The paid Changebot agent that drafts updates from GitHub or Bitbucket is $99 per repository per month. Which changelog tool writes release notes automatically? Changebot is the only tool on this page that reads GitHub or Bitbucket and drafts customer-facing updates from what shipped. The widget tools and feedback suites all give you an editor and expect a person to write each post. ## Start with a free changelog Hosted page, widget, custom domain, Slack, and MCP/API publishing are free. The agent that drafts from GitHub or Bitbucket is $99 per repo. [Get Started for Free](https://app.changebot.ai/signup) [See pricing](/pricing) # Blog URL: https://www.changebot.ai/blog/ Description: Insights on product updates and customer communication # The Blog Insights on product updates and customer communication [ ![A figure ticking neon green checkboxes on a large checklist board beside a published changelog page](/_astro/featured.DqWBfHPR_Z1qzTtR.webp) ## Changelog Best Practices: A Ten-Point Checklist Ten checks for a changelog that customers actually read — audience, cadence, grouping, language, dates, links, feeds, discoverability, review, and machine access. Brian Sierakowski September 18, 2026 ](/blog/changelog-best-practices-checklist) [ ![Five changelog page layouts displayed side by side with a figure reviewing them from a clipboard](/_astro/featured.DNaL4UI__iVC3h.webp) ## Changelog Examples: Five Formats and What Makes Them Work Five changelog formats with written-out examples — the dated feed, the grouped release, the single-feature post, the maintenance roundup, and the API changelog — and when each one fits. Brian Sierakowski September 18, 2026 ](/blog/changelog-examples) [ ![A dated changelog feed of stacked entry cards beside a single release notes document, with a figure comparing the two](/_astro/featured.8wMYqhRO_Z282BKT.webp) ## Changelog vs Release Notes: What Is the Difference? A changelog is the running dated list of what changed; release notes are the narrative for one release. Here's how the two differ in audience, format, and cadence, and when you need both. Brian Sierakowski September 18, 2026 ](/blog/changelog-vs-release-notes) [ ![A robot inspecting commit cards on a conveyor belt that delivers a published changelog page and a chat message](/_astro/featured.DWLM-wiQ_Zs6icl.webp) ## How to Publish a Changelog From GitHub Four ways to turn GitHub history into a published changelog — GitHub Releases, a CHANGELOG.md file, a generator in CI, or an agent that drafts entries — and how to pick between them. Brian Sierakowski September 18, 2026 ](/blog/how-to-publish-a-changelog-from-github) [ ![A figure fitting a green block into a dashed placeholder slot on a large template page, surrounded by completed pages](/_astro/featured.BnjobCpF_15V8LT.webp) ## Release Notes Template: Four Formats You Can Copy Four copy-paste release notes templates — standard release, single feature launch, bug fix roundup, and breaking change — with guidance on when to use each. Brian Sierakowski September 18, 2026 ](/blog/release-notes-template) [ ![AI agent icon with empty fuel gauge surrounded by disconnected data sources](/_astro/featured.SIA2wRub_Z8rzpT.webp) ## Introducing the Changebot Agent Changebot is becoming the agent-first changelog: write, edit, review, and publish product updates from the workflow you already use. Brian Sierakowski June 13, 2026 ](/blog/introducing-the-changebot-agent) [ ![Developer workflow with AI coding tools and release communication signals](/_astro/featured.KqEEKq0c_1iiJvF.webp) ## Publish Your Changelog From Claude Code A practical example of the Changebot MCP workflow: ask for an update, review the draft, and publish without leaving your agent surface. Brian Sierakowski June 13, 2026 ](/blog/publish-your-changelog-from-claude-code) [ ![A changelog sitting at the end of a long product workflow](/_astro/featured.pnGxyg_q_Z1Yu70o.webp) ## The Agent-First Changelog The next changelog is not a CMS you remember to update. It is a publishing layer your agents can write to. Brian Sierakowski June 13, 2026 ](/blog/the-agent-first-changelog) [ ![Illustration of a person tangled in vines growing from a process flowchart they originally created](/_astro/featured.B82ojyQQ_ZOls7D.webp) ## I created this process and now it's eating me alive You championed release notes when nobody else would. Now you're the permanent owner. Here's why the 'person who cares' always gets stuck. Brian Sierakowski March 9, 2026 ](/blog/i-created-this-process-and-now-its-eating-me-alive) [ ![Illustration of a rocket ship representing 10x development speed leaving behind a cyclist struggling with manual communication](/_astro/featured.B_5fYJ4c_Zenksk.webp) ## AI made you ship 10x faster. Your communication didn't keep up. AI coding tools have accelerated engineering output dramatically. But nobody built the communication layer to match. The gap is widening. Brian Sierakowski March 6, 2026 ](/blog/ai-made-you-ship-10x-faster) [ ![Illustration of a scale with AI misjudging a large dependency update as more important than a small key feature](/_astro/featured.CSim7ook_1ymztg.webp) ## AI can't tell your biggest feature from a dependency update Generic AI tools treat all code changes equally. They over-index on PR volume, can't distinguish customer impact from internal cleanup, and the output sounds like a robot wrote it. Brian Sierakowski March 3, 2026 ](/blog/ai-cant-tell-your-biggest-feature-from-a-dependency-update) [ ![Illustration of ephemeral chat messages fading away contrasted with a solid permanent changelog record](/_astro/featured.B9tC-QeF_2lqndB.webp) ## Your deploy message in Slack is not a changelog Developer posts 'released this morning' in Slack. A week later, nobody can find it. Here's why Slack-as-changelog fails and what to do instead. Brian Sierakowski February 28, 2026 ](/blog/your-deploy-message-in-slack-is-not-a-changelog) [ ![Illustration of a building bustling with activity inside but no visible signs of progress to people outside](/_astro/featured.BXBGPQ95_1jEVmG.webp) ## We are doing stuff. Trust us. Your team ships features every week. Your customers have no idea. When there's no single place to point people to, trust erodes even when the work is getting done. Brian Sierakowski February 25, 2026 ](/blog/we-are-doing-stuff-trust-us) [ ![Illustration of a single document splitting into five paths for different audiences](/_astro/featured.DJaXBpwi_2bAx0a.webp) ## The five rewrites problem Every release cycle, the same update gets rewritten five times for five audiences. Here's why that's killing your product team's bandwidth. Brian Sierakowski February 22, 2026 ](/blog/the-five-rewrites-problem) [ ![A boomerang arcing through the air, representing SaaS customers who leave and come back](/_astro/featured.xIUcbq20_daQKk.webp) ## The customer always comes back SaaS customers are canceling to vibe-code their own tools. They're also coming back a month later. Here's why the build-it-yourself era is a blip, not a trend. Brian Sierakowski February 20, 2026 ](/blog/the-customer-always-comes-back) [ ![Illustration of a stopwatch showing fifteen minutes with a hidden iceberg of context-gathering work beneath](/_astro/featured.BpK0x1Io_Z1u2DdI.webp) ## The fifteen-minute illusion Your changelog process only takes fifteen minutes. But that number is hiding the real cost of how your team communicates what shipped. Brian Sierakowski February 19, 2026 ](/blog/the-fifteen-minute-illusion) [ ![Two changelogs side by side: a vibrant stack of update cards with a verification badge versus a sparse faded timeline with cobwebs](/_astro/featured.BBaEHGWA_1EbBq1.webp) ## Proof of Shipping: The New Table Stakes for Vendor Evaluation Prospects check your changelog before they book a demo. Investors want evidence of velocity. A stale update history says 'abandoned' louder than any pitch deck can overcome. Brian Sierakowski February 17, 2026 ](/blog/proof-of-shipping) [ ![A grid of hackathon project demos showing various customer communication tools](/_astro/featured.BlOmFd8H_Z1luqYv.webp) ## What 15 hackathon apps taught us about the future of customer communication When 15 teams at an AI hackathon independently built customer success tools, it confirmed something we've believed for a while: customer communication is the next frontier for AI. Brian Sierakowski February 17, 2026 ](/blog/what-15-hackathon-apps-taught-us) [ ![Illustration of a priority stack with changelog at the bottom collecting dust](/_astro/featured.pnGxyg_q_Z1Yu70o.webp) ## The changelog is always the last thing you update Ship the code. Update the docs. Update the marketing page. Then, if there's time, update the changelog. Here's why 'afterthought' is the default and how to fix it. Brian Sierakowski February 16, 2026 ](/blog/the-changelog-is-always-the-last-thing-you-update) [ ![Illustration of a clunky workflow with screenshots being pasted between a changelog editor, a capture frame, and ticket comments](/_astro/featured.CgeNT2Li_Z1MiiNF.webp) ## Sharing screenshots of your changelog drafts is a red flag When your team reviews changelog entries by taking screenshots of drafts and pasting them into tickets, the tool has become the bottleneck. Brian Sierakowski February 13, 2026 ](/blog/sharing-screenshots-of-your-changelog-drafts-is-a-red-flag) [ ![Product content cards ascending a staircase into a spotlight while generic SEO blog posts fade below, with AI chat bubbles at the top](/_astro/featured.CzAQQKXs_ZnHJua.webp) ## Product Marketing Is the Ascendant Discipline in 2026 Top-of-funnel SEO content is dying. LLMs are the new discovery channel. The companies that win are the ones writing about what their product actually does, not chasing keywords. Brian Sierakowski February 12, 2026 ](/blog/product-marketing-is-the-ascendant-discipline) [ ![A crumbling marketing funnel contrasted with product update cards flowing into an AI chat bubble that connects to customers](/_astro/featured.cH0vstkd_ZrwjV1.webp) ## Top-of-Funnel Content Is Dead. Product Updates Are Your New Growth Channel. Traditional SEO blog posts won't save you. In a world where prospects ask LLMs for recommendations, the companies with the most detailed product content win. Brian Sierakowski February 7, 2026 ](/blog/top-of-funnel-is-dead) [ ![Clock split between productive coding and wasted status meetings, with a chain of figures passing information in a telephone game](/_astro/featured.KqEEKq0c_1iiJvF.webp) ## Developers Lose 10 Hours a Week to Status Theater Your engineering team spends 5-10 hours every week in meetings explaining what they built. Then you wonder why they're not shipping fast enough. Brian Sierakowski February 2, 2026 ](/blog/developers-lose-10-hours-a-week-to-status-theater) [ ![Terminal with raw commit messages transforming through gears into a polished customer announcement card](/_astro/featured.By65PXk2_1O2PkY.webp) ## Your Commit Messages Were Never Meant for Customers The gap between what developers write in commit messages and what customers need to hear about your product is wider than you think. Here's why that matters. Brian Sierakowski January 28, 2026 ](/blog/your-commit-messages-were-never-meant-for-customers) [ ![Split illustration showing engineering artifacts on one side and a polished newsletter on the other, with a figure bridging the gap](/_astro/featured.EnJOzac9_ZxUHyI.webp) ## The Non-Technical Founder's Update Problem You know your product is shipping. You just can't see it. When every customer update requires interrupting your engineering cofounder, most updates don't happen. Brian Sierakowski January 23, 2026 ](/blog/the-non-technical-founders-update-problem) [ ![Illustration contrasting chaotic year-end data excavation with organized curation, showing scattered documents becoming a clean summary report](/_astro/featured.DfA7R9PO_Z1X25K0.webp) ## The Year-End Review You're Dreading Every January, product teams face the same grueling ritual: sifting through months of work to compile what actually shipped. There's a better way to approach year-end retrospectives. Brian Sierakowski January 19, 2026 ](/blog/the-year-end-review-youre-dreading) [ ![Illustration showing a communication gap between a product team shipping features and customers unaware of them, with a changelog bridge spanning the gap](/_astro/featured.Zcxg6EH4_Z18mJ15.webp) ## "I Had No Idea This Exists": The Feature Awareness Problem Your team shipped the feature. You announced it. And customers still don't know it exists. Here's why the gap between shipping and awareness is bigger than you think. Brian Sierakowski January 15, 2026 ](/blog/i-had-no-idea-this-exists) [ ![Illustration showing multiple repository sources converging from fragmented views into one unified holistic dashboard](/_astro/featured.Bvanj-gv_2j9J3g.webp) ## Many Repositories, Many Products: The Holistic View Nobody Has When your product spans five repositories, three teams, and two technology stacks, no single person can see the full picture of what shipped. Here's why that's a communication crisis. Brian Sierakowski January 13, 2026 ](/blog/the-holistic-view-nobody-has) [ ![Single figure with radiating connections to many product icons showing coverage spreading thin](/_astro/featured.3_OAoZzT_IvMzE.webp) ## Product Marketing Across 20 Products Most PMM advice assumes you own one product. But what happens when you're responsible for 10, 20, or 100? The playbook breaks down. Here's how to scale without losing your mind. Brian Sierakowski January 11, 2026 ](/blog/product-marketing-across-20-products) [ ![Towering stack of documents with scattered papers versus a clean tablet showing a concise summary](/_astro/featured.Jw8Dybi8_1VToof.webp) ## The 100-Page Update Doc Nobody Reads Every quarter, product marketing teams assemble massive update documents for events and stakeholder reviews. They take weeks to compile, and nobody reads them end-to-end. There's a better way. Brian Sierakowski January 9, 2026 ](/blog/the-100-page-update-doc-nobody-reads) [ ![Calendar with meeting blocks contrasted with automatic notification feed](/_astro/featured.DB1UC68X_Z1mHNa7.webp) ## The Meeting You Shouldn't Have to Attend There's a difference between meetings where you contribute and meetings where you're just extracting information. Product marketers shouldn't have to join calls just to learn what shipped. Brian Sierakowski January 7, 2026 ](/blog/the-meeting-you-shouldnt-have-to-attend) [ ![AI agent icon with empty fuel gauge surrounded by disconnected data sources](/_astro/featured.SIA2wRub_Z8rzpT.webp) ## Feeding Your AI Agents: Why Product Updates Need Structure AI-forward companies are building internal agents for sales enablement, support, and more. But these agents are starving for reliable product change data. Here's how to fix that. Brian Sierakowski January 5, 2026 ](/blog/feeding-your-ai-agents-why-product-updates-need-structure) [ ![Transformation from dry technical changelog on the left to customer-friendly release notes on the right, connected by an arrow](/_astro/featured.MHF0C3j5_Z1eM9v8.webp) ## Why Your Release Notes Still Sound Like a Changelog Most teams list what changed. Few explain why customers should care. Here's how to transform technical changes into customer value. Brian Sierakowski January 4, 2026 ](/blog/why-your-release-notes-still-sound-like-a-changelog) [ ![Staged rollout progress bar with megaphone icons at varying opacity and a question mark over middle stages representing communication timing uncertainty](/_astro/featured.Bbll_nbw_1QIox3.webp) ## When Do You Announce a Feature That's Only 10% Rolled Out? Feature flags and staged rollouts create a communication timing problem. Traditional release notes assume binary shipped/not-shipped. CI/CD requires a new mental model. Brian Sierakowski January 2, 2026 ](/blog/when-do-you-announce-a-feature-thats-only-10-percent-rolled-out) [ ![Three-stage workflow showing automation generating a draft, a human refining it with editing marks, and the polished document flowing to multiple distribution channels](/_astro/featured.D20IvKdv_ZdCK6e.webp) ## The Draft-to-Publish Workflow That Actually Works PMs draft. Marketing refines. Here's how to automate the drafting without losing the positioning control that makes release notes effective. Brian Sierakowski December 31, 2025 ](/blog/the-draft-to-publish-workflow-that-actually-works) [ ![Cobbled-together system with tangled wires and broken connections falling apart, contrasted with a clean integrated system](/_astro/featured.DHYFSHki_kV9vM.webp) ## Why You Can't Vibe-Code Your Way to Good Release Communication Teams think they can cobble together ChatGPT + scripts + Slack bots for release updates. Here's why that approach falls apart, and what it's actually worth to solve this problem properly. Brian Sierakowski December 29, 2025 ](/blog/why-you-cant-vibe-code-release-communication) [ ![Document in center with distribution arrows branching to channel icons, some reaching destinations and others fading or breaking midway](/_astro/featured.BAgALkvy_Z1gLDCJ.webp) ## Writing the Update Is Only Half the Battle Most teams think the hard part is writing product updates. The real challenge? Getting them where they need to go. Brian Sierakowski December 27, 2025 ](/blog/writing-the-update-is-only-half-the-battle) [ ![Two figures meeting on a bridge representing vendor and buyer collaboration in security reviews, with documentation and checkpoints leading to a handshake](/_astro/featured.D2Gpveqm_Z2gacfK.webp) ## The Vendor Security Dance: How Both Sides Can Move Faster Security reviews don't have to stall deals for weeks. Here's how vendors and buyers can structure evaluations that work for security teams without killing momentum. Brian Sierakowski December 25, 2025 ](/blog/the-vendor-security-dance) [ ![Iceberg visualization showing a small visible tip above the waterline with a few feature cards, and a massive collection of code commits, bug fixes, and shipped work hidden below the surface](/_astro/featured.BbJqLC4p_sDNm9.webp) ## Getting Paid to Build Is Easy. Getting Credit for It? Hard. Your team is shipping features every week. Your customers think you haven't improved the product in months. Here's why the credit gap exists, and what it costs you. Brian Sierakowski December 23, 2025 ](/blog/getting-paid-to-build-is-easy) [ ![Illustration showing scattered Jira tickets, GitHub PRs and Slack messages flowing through a funnel into a clean summary dashboard, representing the transformation from chaotic manual recaps to streamlined automation](/_astro/featured.0eHPIBRu_Z2fRlXi.webp) ## Five Hours Down to Five Minutes: The Monthly Recap Problem Monthly product recaps shouldn't take days. Here's why they do, and how to reclaim that time. Brian Sierakowski December 22, 2025 ](/blog/from-five-hours-to-five-minutes) [ ![Illustration of a developer silhouette overwhelmed by form fields and checkboxes, representing Jira bureaucracy](/_astro/featured.zSOk5WaU_Zuz8Rs.webp) ## Why Every Engineer Hates Jira (And How We Made It Worse) Jira became the most hated tool in engineering because every team added their own fields and requirements. Here's how it happened and what to do instead. Brian Sierakowski December 22, 2025 ](/blog/why-every-engineer-hates-jira) [ ![A spiral vortex with calendar and meeting icons multiplying, representing the destructive cycle of meeting overload](/_astro/featured.B-yMVFGy_Ziwp4x.webp) ## The Release Communication Death Spiral: More Meetings Won't Fix It When teams don't know what's shipping, they add meetings, which leaves less time to document, which means even more meetings. Here's how to break the cycle. Brian Sierakowski December 21, 2025 ](/blog/the-release-communication-death-spiral) [ ![Bug being squashed with checkmark on one side, megaphone broadcasting the fix on the other](/_astro/featured.35EeLAp5_ZSOSqX.webp) ## Why Your Bug Fixes Deserve Their Own Announcements Most companies only announce new features. But your customers already saw the bug. Here's why you should tell them you fixed it. Brian Sierakowski December 20, 2025 ](/blog/why-bug-fixes-deserve-announcements) [ ![Support agent desk showing contrast between sparse official inbox and overflowing secret channel sidebar with sticky notes and chat messages about small fixes](/_astro/featured.BIG96wNS_hwOOd.webp) ## The Support Team's Secret Channel: When Your Own Team Doesn't Know What Shipped Support teams often create workarounds just to learn about small releases. This signals a systemic communication failure that affects everyone. Brian Sierakowski December 17, 2025 ](/blog/the-support-teams-secret-channel) [ ![A visual gap showing code and shipped features on one side, empty documents and waiting stakeholders on the other](/_astro/featured.DCbRX0f0_Z2oXN2c.webp) ## The PM Accountability Gap: Why Documentation Falls Through the Cracks Product managers hate documentation. They know it's important, but it's never urgent enough to rank highly. Here's why this gap exists and what to do about it. Brian Sierakowski December 16, 2025 ](/blog/the-pm-accountability-gap) [ ![Secure code repository connected by a gated pathway to an AI brain symbol with security checklist](/_astro/featured.CBC49yCi_Z2pLeJo.webp) ## What to Ask Before Giving an AI Tool Access to Your Code A vendor checklist before you grant an AI tool repo access: what they read, what they send to LLMs, secrets handling, retention, and breach response. Brian Sierakowski December 14, 2025 ](/blog/what-to-ask-before-giving-ai-code-access) [ ![Faded spec document floating like a dream contrasted with solid grounded code blocks](/_astro/featured.BvadUFir_ZP8ntR.webp) ## Product Manager Fiction: Why Your PRDs Aren't the Source of Truth PRDs and specs describe a future that may never exist. The code that ships is your actual tether to reality. Here's why this disconnect matters. Brian Sierakowski December 10, 2025 ](/blog/product-manager-fiction) [ ![Globe with location pins connected by information streams, showing fragmented communication flowing into unified channels](/_astro/featured.DPkoJhbE_f6375.webp) ## The Hybrid Workplace's Hidden Product Challenge: Keeping Distributed Teams in Sync on What's Shipping Remote and hybrid work solved the location problem, but created a new one: how do you keep distributed teams informed about what's actually getting built? Brian Sierakowski December 10, 2025 ](/blog/the-hybrid-workplaces-hidden-product-challenge) [ ![Illustration of a filter separating a chaotic stream of technical items into two paths: a highlighted signal path with key updates flowing to customers, and a faded noise path with internal changes](/_astro/featured.CAUlgTrj_Z1NRQ7H.webp) ## Signal vs. Noise: What Customers Actually Care About Not every code change is worth announcing. Database indexes, infrastructure tweaks, and internal refactors are valuable work but noise to customers. Here's how to filter. Brian Sierakowski December 7, 2025 ](/blog/signal-vs-noise-what-customers-care-about) [ ![Illustration of changelog entries flowing toward a customer, with retention icons like circular arrows and a shield, representing changelogs as customer retention tools](/_astro/featured.nfffnZlS_ZeEl6h.webp) ## When changelogs Become Customer Retention Tools (Beyond Mere Obligations) Most companies treat changelogs as a checkbox. Smart companies use them to save at-risk accounts and prove ongoing value. Here's how. Brian Sierakowski December 5, 2025 ](/blog/changelogs-as-customer-retention-tools) [ ![Silhouette trapped in gears versus silhouette overseeing automated machinery](/_astro/featured.MRbH_XSJ_1AN4CC.webp) ## The PM as Automation: Why Product Managers Build Systems That Break PMs create bespoke spreadsheets and processes to track what's shipping. Then they become the automation themselves. Here's why that doesn't scale. Brian Sierakowski December 3, 2025 ](/blog/the-pm-as-automation) [ ![Disconnected tool icons unified by a central code node forming a knowledge graph](/_astro/featured.WuaH5QsV_zWm7f.webp) ## The Missing Knowledge Graph: Why No One Knows What Shipped Organizations have rich data in GitHub, Jira, Docs, and Slack. But none of it connects. Here's why the missing knowledge graph is your biggest communication problem. Brian Sierakowski December 1, 2025 ](/blog/the-missing-knowledge-graph) [ ![Product marketer watching a fast-moving launch train while sipping coffee](/_astro/featured.B6sNec3O_1cmXJt.webp) ## High-Velocity PMM Without More Meetings How product marketing can stay ahead of rapid engineering output without living in standups, Slack threads, or demo day. Brian Sierakowski November 25, 2025 ](/blog/high-velocity-pmm-without-more-meetings) [ ![Two paths from code to customer: raw commits vs product-aware summaries](/_astro/featured.jPjj9por_1t7ART.webp) ## CodeRabbit vs Product-Aware Summaries Why product framing beats commit-level blurbs when support and marketing need customer impact. Brian Sierakowski November 15, 2025 ](/blog/coderabbit-vs-product-aware-summaries) [ ![AI tailoring release notes to a brand's voice](/_astro/featured.DK4zUq--_EqyVp.webp) ## Brand-Voice-Aware AI How Changebot learns your company's voice so release updates sound like your team wrote them. Brian Sierakowski July 29, 2025 ](/blog/brand-voice-aware-ai) [ ![Five concise bullets emerging from a stream of code updates for investors](/_astro/featured.Cwez3cEd_1CUjj.webp) ## Investor Updates From Code How Changebot turns your shipped code into investor-ready updates that prove progress and build confidence. Brian Sierakowski July 22, 2025 ](/blog/investor-updates-from-code) [ ![B2C update dial controlling frequency with a support team in the loop](/_astro/featured.Dl8PtQNd_Z1MDKxB.webp) ## B2C Cadence Control Avoiding churn by right-sizing app updates for millions of users while keeping support fully briefed. Brian Sierakowski June 24, 2025 ](/blog/b2c-cadence-control) [ ![A spotlight shining on a changelog entry rising from a backlog pile](/_astro/featured.B3h1Juci_Z25VpNU.webp) ## Backlog to Spotlight How Changebot's Recaps and Spotlights turn buried product work into customer-ready updates. Brian Sierakowski June 3, 2025 ](/blog/from-backlog-to-spotlight) [ ![The Development Hell Death Spiral (and how to escape)](/_astro/featured.DvQdHFZo_1Pt8Pv.webp) ## The Development Hell Death Spiral (and how to escape it) When big dev projects stall your roadmap, the real danger is the communication death spiral that follows. Brian Sierakowski May 19, 2025 ](/blog/the-development-hell-death-spiral-and-how-to-escape) [ ![The Soul of Your Company](/_astro/featured.DEptH9Vf_1UbRzh.webp) ## The Soul of Your Company Your product announcements reveal the soul of your company—are you a slow turtle or a cool rabbit with sunglasses? Brian Sierakowski May 15, 2025 ](/blog/the-soul-of-your-company) [ ![How GitHub Squeezes The Juice From Their Updates](/_astro/featured.DhPnM86N_Mlc23.webp) ## How GitHub Squeezes The Juice From Their Updates GitHub publishes 29 updates per month—here's how they squeeze maximum value from their changelog with relentless consistency and smart distribution. Brian Sierakowski March 7, 2025 ](/blog/how-github-squeezes-the-juice-from-their-updates) [ ![How Linear uses product updates to create yell-from-the-rooftop fans](/_astro/featured.vTn5qUMc_g0iEK.webp) ## How Linear uses its changelog to announce product updates I analyzed 192 Linear changelog entries. They stay public, ship about 3 times a month, and explain the why. Here's what to copy. Brian Sierakowski March 7, 2025 ](/blog/how-linear-uses-product-updates-to-create-yell-from-the-rooftop-fans) [ ![Changelogs: The PM's Secret Weapon](/_astro/featured.BjQbr1-X_Z1TFCBk.webp) ## Changelogs: The PM's Secret Weapon Five ways product managers turn ordinary release notes into a customer magnet that prevents churn and drives expansion revenue. Brian Sierakowski December 20, 2024 ](/blog/changelogs-the-pms-secret-weapon) [ ![Here's how Github uses their developers to write better changelogs](/_astro/featured.Bg_Rsrbv_12IQ7i.webp) ## Here's how Github uses their developers to write better changelogs Getting customer quotes slows down your changelog—here's how GitHub uses developer quotes to maintain speed while building trust. Brian Sierakowski December 3, 2024 ](/blog/heres-how-github-uses-their-developers-to-write-better-changelogs) [ ![This to That](/_astro/featured.BpVLW6Lg_ZPjDg8.webp) ## This to That Watch us transform minimal commit messages into compelling customer updates that actually resonate. Brian Sierakowski September 2, 2024 ](/blog/this-to-that) [ ![How to Update Your Changelog Before a Price Increase](/_astro/featured.Cw1e1wEe_ZgXGKw.webp) ## How to Update Your Changelog Before a Price Increase Raising prices with an empty changelog is asking for churn—here's how to avoid that mistake. Brian Sierakowski August 19, 2024 ](/blog/how-to-update-your-changelog-before-a-price-increase) [ ![Who's responsible for customer updates?](/_astro/featured.BdhqYxGa_YAdge.webp) ## Who's responsible for customer updates? Your team isn't updating customers enough—here's how to figure out who should actually own this critical responsibility. Brian Sierakowski July 15, 2024 ](/blog/whos-responsible-for-customer-updates) [ ![Here's how Github uses their developers to write better changelogs](/_astro/featured.CJmKqClh_Z2cxQmf.webp) ## How Cringe Should Customer Updates Be? Finding the right balance between boring corporate speak and over-the-top enthusiasm in your customer updates. Brian Sierakowski June 3, 2024 ](/blog/how-cringe-should-customer-updates-be) [ ![The Art of the Update](/_astro/featured.R4nmcstn_sXp31.webp) ## The Art of the Update The complete guide to writing product updates that prevent churn, attract customers, and prove your value. Brian Sierakowski March 25, 2024 ](/blog/the-art-of-the-update) # AI can't tell your biggest feature from a dependency update URL: https://www.changebot.ai/blog/ai-cant-tell-your-biggest-feature-from-a-dependency-update/ Description: Generic AI tools treat all code changes equally. They over-index on PR volume, can't distinguish customer impact from internal cleanup, and the output sounds like a robot wrote it. Last updated: 2026-03-03 Best Practices # AI can't tell your biggest feature from a dependency update [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder March 3, 2026 4 min read ![Illustration of a scale with AI misjudging a large dependency update as more important than a small key feature](/_astro/featured.CSim7ook_1ymztg.webp) A product lead at a developer tools company told us about the time he tried using AI to speed up his changelog. He pointed it at a quarter’s worth of PRs and asked for a summary of what shipped. The AI looked at the PR volume and decided the most important thing that quarter was a dependency update. Granted, a massive dependency update with forty+ PRs and tons of code changes, but plainly _not_ the headline feature for a whole quarter of work. The migration was pure infrastructure, critical internally, but ideally should be invisible externally (otherwise they did something wrong). Of course the three PRs that actually did introduce major new product capability got a passing mention at the bottom. ## Volume is not importance Generic AI tools have a fundamental problem when it comes to changelogs: they treat all code changes equally. More PRs means more important, more lines changed means more significant, and more commits means more worth talking about. That’s the opposite of how customer communication works. The change that matters most to customers might be a single commit that fixes a billing display bug. The change that matters least might be a month-long infrastructure project with hundreds of commits. Without product context, AI has no way to tell the difference. It can read the code and summarize what changed technically, but what it can’t do is judge whether a customer would care. ## The prioritization gap The PM told us his team intentionally structures their public changelog to always lead with the stuff that benefits customers. It goes: - Major features in the first paragraph, then - improvements get the second most prominent placement, then - bug fixes that customers reported. The “internal work”, migrations, dependency updates, and refactors either gets a brief mention at the bottom or gets left out entirely. That prioritization requires judgment: knowing which changes customers are actually going to see, which changes fix bugs that customers have open tickets for, and which feature improvements are worth announcing versus which ones just need to work quietly in the background. When he tried ChatGPT, the output was technically accurate but strategically useless. The AI had no sense of customer impact, no awareness of what matters to the audience. He spent more time restructuring and rewriting the AI’s output than it would have taken to write from scratch. ## The voice problem Even when you point AI at the right changes, there’s a second issue: the output sounds like AI. “We’re excited to announce” followed by feature descriptions that could be about any product. The PM characterized the writing as “disingenuous.” His team’s changelog has a specific tone since they’re selling to developers, it needed to be direct, technical, and honest. The AI’s version sounded like a press release from a company trying too hard. This isn’t just an aesthetic complaint. Customers can tell when content is AI-generated, and for a developer tools company, authenticity matters. Your changelog is a direct line to your most engaged users. If it reads like a marketing bot wrote it, you’ve damaged trust with the exact people who care the most. ## The prompt engineering trap His next attempt was the obvious: “fix the prompts.” Try giving the AI more context, tell it explicitly which changes matter, specify the characteristics of the tone, and then provide examples of both good and bad updates. Teams try this, and it works… kind of. But even when the output is acceptable, now you’re spending time that you would have spent writing futzing with the prompts instead. I’m a bit of a prompt futzer myself, but if you’re manually providing all the context that makes a good changelog, customer impact, prioritization, voice… at some point the effort to manage the AI exceeds the effort to just write the changelog yourself. And that’s how we wound up on the call, his conclusion is that with all the information at his fingertips he could write a _killer_ update “two, three hours,” so the hours of data wrangling, guess and check, editing, and the still needing to do all the sharing manually wasn’t worth it. ## What “AI-powered” should mean The problem isn’t “AI is bad,” but is rather the nature of using generic AI to solve an “Expert problem.” A general-purpose language model doesn’t know your product, your customers, or your voice. It doesn’t know that a migration is internal work. It doesn’t know that three PRs matter more than forty. It doesn’t know that your changelog should sound direct and technical, not breathless and generic. This is all captured in the expertise of your product managers and product marketers (if you’re lucky enough to have dedicated product marketers!) Tools built for the hands of these experts solve the problem differently. Instead of asking you to provide context through prompts, they build context from your actual workflow, commit messages, PR descriptions, ticket metadata, historical changelog entries. They learn what your team considers customer-facing versus internal. They match your existing voice instead of defaulting to AI-speak. Our goal isn’t to remove the human from the changelog. It’s to handle the parts that don’t require human judgment, like aggregation, categorization, and first-draft generation, so the human can focus on the parts that do: prioritization, framing, and making sure the right message reaches the right audience. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # AI made you ship 10x faster. Your communication didn't keep up. URL: https://www.changebot.ai/blog/ai-made-you-ship-10x-faster/ Description: AI coding tools have accelerated engineering output dramatically. But nobody built the communication layer to match. The gap is widening. Last updated: 2026-03-06 Best Practices # AI made you ship 10x faster. Your communication didn't keep up. [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder March 6, 2026 4 min read ![Illustration of a rocket ship representing 10x development speed leaving behind a cyclist struggling with manual communication](/_astro/featured.B_5fYJ4c_Zenksk.webp) A product marketing lead introduced us to his VP of Product recently. His pitch: “I thought you guys would get along. Almost like talking to the same person.” He was right. Within minutes she was describing the exact problem we hear on every call. Her team is shipping more than ever. GitHub Copilot, AI-assisted code review, better tooling across the board. Engineering output has legitimately accelerated. The release notes process? Still manual. Still the same person going through Jira one by one. Still the same copy/paste workflow from two (or ten) years ago. ## The asymmetric acceleration The AI conversation in software has been almost entirely about building: faster coding, better code review, automated testing, AI pair programming. Every stage of the development pipeline has either gotten faster, and there’s 300 more teams actively working on making our developers lives even better. The communication pipeline, though (the whole thing where you actually tell customers what you’re doing), hasn’t changed at all. Same Jira ticket to doc workflow. Same manual translation turning technical language into customer language. Same person writing the same update five different ways for five different audiences. When you ship once a month the communication step is an annoying but manageable process. When AI-assisted development pushes your output to the point where you’re shipping constantly, truly continuous integration, the communication burden doesn’t just grow linearly. More changes mean more translation work, more distribution, more people asking “what did you release?” ## The irony The teams using AI to ship faster are often the same teams whose release communication is most behind. Not because they don’t care, but because the communication work scales with output… and output just went through the damn roof! A VP of Product put it to us directly: “We want to do more, but we can’t get to it because we’re stretched so thin.” Her team of two and a half people was already struggling with bi-weekly releases. Now they’re shipping more per cycle, the ticket volume is higher, and the communication process takes the same amount of time per item it always has. AI made the building faster… but has made the communication bottlenecks even worse. The result is obvious, predictable, and frustrating. Support asks in Slack what shipped, then leadership schedules more meetings to stay informed. Customers don’t hear about fixes because marketing has nothing to work with. The gap between what’s getting built and what’s getting communicated is wider than it’s ever been. ## Why “just use ChatGPT” doesn’t work The obvious response: if AI made building faster, use AI to make communication faster too. Paste your Jira tickets into ChatGPT and get release notes out. Teams try this, but it doesn’t work for the same reason a raw Jira export doesn’t work. The problem goes beyond generating text, you need the right text for the right audience with the right context. A Jira ticket says “fixed null pointer exception in billing module.” ChatGPT can rewrite that in friendlier language. What it can’t do (without another 40 hours of your time) is know that this fix affects invoice display for a specific customer segment, that support has three open tickets about it, that marketing shouldn’t broadcast it publicly because it implies the feature had problems, and that leadership needs to know because it blocked a renewal. That context lives in people’s heads. Until it’s captured in a system, no amount of prompt engineering gets you there. ## The widening gap is a strategic problem This isn’t just an operational inconvenience. The gap between shipping velocity and communication velocity has real business consequences. Customers churn because they think the product stopped improving. In reality, the team shipped 30 improvements last quarter… they just didn’t tell anyone (so can you blame the customers?) A product lead told us her team doesn’t want to broadcast certain fixes publicly because it’d advertise that the feature had problems, but the customers affected by those bugs would love to know they’re fixed. That’s a nuance / people / strategy problem, not a text generation problem. Support teams get blindsided, and in a world of public Slack channels, that embarrassment is visible to the whole company. New support hires are especially vulnerable because they lack the institutional context to know what shipped and what matters. Renewals get harder. Price increases feel unjustified. Prospects can’t find evidence of shipping velocity. All because the communication layer is still running at 2024 speed while the engineering layer is running at 2026 speed. ## The missing tool category We’ve invested massively in making developers faster. IDEs, CI/CD, testing frameworks, AI copilots. The tooling stack for building software is deep and mature. The tooling stack for communicating what you built? A Jira export and a Google Doc. That asymmetry is the opportunity. Not to add more AI to the building side, but to bring the communication side up to the same level. To make translating code into customer language as automated as translating code into deployed product. The teams that figure this out first will have a structural advantage. Not because they ship more, but because their customers, support teams, and leadership actually know what they shipped. ## The agent-first changelog The missing category is not just “AI release notes.” Teams already have AI tools that can summarize text. What they need is the workflow around the summary: review, audience-specific edits, approval, and publishing to a changelog customers can actually find. That is what an agent-first changelog does. You ask for the update in the agent surface where the work already happens. Changebot helps draft and revise it. Then the approved version lands on a hosted changelog, widget, Slack channel, custom domain, or API. The communication layer catches up when publishing is part of the agent workflow, not a separate chore after the AI draft is done. * * * If your engineering team is shipping faster than your communication can keep up, [start free](https://app.changebot.ai/signup) and publish your first update to a hosted changelog. For the MCP workflow, see how to [publish from Claude Code](/blog/publish-your-changelog-from-claude-code). [← Back to Blog](/blog) # Brian Sierakowski - Founder at Changebot URL: https://www.changebot.ai/blog/authors/brian-sierakowski/ Description: Brian Sierakowski is Founder at Changebot and writes about changelogs, release notes, and product communication. ![Brian Sierakowski](/_astro/brian-sierakowski.CVzujm3w_1gel5M.webp) # Brian Sierakowski Founder, Changebot Brian Sierakowski is Founder at Changebot and writes about changelogs, release notes, and product communication. ## Posts by Brian Sierakowski [ ![A figure ticking neon green checkboxes on a large checklist board beside a published changelog page](/_astro/featured.DqWBfHPR_Z1qzTtR.webp) ## Changelog Best Practices: A Ten-Point Checklist Ten checks for a changelog that customers actually read — audience, cadence, grouping, language, dates, links, feeds, discoverability, review, and machine access. Brian Sierakowski September 18, 2026 ](/blog/changelog-best-practices-checklist) [ ![Five changelog page layouts displayed side by side with a figure reviewing them from a clipboard](/_astro/featured.DNaL4UI__iVC3h.webp) ## Changelog Examples: Five Formats and What Makes Them Work Five changelog formats with written-out examples — the dated feed, the grouped release, the single-feature post, the maintenance roundup, and the API changelog — and when each one fits. Brian Sierakowski September 18, 2026 ](/blog/changelog-examples) [ ![A dated changelog feed of stacked entry cards beside a single release notes document, with a figure comparing the two](/_astro/featured.8wMYqhRO_Z282BKT.webp) ## Changelog vs Release Notes: What Is the Difference? A changelog is the running dated list of what changed; release notes are the narrative for one release. Here's how the two differ in audience, format, and cadence, and when you need both. Brian Sierakowski September 18, 2026 ](/blog/changelog-vs-release-notes) [ ![A robot inspecting commit cards on a conveyor belt that delivers a published changelog page and a chat message](/_astro/featured.DWLM-wiQ_Zs6icl.webp) ## How to Publish a Changelog From GitHub Four ways to turn GitHub history into a published changelog — GitHub Releases, a CHANGELOG.md file, a generator in CI, or an agent that drafts entries — and how to pick between them. Brian Sierakowski September 18, 2026 ](/blog/how-to-publish-a-changelog-from-github) [ ![A figure fitting a green block into a dashed placeholder slot on a large template page, surrounded by completed pages](/_astro/featured.BnjobCpF_15V8LT.webp) ## Release Notes Template: Four Formats You Can Copy Four copy-paste release notes templates — standard release, single feature launch, bug fix roundup, and breaking change — with guidance on when to use each. Brian Sierakowski September 18, 2026 ](/blog/release-notes-template) [ ![AI agent icon with empty fuel gauge surrounded by disconnected data sources](/_astro/featured.SIA2wRub_Z8rzpT.webp) ## Introducing the Changebot Agent Changebot is becoming the agent-first changelog: write, edit, review, and publish product updates from the workflow you already use. Brian Sierakowski June 13, 2026 ](/blog/introducing-the-changebot-agent) [ ![Developer workflow with AI coding tools and release communication signals](/_astro/featured.KqEEKq0c_1iiJvF.webp) ## Publish Your Changelog From Claude Code A practical example of the Changebot MCP workflow: ask for an update, review the draft, and publish without leaving your agent surface. Brian Sierakowski June 13, 2026 ](/blog/publish-your-changelog-from-claude-code) [ ![A changelog sitting at the end of a long product workflow](/_astro/featured.pnGxyg_q_Z1Yu70o.webp) ## The Agent-First Changelog The next changelog is not a CMS you remember to update. It is a publishing layer your agents can write to. Brian Sierakowski June 13, 2026 ](/blog/the-agent-first-changelog) [ ![Illustration of a person tangled in vines growing from a process flowchart they originally created](/_astro/featured.B82ojyQQ_ZOls7D.webp) ## I created this process and now it's eating me alive You championed release notes when nobody else would. Now you're the permanent owner. Here's why the 'person who cares' always gets stuck. Brian Sierakowski March 9, 2026 ](/blog/i-created-this-process-and-now-its-eating-me-alive) [ ![Illustration of a rocket ship representing 10x development speed leaving behind a cyclist struggling with manual communication](/_astro/featured.B_5fYJ4c_Zenksk.webp) ## AI made you ship 10x faster. Your communication didn't keep up. AI coding tools have accelerated engineering output dramatically. But nobody built the communication layer to match. The gap is widening. Brian Sierakowski March 6, 2026 ](/blog/ai-made-you-ship-10x-faster) [ ![Illustration of a scale with AI misjudging a large dependency update as more important than a small key feature](/_astro/featured.CSim7ook_1ymztg.webp) ## AI can't tell your biggest feature from a dependency update Generic AI tools treat all code changes equally. They over-index on PR volume, can't distinguish customer impact from internal cleanup, and the output sounds like a robot wrote it. Brian Sierakowski March 3, 2026 ](/blog/ai-cant-tell-your-biggest-feature-from-a-dependency-update) [ ![Illustration of ephemeral chat messages fading away contrasted with a solid permanent changelog record](/_astro/featured.B9tC-QeF_2lqndB.webp) ## Your deploy message in Slack is not a changelog Developer posts 'released this morning' in Slack. A week later, nobody can find it. Here's why Slack-as-changelog fails and what to do instead. Brian Sierakowski February 28, 2026 ](/blog/your-deploy-message-in-slack-is-not-a-changelog) [ ![Illustration of a building bustling with activity inside but no visible signs of progress to people outside](/_astro/featured.BXBGPQ95_1jEVmG.webp) ## We are doing stuff. Trust us. Your team ships features every week. Your customers have no idea. When there's no single place to point people to, trust erodes even when the work is getting done. Brian Sierakowski February 25, 2026 ](/blog/we-are-doing-stuff-trust-us) [ ![Illustration of a single document splitting into five paths for different audiences](/_astro/featured.DJaXBpwi_2bAx0a.webp) ## The five rewrites problem Every release cycle, the same update gets rewritten five times for five audiences. Here's why that's killing your product team's bandwidth. Brian Sierakowski February 22, 2026 ](/blog/the-five-rewrites-problem) [ ![A boomerang arcing through the air, representing SaaS customers who leave and come back](/_astro/featured.xIUcbq20_daQKk.webp) ## The customer always comes back SaaS customers are canceling to vibe-code their own tools. They're also coming back a month later. Here's why the build-it-yourself era is a blip, not a trend. Brian Sierakowski February 20, 2026 ](/blog/the-customer-always-comes-back) [ ![Illustration of a stopwatch showing fifteen minutes with a hidden iceberg of context-gathering work beneath](/_astro/featured.BpK0x1Io_Z1u2DdI.webp) ## The fifteen-minute illusion Your changelog process only takes fifteen minutes. But that number is hiding the real cost of how your team communicates what shipped. Brian Sierakowski February 19, 2026 ](/blog/the-fifteen-minute-illusion) [ ![Two changelogs side by side: a vibrant stack of update cards with a verification badge versus a sparse faded timeline with cobwebs](/_astro/featured.BBaEHGWA_1EbBq1.webp) ## Proof of Shipping: The New Table Stakes for Vendor Evaluation Prospects check your changelog before they book a demo. Investors want evidence of velocity. A stale update history says 'abandoned' louder than any pitch deck can overcome. Brian Sierakowski February 17, 2026 ](/blog/proof-of-shipping) [ ![A grid of hackathon project demos showing various customer communication tools](/_astro/featured.BlOmFd8H_Z1luqYv.webp) ## What 15 hackathon apps taught us about the future of customer communication When 15 teams at an AI hackathon independently built customer success tools, it confirmed something we've believed for a while: customer communication is the next frontier for AI. Brian Sierakowski February 17, 2026 ](/blog/what-15-hackathon-apps-taught-us) [ ![Illustration of a priority stack with changelog at the bottom collecting dust](/_astro/featured.pnGxyg_q_Z1Yu70o.webp) ## The changelog is always the last thing you update Ship the code. Update the docs. Update the marketing page. Then, if there's time, update the changelog. Here's why 'afterthought' is the default and how to fix it. Brian Sierakowski February 16, 2026 ](/blog/the-changelog-is-always-the-last-thing-you-update) [ ![Illustration of a clunky workflow with screenshots being pasted between a changelog editor, a capture frame, and ticket comments](/_astro/featured.CgeNT2Li_Z1MiiNF.webp) ## Sharing screenshots of your changelog drafts is a red flag When your team reviews changelog entries by taking screenshots of drafts and pasting them into tickets, the tool has become the bottleneck. Brian Sierakowski February 13, 2026 ](/blog/sharing-screenshots-of-your-changelog-drafts-is-a-red-flag) [ ![Product content cards ascending a staircase into a spotlight while generic SEO blog posts fade below, with AI chat bubbles at the top](/_astro/featured.CzAQQKXs_ZnHJua.webp) ## Product Marketing Is the Ascendant Discipline in 2026 Top-of-funnel SEO content is dying. LLMs are the new discovery channel. The companies that win are the ones writing about what their product actually does, not chasing keywords. Brian Sierakowski February 12, 2026 ](/blog/product-marketing-is-the-ascendant-discipline) [ ![A crumbling marketing funnel contrasted with product update cards flowing into an AI chat bubble that connects to customers](/_astro/featured.cH0vstkd_ZrwjV1.webp) ## Top-of-Funnel Content Is Dead. Product Updates Are Your New Growth Channel. Traditional SEO blog posts won't save you. In a world where prospects ask LLMs for recommendations, the companies with the most detailed product content win. Brian Sierakowski February 7, 2026 ](/blog/top-of-funnel-is-dead) [ ![Clock split between productive coding and wasted status meetings, with a chain of figures passing information in a telephone game](/_astro/featured.KqEEKq0c_1iiJvF.webp) ## Developers Lose 10 Hours a Week to Status Theater Your engineering team spends 5-10 hours every week in meetings explaining what they built. Then you wonder why they're not shipping fast enough. Brian Sierakowski February 2, 2026 ](/blog/developers-lose-10-hours-a-week-to-status-theater) [ ![Terminal with raw commit messages transforming through gears into a polished customer announcement card](/_astro/featured.By65PXk2_1O2PkY.webp) ## Your Commit Messages Were Never Meant for Customers The gap between what developers write in commit messages and what customers need to hear about your product is wider than you think. Here's why that matters. Brian Sierakowski January 28, 2026 ](/blog/your-commit-messages-were-never-meant-for-customers) [ ![Split illustration showing engineering artifacts on one side and a polished newsletter on the other, with a figure bridging the gap](/_astro/featured.EnJOzac9_ZxUHyI.webp) ## The Non-Technical Founder's Update Problem You know your product is shipping. You just can't see it. When every customer update requires interrupting your engineering cofounder, most updates don't happen. Brian Sierakowski January 23, 2026 ](/blog/the-non-technical-founders-update-problem) [ ![Illustration contrasting chaotic year-end data excavation with organized curation, showing scattered documents becoming a clean summary report](/_astro/featured.DfA7R9PO_Z1X25K0.webp) ## The Year-End Review You're Dreading Every January, product teams face the same grueling ritual: sifting through months of work to compile what actually shipped. There's a better way to approach year-end retrospectives. Brian Sierakowski January 19, 2026 ](/blog/the-year-end-review-youre-dreading) [ ![Illustration showing a communication gap between a product team shipping features and customers unaware of them, with a changelog bridge spanning the gap](/_astro/featured.Zcxg6EH4_Z18mJ15.webp) ## "I Had No Idea This Exists": The Feature Awareness Problem Your team shipped the feature. You announced it. And customers still don't know it exists. Here's why the gap between shipping and awareness is bigger than you think. Brian Sierakowski January 15, 2026 ](/blog/i-had-no-idea-this-exists) [ ![Illustration showing multiple repository sources converging from fragmented views into one unified holistic dashboard](/_astro/featured.Bvanj-gv_2j9J3g.webp) ## Many Repositories, Many Products: The Holistic View Nobody Has When your product spans five repositories, three teams, and two technology stacks, no single person can see the full picture of what shipped. Here's why that's a communication crisis. Brian Sierakowski January 13, 2026 ](/blog/the-holistic-view-nobody-has) [ ![Single figure with radiating connections to many product icons showing coverage spreading thin](/_astro/featured.3_OAoZzT_IvMzE.webp) ## Product Marketing Across 20 Products Most PMM advice assumes you own one product. But what happens when you're responsible for 10, 20, or 100? The playbook breaks down. Here's how to scale without losing your mind. Brian Sierakowski January 11, 2026 ](/blog/product-marketing-across-20-products) [ ![Towering stack of documents with scattered papers versus a clean tablet showing a concise summary](/_astro/featured.Jw8Dybi8_1VToof.webp) ## The 100-Page Update Doc Nobody Reads Every quarter, product marketing teams assemble massive update documents for events and stakeholder reviews. They take weeks to compile, and nobody reads them end-to-end. There's a better way. Brian Sierakowski January 9, 2026 ](/blog/the-100-page-update-doc-nobody-reads) [ ![Calendar with meeting blocks contrasted with automatic notification feed](/_astro/featured.DB1UC68X_Z1mHNa7.webp) ## The Meeting You Shouldn't Have to Attend There's a difference between meetings where you contribute and meetings where you're just extracting information. Product marketers shouldn't have to join calls just to learn what shipped. Brian Sierakowski January 7, 2026 ](/blog/the-meeting-you-shouldnt-have-to-attend) [ ![AI agent icon with empty fuel gauge surrounded by disconnected data sources](/_astro/featured.SIA2wRub_Z8rzpT.webp) ## Feeding Your AI Agents: Why Product Updates Need Structure AI-forward companies are building internal agents for sales enablement, support, and more. But these agents are starving for reliable product change data. Here's how to fix that. Brian Sierakowski January 5, 2026 ](/blog/feeding-your-ai-agents-why-product-updates-need-structure) [ ![Transformation from dry technical changelog on the left to customer-friendly release notes on the right, connected by an arrow](/_astro/featured.MHF0C3j5_Z1eM9v8.webp) ## Why Your Release Notes Still Sound Like a Changelog Most teams list what changed. Few explain why customers should care. Here's how to transform technical changes into customer value. Brian Sierakowski January 4, 2026 ](/blog/why-your-release-notes-still-sound-like-a-changelog) [ ![Staged rollout progress bar with megaphone icons at varying opacity and a question mark over middle stages representing communication timing uncertainty](/_astro/featured.Bbll_nbw_1QIox3.webp) ## When Do You Announce a Feature That's Only 10% Rolled Out? Feature flags and staged rollouts create a communication timing problem. Traditional release notes assume binary shipped/not-shipped. CI/CD requires a new mental model. Brian Sierakowski January 2, 2026 ](/blog/when-do-you-announce-a-feature-thats-only-10-percent-rolled-out) [ ![Three-stage workflow showing automation generating a draft, a human refining it with editing marks, and the polished document flowing to multiple distribution channels](/_astro/featured.D20IvKdv_ZdCK6e.webp) ## The Draft-to-Publish Workflow That Actually Works PMs draft. Marketing refines. Here's how to automate the drafting without losing the positioning control that makes release notes effective. Brian Sierakowski December 31, 2025 ](/blog/the-draft-to-publish-workflow-that-actually-works) [ ![Cobbled-together system with tangled wires and broken connections falling apart, contrasted with a clean integrated system](/_astro/featured.DHYFSHki_kV9vM.webp) ## Why You Can't Vibe-Code Your Way to Good Release Communication Teams think they can cobble together ChatGPT + scripts + Slack bots for release updates. Here's why that approach falls apart, and what it's actually worth to solve this problem properly. Brian Sierakowski December 29, 2025 ](/blog/why-you-cant-vibe-code-release-communication) [ ![Document in center with distribution arrows branching to channel icons, some reaching destinations and others fading or breaking midway](/_astro/featured.BAgALkvy_Z1gLDCJ.webp) ## Writing the Update Is Only Half the Battle Most teams think the hard part is writing product updates. The real challenge? Getting them where they need to go. Brian Sierakowski December 27, 2025 ](/blog/writing-the-update-is-only-half-the-battle) [ ![Two figures meeting on a bridge representing vendor and buyer collaboration in security reviews, with documentation and checkpoints leading to a handshake](/_astro/featured.D2Gpveqm_Z2gacfK.webp) ## The Vendor Security Dance: How Both Sides Can Move Faster Security reviews don't have to stall deals for weeks. Here's how vendors and buyers can structure evaluations that work for security teams without killing momentum. Brian Sierakowski December 25, 2025 ](/blog/the-vendor-security-dance) [ ![Iceberg visualization showing a small visible tip above the waterline with a few feature cards, and a massive collection of code commits, bug fixes, and shipped work hidden below the surface](/_astro/featured.BbJqLC4p_sDNm9.webp) ## Getting Paid to Build Is Easy. Getting Credit for It? Hard. Your team is shipping features every week. Your customers think you haven't improved the product in months. Here's why the credit gap exists, and what it costs you. Brian Sierakowski December 23, 2025 ](/blog/getting-paid-to-build-is-easy) [ ![Illustration showing scattered Jira tickets, GitHub PRs and Slack messages flowing through a funnel into a clean summary dashboard, representing the transformation from chaotic manual recaps to streamlined automation](/_astro/featured.0eHPIBRu_Z2fRlXi.webp) ## Five Hours Down to Five Minutes: The Monthly Recap Problem Monthly product recaps shouldn't take days. Here's why they do, and how to reclaim that time. Brian Sierakowski December 22, 2025 ](/blog/from-five-hours-to-five-minutes) [ ![Illustration of a developer silhouette overwhelmed by form fields and checkboxes, representing Jira bureaucracy](/_astro/featured.zSOk5WaU_Zuz8Rs.webp) ## Why Every Engineer Hates Jira (And How We Made It Worse) Jira became the most hated tool in engineering because every team added their own fields and requirements. Here's how it happened and what to do instead. Brian Sierakowski December 22, 2025 ](/blog/why-every-engineer-hates-jira) [ ![A spiral vortex with calendar and meeting icons multiplying, representing the destructive cycle of meeting overload](/_astro/featured.B-yMVFGy_Ziwp4x.webp) ## The Release Communication Death Spiral: More Meetings Won't Fix It When teams don't know what's shipping, they add meetings, which leaves less time to document, which means even more meetings. Here's how to break the cycle. Brian Sierakowski December 21, 2025 ](/blog/the-release-communication-death-spiral) [ ![Bug being squashed with checkmark on one side, megaphone broadcasting the fix on the other](/_astro/featured.35EeLAp5_ZSOSqX.webp) ## Why Your Bug Fixes Deserve Their Own Announcements Most companies only announce new features. But your customers already saw the bug. Here's why you should tell them you fixed it. Brian Sierakowski December 20, 2025 ](/blog/why-bug-fixes-deserve-announcements) [ ![Support agent desk showing contrast between sparse official inbox and overflowing secret channel sidebar with sticky notes and chat messages about small fixes](/_astro/featured.BIG96wNS_hwOOd.webp) ## The Support Team's Secret Channel: When Your Own Team Doesn't Know What Shipped Support teams often create workarounds just to learn about small releases. This signals a systemic communication failure that affects everyone. Brian Sierakowski December 17, 2025 ](/blog/the-support-teams-secret-channel) [ ![A visual gap showing code and shipped features on one side, empty documents and waiting stakeholders on the other](/_astro/featured.DCbRX0f0_Z2oXN2c.webp) ## The PM Accountability Gap: Why Documentation Falls Through the Cracks Product managers hate documentation. They know it's important, but it's never urgent enough to rank highly. Here's why this gap exists and what to do about it. Brian Sierakowski December 16, 2025 ](/blog/the-pm-accountability-gap) [ ![Secure code repository connected by a gated pathway to an AI brain symbol with security checklist](/_astro/featured.CBC49yCi_Z2pLeJo.webp) ## What to Ask Before Giving an AI Tool Access to Your Code A vendor checklist before you grant an AI tool repo access: what they read, what they send to LLMs, secrets handling, retention, and breach response. Brian Sierakowski December 14, 2025 ](/blog/what-to-ask-before-giving-ai-code-access) [ ![Faded spec document floating like a dream contrasted with solid grounded code blocks](/_astro/featured.BvadUFir_ZP8ntR.webp) ## Product Manager Fiction: Why Your PRDs Aren't the Source of Truth PRDs and specs describe a future that may never exist. The code that ships is your actual tether to reality. Here's why this disconnect matters. Brian Sierakowski December 10, 2025 ](/blog/product-manager-fiction) [ ![Globe with location pins connected by information streams, showing fragmented communication flowing into unified channels](/_astro/featured.DPkoJhbE_f6375.webp) ## The Hybrid Workplace's Hidden Product Challenge: Keeping Distributed Teams in Sync on What's Shipping Remote and hybrid work solved the location problem, but created a new one: how do you keep distributed teams informed about what's actually getting built? Brian Sierakowski December 10, 2025 ](/blog/the-hybrid-workplaces-hidden-product-challenge) [ ![Illustration of a filter separating a chaotic stream of technical items into two paths: a highlighted signal path with key updates flowing to customers, and a faded noise path with internal changes](/_astro/featured.CAUlgTrj_Z1NRQ7H.webp) ## Signal vs. Noise: What Customers Actually Care About Not every code change is worth announcing. Database indexes, infrastructure tweaks, and internal refactors are valuable work but noise to customers. Here's how to filter. Brian Sierakowski December 7, 2025 ](/blog/signal-vs-noise-what-customers-care-about) [ ![Illustration of changelog entries flowing toward a customer, with retention icons like circular arrows and a shield, representing changelogs as customer retention tools](/_astro/featured.nfffnZlS_ZeEl6h.webp) ## When changelogs Become Customer Retention Tools (Beyond Mere Obligations) Most companies treat changelogs as a checkbox. Smart companies use them to save at-risk accounts and prove ongoing value. Here's how. Brian Sierakowski December 5, 2025 ](/blog/changelogs-as-customer-retention-tools) [ ![Silhouette trapped in gears versus silhouette overseeing automated machinery](/_astro/featured.MRbH_XSJ_1AN4CC.webp) ## The PM as Automation: Why Product Managers Build Systems That Break PMs create bespoke spreadsheets and processes to track what's shipping. Then they become the automation themselves. Here's why that doesn't scale. Brian Sierakowski December 3, 2025 ](/blog/the-pm-as-automation) [ ![Disconnected tool icons unified by a central code node forming a knowledge graph](/_astro/featured.WuaH5QsV_zWm7f.webp) ## The Missing Knowledge Graph: Why No One Knows What Shipped Organizations have rich data in GitHub, Jira, Docs, and Slack. But none of it connects. Here's why the missing knowledge graph is your biggest communication problem. Brian Sierakowski December 1, 2025 ](/blog/the-missing-knowledge-graph) [ ![Product marketer watching a fast-moving launch train while sipping coffee](/_astro/featured.B6sNec3O_1cmXJt.webp) ## High-Velocity PMM Without More Meetings How product marketing can stay ahead of rapid engineering output without living in standups, Slack threads, or demo day. Brian Sierakowski November 25, 2025 ](/blog/high-velocity-pmm-without-more-meetings) [ ![Two paths from code to customer: raw commits vs product-aware summaries](/_astro/featured.jPjj9por_1t7ART.webp) ## CodeRabbit vs Product-Aware Summaries Why product framing beats commit-level blurbs when support and marketing need customer impact. Brian Sierakowski November 15, 2025 ](/blog/coderabbit-vs-product-aware-summaries) [ ![AI tailoring release notes to a brand's voice](/_astro/featured.DK4zUq--_EqyVp.webp) ## Brand-Voice-Aware AI How Changebot learns your company's voice so release updates sound like your team wrote them. Brian Sierakowski July 29, 2025 ](/blog/brand-voice-aware-ai) [ ![Five concise bullets emerging from a stream of code updates for investors](/_astro/featured.Cwez3cEd_1CUjj.webp) ## Investor Updates From Code How Changebot turns your shipped code into investor-ready updates that prove progress and build confidence. Brian Sierakowski July 22, 2025 ](/blog/investor-updates-from-code) [ ![B2C update dial controlling frequency with a support team in the loop](/_astro/featured.Dl8PtQNd_Z1MDKxB.webp) ## B2C Cadence Control Avoiding churn by right-sizing app updates for millions of users while keeping support fully briefed. Brian Sierakowski June 24, 2025 ](/blog/b2c-cadence-control) [ ![A spotlight shining on a changelog entry rising from a backlog pile](/_astro/featured.B3h1Juci_Z25VpNU.webp) ## Backlog to Spotlight How Changebot's Recaps and Spotlights turn buried product work into customer-ready updates. Brian Sierakowski June 3, 2025 ](/blog/from-backlog-to-spotlight) [ ![The Development Hell Death Spiral (and how to escape)](/_astro/featured.DvQdHFZo_1Pt8Pv.webp) ## The Development Hell Death Spiral (and how to escape it) When big dev projects stall your roadmap, the real danger is the communication death spiral that follows. Brian Sierakowski May 19, 2025 ](/blog/the-development-hell-death-spiral-and-how-to-escape) [ ![The Soul of Your Company](/_astro/featured.DEptH9Vf_1UbRzh.webp) ## The Soul of Your Company Your product announcements reveal the soul of your company—are you a slow turtle or a cool rabbit with sunglasses? Brian Sierakowski May 15, 2025 ](/blog/the-soul-of-your-company) [ ![How GitHub Squeezes The Juice From Their Updates](/_astro/featured.DhPnM86N_Mlc23.webp) ## How GitHub Squeezes The Juice From Their Updates GitHub publishes 29 updates per month—here's how they squeeze maximum value from their changelog with relentless consistency and smart distribution. Brian Sierakowski March 7, 2025 ](/blog/how-github-squeezes-the-juice-from-their-updates) [ ![How Linear uses product updates to create yell-from-the-rooftop fans](/_astro/featured.vTn5qUMc_g0iEK.webp) ## How Linear uses its changelog to announce product updates I analyzed 192 Linear changelog entries. They stay public, ship about 3 times a month, and explain the why. Here's what to copy. Brian Sierakowski March 7, 2025 ](/blog/how-linear-uses-product-updates-to-create-yell-from-the-rooftop-fans) [ ![Changelogs: The PM's Secret Weapon](/_astro/featured.BjQbr1-X_Z1TFCBk.webp) ## Changelogs: The PM's Secret Weapon Five ways product managers turn ordinary release notes into a customer magnet that prevents churn and drives expansion revenue. Brian Sierakowski December 20, 2024 ](/blog/changelogs-the-pms-secret-weapon) [ ![Here's how Github uses their developers to write better changelogs](/_astro/featured.Bg_Rsrbv_12IQ7i.webp) ## Here's how Github uses their developers to write better changelogs Getting customer quotes slows down your changelog—here's how GitHub uses developer quotes to maintain speed while building trust. Brian Sierakowski December 3, 2024 ](/blog/heres-how-github-uses-their-developers-to-write-better-changelogs) [ ![This to That](/_astro/featured.BpVLW6Lg_ZPjDg8.webp) ## This to That Watch us transform minimal commit messages into compelling customer updates that actually resonate. Brian Sierakowski September 2, 2024 ](/blog/this-to-that) [ ![How to Update Your Changelog Before a Price Increase](/_astro/featured.Cw1e1wEe_ZgXGKw.webp) ## How to Update Your Changelog Before a Price Increase Raising prices with an empty changelog is asking for churn—here's how to avoid that mistake. Brian Sierakowski August 19, 2024 ](/blog/how-to-update-your-changelog-before-a-price-increase) [ ![Who's responsible for customer updates?](/_astro/featured.BdhqYxGa_YAdge.webp) ## Who's responsible for customer updates? Your team isn't updating customers enough—here's how to figure out who should actually own this critical responsibility. Brian Sierakowski July 15, 2024 ](/blog/whos-responsible-for-customer-updates) [ ![Here's how Github uses their developers to write better changelogs](/_astro/featured.CJmKqClh_Z2cxQmf.webp) ## How Cringe Should Customer Updates Be? Finding the right balance between boring corporate speak and over-the-top enthusiasm in your customer updates. Brian Sierakowski June 3, 2024 ](/blog/how-cringe-should-customer-updates-be) [ ![The Art of the Update](/_astro/featured.R4nmcstn_sXp31.webp) ## The Art of the Update The complete guide to writing product updates that prevent churn, attract customers, and prove your value. Brian Sierakowski March 25, 2024 ](/blog/the-art-of-the-update) # B2C Cadence Control URL: https://www.changebot.ai/blog/b2c-cadence-control/ Description: Avoiding churn by right-sizing app updates for millions of users while keeping support fully briefed. Last updated: 2025-06-24 Best Practices # B2C Cadence Control [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder June 24, 2025 3 min read ![B2C update dial controlling frequency with a support team in the loop](/_astro/featured.Dl8PtQNd_Z1MDKxB.webp) B2C teams can’t blast every commit to millions of users, yet support needs to know what changed _today_. In a recent call, a CEO worried that “a monthly support recap is too late for a login fix,” a marketplace leader admitted his dealers never saw a big feature because the notes were (in their words) “gibberish,” and a VP of Product with fifteen repos just wanted a weekly recap that wasn’t a two-hour meeting. Here’s how teams like theirs are turning outline-style change lists into a steady narrative that keeps consumers calm and support confident. ## The real tension Consumer cadence cuts both ways. Push too often and churn ticks up, push too little and customers assume nothing is happening. Despite engineering teams logging every release, support still learns about fixes after tickets pile up. Sometimes this is because the updates are too technical, but other times this is a “signal from noise” issue, the updates are there, just buried in Slack. ## Run two tracks: exhaustive inside, selective outside The process we’ve implemented successfully is the dual-track approach: - **Authoritative internal trail.** Keep a complete, code-driven feed so support, PMM, and product ops can see what actually hit production. You can still create a Friday product update recap, but now pairs it with an always-on feed that maps changes to customer impact so the support team can triage faster. - **Throttled external cadence.** Consumers only hear about the top three to five changes on a monthly rhythm. Teams use Changebot to generate a recap as meeting prep internally, then lift a handful of items into a biweekly app-store/update note. This keeps credit and context flowing internally without spamming customers. ## Make support your first audience Support tends to hear last, yet feels the pain first. The fintech CEO saw weekly updates “not read” and monthly MX recaps miss critical fixes; the result was slower triage and misaligned talking points. Treat support/MX as the primary subscriber: - Push a short, plain-language note the moment code hits production, not after the weekly roundup. One marketplace CEO now insists every update includes a “why it matters” line a dealer could read in a drive-thru line. - Translate technical fixes into outcomes: “login now succeeds on first try,” “card verification errors resolved for prepaid users,” “photo uploads retry automatically.” A proptech CEO compared his internal notes to Tesla’s one-liners and realized why he’d lost his dealers. - Link to help articles, status pages, or known caveats so the frontline has an answer-ready script. When support has this feed, product marketing can move slower and more selectively with consumer channels. ## Choose cadence by channel, not by habit One B2C leader told us bluntly: “We can’t bombard millions of people with every tweak.” The pattern that works: - **Daily/continuous:** Internal change log and support feed; everything lands here with customer-facing framing. - **Weekly/biweekly:** Internal huddles and leadership recaps. The fitness VP uses this to prep without combing through fifteen repos. - **Monthly (or slower) external:** App store notes, email, or in-app banners with only the most visible experience changes. Consumer channels should feel calm and curated; internal channels should feel complete and searchable. ## Filter for signal and voice Noise kills trust. The commerce PM worried about “great news, we added a DB index” updates; her VP wanted one- to two-line summaries per change so they could spotlight front-end shifts without wading through component names and layout jargon. Practical filters: - Flag customer-facing updates vs. backend-only work, and keep the backend items in the internal feed. - Offer short summaries first, with deeper detail a click away. Nobody will open 750 items. - Let tone match the audience: internal-first language for support and PMs; polished, empathetic copy for consumers. One PM sent real examples of their brand voice so internal updates wouldn’t read like end-user marketing. ## Respect readiness: staging, beta, GA Announcing ghost features burns trust. A product marketing leader preparing four launches insisted on tagging work by stage (staging, beta, GA) so demo-day excitement didn’t leak into customer channels prematurely. Feature flags and partial rollouts should be visible internally with clear “do not announce yet” labels; only GA items flow to consumer surfaces. ## What to measure Cadence control isn’t “set and forget.” Track whether the new rhythm is working: - Churn and engagement before/after major pushes. - Ticket volume and resolution time by theme: proactive support notes should cut repeat issues. - Merge-to-notification time: support and MX should hear about changes before customers do. Get the cadence right, and consumers stay happy while support stops getting blindsided. The side effect: product and engineering finally get credit for work that was already shipping. [← Back to Blog](/blog) # Brand-Voice-Aware AI URL: https://www.changebot.ai/blog/brand-voice-aware-ai/ Description: How Changebot learns your company's voice so release updates sound like your team wrote them. Last updated: 2025-07-29 Best Practices # Brand-Voice-Aware AI [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder July 29, 2025 3 min read ![AI tailoring release notes to a brand's voice](/_astro/featured.DK4zUq--_EqyVp.webp) You’ve probably noticed that AI can draft just about any information you ask for, and can turn that draft around faster than any human could. You’ve probably also noticed that stock AI gets you in the ballpark, but if every blurb needs a rewrite you’re not saving any time. Generic AI doesn’t know your product, your customers, or how your team talks about features. That’s why we built Changebot around three pillars: **accuracy**, **tone**, and **distribution**. Accurate content that sounds wrong still needs a rewrite, and perfect tone with wrong details is even worse. Neither matters if it doesn’t reach the right people. Here’s how we solve the tone piece. ## How Changebot learns your voice ### 1\. Writing samples during onboarding When you set up Changebot, we ask for examples of your best release notes, changelog entries, blog posts, and support snippets. These samples teach us the phrases you use, the level of detail you prefer, and how you frame benefits versus features. We look at patterns: Do you lead with customer impact or technical detail? Short and punchy or thorough and explanatory? Casual or buttoned-up? These samples become the foundation. ### 2\. Company and product context We work with your team to build a context layer that understands your product, your customers, and how you talk about both. Changebot knows that “the new alerting workflow” helps enterprise accounts reduce mean time to detect. We surface the customer impact that matters to your users. This context prevents the generic AI problem where every feature sounds the same. Your updates reflect what actually matters to your users. ### 3\. Your entire code history Changebot scans your complete commit and PR history to build a timeline of your product’s evolution. We know what shipped when, what features connect to what, and how your product has grown. This means when a new PR lands, we understand it in context. A small fix might be the final piece of a larger improvement your customers have been waiting for. A refactor might signal a shift in how a feature works. History gives us accuracy; accuracy makes the tone believable. ### 4\. Hands-on tuning with your team During implementation, we work directly with your PMM and product teams to tune the output. We collaborate on refinement until the updates feel right. We adjust for audience (internal vs external), verbosity, CTA style, and the specific phrases your team loves (or hates). The goal: updates that need light edits, not rewrites. ### 5\. Continuous learning from your edits Here’s where it gets good. Every time you edit an update before publishing, Changebot learns from it. Your corrections teach the system what you prefer. Over time, your brand voice gets sharper. The first month might need more tweaks. By month three, most updates ship with minimal changes. By month six, your team wonders why they ever wrote this stuff manually. ## What “good” looks like - **Benefit-first framing:** “Fewer failed payouts” beats “Updated payment retry logic.” - **Audience-aware language:** Support teams, customers, and investors each get the version that resonates. - **Consistent structure:** Short scannable summaries with optional depth for those who want it. - **Your phrases, not ours:** If your team says “setup” not “onboarding,” Changebot says setup. ## The three pillars working together Tone doesn’t exist in isolation. An update that sounds perfect but gets the details wrong erodes trust. An accurate update that sounds robotic gets ignored. **Accuracy** comes from scanning your code history and understanding what actually changed. **Tone** comes from learning your voice and improving with every edit. **Distribution** ensures the right version reaches the right audience in the right channel. When all three work together, your team just reviews drafts instead of rewriting them. Your customers get updates that sound like they came from the team that built the product. [← Back to Blog](/blog) # Changelog Best Practices: A Ten-Point Checklist URL: https://www.changebot.ai/blog/changelog-best-practices-checklist/ Description: Ten checks for a changelog that customers actually read — audience, cadence, grouping, language, dates, links, feeds, discoverability, review, and machine access. Last updated: 2026-09-18 Best Practices # Changelog Best Practices: A Ten-Point Checklist [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder September 18, 2026 3 min read ![A figure ticking neon green checkboxes on a large checklist board beside a published changelog page](/_astro/featured.DqWBfHPR_Z1qzTtR.webp) In short A good changelog is dated, published on your own domain, written in customer language rather than commit language, grouped by what the change means, released on a predictable rhythm, linked to documentation, available as a feed, and readable by machines. Human review before publishing keeps it trustworthy. Most changelog advice is a style guide. This is a checklist: ten things to verify about the changelog you already have. ## 1\. It is written for one audience, deliberately chosen The most common failure is a changelog that tries to serve developers integrating against your API and the non-technical buyer who wants to know the product is alive. Those readers want different grain and different language. Pick a primary audience. If you genuinely need both, run two surfaces — a product changelog and an API changelog — and link them. ## 2\. It ships on a rhythm Weekly, biweekly, or per release. What matters is that a reader can predict it, and that prospects checking whether you’re alive find [proof you’re still shipping](/blog/proof-of-shipping/). Cadence is also the honest test of whether your process works. Teams don’t decide to stop publishing — they forget, because nothing in the workflow asks for the entry once attention moves to the next feature. If the changelog is three weeks behind, the fix is a trigger and a cheaper first draft, not more discipline. ## 3\. Entries are grouped by meaning, not by team “New / Improved / Fixed” tells a reader where to look. “Platform team / Growth team / Infrastructure” tells them about your org chart, which they did not ask about. ## 4\. Language is customer language The rule that catches most of it: describe the symptom, not the cause. - Not: “Fixed a race condition in the notification consumer.” - Yes: “Comment notifications no longer arrive twice when a thread is reopened.” Your commit messages were written for a reviewer who has the pull request open. They were [never meant for customers](/blog/your-commit-messages-were-never-meant-for-customers/). ## 5\. Every entry is dated Dates let readers see what is recent, let you link to a moment in time, and let AI assistants and search engines judge whether what they found is still current. An undated changelog is unusable as a citation. ## 6\. Entries link somewhere Each substantive entry should link to documentation, the feature itself, or a migration guide. An update that ends at the description makes the reader go looking, and most won’t. ## 7\. There is a feed RSS or Atom. It costs nothing, it’s how power users and internal tooling subscribe, and it’s a standard input for aggregators and assistants. ## 8\. It is discoverable from inside the product The people most likely to care are already logged in. A [changelog widget](/glossary/changelog-widget/) or a “What’s new” entry in the navigation converts the audience you already have, which is cheaper than any email campaign. ## 9\. A human approves before it publishes Automation should draft. A person should decide what ships. The risk of fully automatic publishing is not bad grammar, it’s announcing something you didn’t intend to announce yet — a flagged feature, a partner integration, a change of pricing behavior. A related habit: don’t announce on deploy day. Let a feature settle for a couple of days before the entry goes out, so you never announce something you roll back on Thursday. ## 10\. Machines can read it This is the newest item and the one most changelogs fail. Customers increasingly ask an assistant what changed instead of visiting your page, and assistants can only answer from what they can fetch, parse, and date. That means: crawlable HTML on your own domain, dated entries, a feed, and ideally a machine-readable surface — Markdown, an API, or [MCP](/glossary/mcp/) — so an agent can pull your updates directly. Changebot serves all of those, and the publishing layer is free. ## The scoring Eight or more: your changelog is doing its job. Five to seven: usually a cadence problem hiding as a quality problem. Fix the rhythm first; the writing improves when entries are drafted while the work is fresh. Under five: don’t start with a style guide. Start by making the first draft cheap. [The Changebot Agent](/product/agent/) reads your GitHub or Bitbucket history and writes the entries for review, which turns publishing from a blank page into an edit. ## Related reading - [Release notes template: four formats you can copy](/blog/release-notes-template/) - [Changelog vs release notes: what is the difference?](/blog/changelog-vs-release-notes/) - [What is a changelog?](/glossary/changelog/) ## Frequently Asked Questions How often should you update a changelog? On a rhythm customers can predict, usually weekly or per release. Consistency beats volume: a reliable weekly update trains people to check, while a sporadic one gets ignored even when the underlying work is strong. What should you leave out of a changelog? Internal refactors with no customer-visible effect, ticket numbers, service names your customers have never heard, and anything still behind a flag they cannot turn on. If a reader cannot act on it or notice it, it is noise. Should every bug fix go in the changelog? Every fix a customer could have noticed, yes — described by the symptom rather than the cause. Fixes nobody could observe belong in your commit history. A roundup entry covering the rest keeps the page honest without padding it. How do you make a changelog visible to AI assistants? Publish it as crawlable HTML on your own domain with dated entries, provide a feed, and expose a machine-readable surface such as Markdown, an API, or MCP. Assistants can only cite what they can fetch and date. ## Table of Contents - [1\. It is written for one audience, deliberately chosen](#1-it-is-written-for-one-audience-deliberately-chosen) - [2\. It ships on a rhythm](#2-it-ships-on-a-rhythm) - [3\. Entries are grouped by meaning, not by team](#3-entries-are-grouped-by-meaning-not-by-team) - [4\. Language is customer language](#4-language-is-customer-language) - [5\. Every entry is dated](#5-every-entry-is-dated) - [6\. Entries link somewhere](#6-entries-link-somewhere) - [7\. There is a feed](#7-there-is-a-feed) - [8\. It is discoverable from inside the product](#8-it-is-discoverable-from-inside-the-product) - [9\. A human approves before it publishes](#9-a-human-approves-before-it-publishes) - [10\. Machines can read it](#10-machines-can-read-it) - [The scoring](#the-scoring) - [Related reading](#related-reading) Stop writing the changelog by hand The Changebot Agent drafts customer-ready updates from your GitHub history. Publishing is free. [Get Started for Free →](https://app.changebot.ai/signup) [← Back to Blog](/blog) # Changelog Examples: Five Formats and What Makes Them Work URL: https://www.changebot.ai/blog/changelog-examples/ Description: Five changelog formats with written-out examples — the dated feed, the grouped release, the single-feature post, the maintenance roundup, and the API changelog — and when each one fits. Last updated: 2026-09-18 Examples # Changelog Examples: Five Formats and What Makes Them Work [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder September 18, 2026 4 min read ![Five changelog page layouts displayed side by side with a figure reviewing them from a clipboard](/_astro/featured.DNaL4UI__iVC3h.webp) In short A good changelog example shows a dated entry written in customer language: what changed, who it affects, and what to do next. Five formats cover most products — the dated feed, the grouped release, the single-feature post, the maintenance roundup, and the API changelog — and the right one depends on how often you ship and who reads. Changelog advice is easy to find and hard to act on. “Write for the customer” is true and useless at the moment you’re staring at a merge list. So here are five formats, written out. Pick the one that matches how often you ship and who reads. ## 1\. The dated feed The default for most products. One reverse-chronological page, one heading per date, a handful of items under each. ``` ## September 18, 2026 **Saved filters** - Any filter combination on the list view can now be saved and shared with your team. Saved filters appear in the sidebar for everyone with access to the workspace. **Faster exports** - CSV exports of more than 10,000 rows now stream instead of building in memory. Large exports start downloading immediately. **Fixed** - Comment notifications no longer arrive twice when a thread is reopened. ``` What makes it work: every entry leads with the noun the customer recognizes, not the system that changed. “Saved filters,” not “filter persistence service.” If several products share one feed, tag each entry by product so a reader can filter to the one they use. The lack of that filter is one of the most common reasons teams outgrow their first changelog tool. ## 2\. The grouped release For teams that ship on a version cadence, especially with a self-hosted or installable product. ``` ## v4.2.0 - September 18, 2026 ### Added - Saved filters on all list views - Webhook retries with exponential backoff ### Changed - Exports over 10,000 rows now stream - The settings page is reorganized into Account, Billing, and Team ### Fixed - Duplicate comment notifications on reopened threads - Timezone drift on scheduled reports for UTC+13 and higher ### Deprecated - `GET /v1/reports/legacy` will be removed on December 1, 2026 ``` What makes it work: the Added / Changed / Fixed / Deprecated headings are a convention readers already know from [Keep a Changelog](https://keepachangelog.com/), so they can scan for the section that affects them. The cost is that it reads like a spec, which makes it a poor fit for a non-technical audience. ## 3\. The single-feature post For launches that deserve their own page, linked from the feed. ``` ## Saved filters Every team we talked to had one person who rebuilt the same filter every morning. **The problem.** List views supported filtering, but nothing persisted. Close the tab and the filter was gone, which meant the same six clicks at the start of every session and no way to hand a view to a teammate. **What is new.** Any filter combination can now be saved, named, and shared with the workspace. Saved filters appear in the sidebar and can be set as the default view for a project. **How to use it.** Apply any filter, then click Save view in the toolbar. [Read the docs](#) - [Open your list view](#) ``` What makes it work: the problem paragraph. It gives the reader somewhere to stand before the feature arrives. ## 4\. The maintenance roundup For cycles where nothing is individually newsworthy but the work still matters. ``` ## Stability and performance - September 2026 This cycle went to reliability. The highlights: - **Exports** - Large CSV exports stream instead of buffering, so they no longer time out over 50,000 rows. - **Notifications** - Duplicate sends on reopened threads are gone. - **Scheduled reports** - Timezone handling corrected for UTC+13 and above. Plus 24 smaller fixes across search, billing, and the mobile web view. ``` What makes it work: it converts invisible work into evidence that the product is maintained. A customer deciding whether to renew reads this differently than you wrote it — as [proof of life](/blog/proof-of-shipping/). ## 5\. The API changelog For anything developers integrate against. This is the one that has to be precise. ``` ## 2026-09-18 **Added** - `POST /v1/filters` and `GET /v1/filters` for saved filters. **Changed** - `GET /v1/exports` now returns `202 Accepted` with a `location` header for exports over 10,000 rows, instead of blocking until the file is ready. Smaller exports are unchanged. **Deprecated** - `GET /v1/reports/legacy` is deprecated and will be removed on 2026-12-01. Use `GET /v1/reports` with `format=legacy`. ``` What makes it work: exact paths, exact status codes, exact dates. An API changelog is read by someone deciding whether their code breaks, and ambiguity there costs them an afternoon. ## What the good ones have in common Across all five formats, the same four properties show up: 1. **Dated.** Every entry carries a date, so a reader can tell what’s recent and an AI assistant can tell what’s current. 2. **Written from the outside in.** The entry names what the customer sees, and the implementation only appears if it changes what they should do. 3. **Published somewhere stable and crawlable.** A public page on your own domain with a feed, not a Notion doc and not a Slack message. See [your deploy message in Slack is not a changelog](/blog/your-deploy-message-in-slack-is-not-a-changelog/). 4. **Consistent.** A predictable rhythm gets read. Sporadic excellence does not. ## The part that actually stops teams None of these formats are difficult. What stops teams is the translation step — reading a week of commits and pull requests, deciding which changes a customer would notice, and rewriting each one in language that isn’t engineering language — plus the fact that nothing triggers it. The feature ships, attention moves to the next one, and the changelog quietly falls three features behind. [The Changebot Agent](/product/agent/) does that pass for you — it reads your GitHub or Bitbucket history and drafts entries in whichever of these shapes you use, for a human to edit and approve. Publishing is free: a hosted page, an embeddable widget, your own domain, Slack, RSS, and [MCP](/glossary/mcp/) for the assistants your customers ask. ## Related reading - [Release notes template: four formats you can copy](/blog/release-notes-template/) - [Changelog best practices: a ten-point checklist](/blog/changelog-best-practices-checklist/) - [What is a changelog?](/glossary/changelog/) ## Frequently Asked Questions What does a good changelog entry look like? A dated entry with a title in customer language, one or two sentences describing what changed and why it matters, and a link to documentation or to the feature. It names the customer-visible effect rather than the internal implementation. What is the difference between a changelog and a release notes page? A changelog is the running, dated list of everything that changed. Release notes are the narrative written for a specific release. In practice most teams publish release notes as entries in a changelog, and the two words get used interchangeably. Should a changelog include screenshots? For anything visual, yes. A screenshot or short clip is the fastest way to make a UI change legible, and it stops readers from having to reconstruct the feature from your prose. Maintenance entries do not need them. Where should a changelog live? On a public page on your own domain, with an RSS or Atom feed, and ideally surfaced in-app through a widget. Public and crawlable means customers, search engines, and AI assistants can all find it; in-app means the people already using the product see it. ## Table of Contents - [1\. The dated feed](#1-the-dated-feed) - [2\. The grouped release](#2-the-grouped-release) - [3\. The single-feature post](#3-the-single-feature-post) - [4\. The maintenance roundup](#4-the-maintenance-roundup) - [5\. The API changelog](#5-the-api-changelog) - [What the good ones have in common](#what-the-good-ones-have-in-common) - [The part that actually stops teams](#the-part-that-actually-stops-teams) - [Related reading](#related-reading) Stop writing the changelog by hand The Changebot Agent drafts customer-ready updates from your GitHub history. Publishing is free. [Get Started for Free →](https://app.changebot.ai/signup) [← Back to Blog](/blog) # Changelog vs Release Notes: What Is the Difference? URL: https://www.changebot.ai/blog/changelog-vs-release-notes/ Description: A changelog is the running dated list of what changed; release notes are the narrative for one release. Here's how the two differ in audience, format, and cadence, and when you need both. Last updated: 2026-09-18 Best Practices # Changelog vs Release Notes: What Is the Difference? [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder September 18, 2026 3 min read ![A dated changelog feed of stacked entry cards beside a single release notes document, with a figure comparing the two](/_astro/featured.8wMYqhRO_Z282BKT.webp) In short A changelog is the running, dated list of everything that changed in a product, read as a feed. Release notes are the narrative written for one specific release, explaining what shipped and why it matters. Most teams publish release notes as entries in a changelog, which is why the terms are often used interchangeably. The two terms get used interchangeably, and mostly that’s fine. But they describe different artifacts, and teams that conflate them tend to publish something that serves neither purpose. ## The short version A **changelog** is the continuous, dated record of what changed. It’s a feed. You read it to answer “what has happened recently?” or “when did this behavior change?” **Release notes** are the narrative for one specific release. They’re a document. You read them to answer “what is in this version, and what do I need to do about it?” ## Where they actually differ | | Changelog | Release notes | | --- | --- | --- | | Shape | Running list, newest first | One document per release | | Unit | The individual change | The release | | Cadence | Continuous | Tied to a release event | | Read for | What is new lately, when something changed | What is in this version, what to do | | Typical reader | Existing customers, prospects, support | Customers upgrading, integrators | | Depth | One to three sentences per item | Context, upgrade steps, breaking changes | ## Why the distinction is collapsing The split made sense when software shipped in versions. There was a release, it had a number, customers chose to install it, and the notes explained what they were getting. Continuous deployment removed the event. When you ship twelve times a day, “the release” is not a thing customers experience, so the narrative document loses its anchor and the dated feed becomes the natural format. That’s why most modern SaaS products have a changelog page and no separate release notes, and why the words have merged. The distinction survives where releases are still discrete: self-hosted software, mobile apps going through app store review, SDKs and libraries, and APIs with versioned endpoints. If a customer has to take an action to move to the new version, the narrative document still earns its place. ## What each format demands **A changelog is a discipline problem.** Each entry is small, so the difficulty is never the writing — it’s publishing consistently, and describing changes in customer language rather than commit language. A changelog fails by going quiet, or by reading like a merge log. **Release notes are a coordination problem.** Someone has to gather everything in the release, decide the story, document breaking changes precisely, and write upgrade steps. Then the same material gets rewritten for support, for the help center, and for the sales deck — [the five rewrites problem](/blog/the-five-rewrites-problem/). Release notes fail by shipping late, or by being assembled by one person on the afternoon of the release from a spreadsheet nobody kept current. ## Which one you need Ask whether a customer has to do something to receive the change. - **They don’t** (web app, continuous deploy): one dated changelog. Give individual launches their own longer post, linked from the feed. - **They do** (versioned, installable, mobile, API): release notes per version, plus a changelog that aggregates them so there is still one place to see recent history. - **Both audiences** (product plus a public API): two surfaces. A product changelog in plain language for customers, an API changelog with exact paths, status codes and deprecation dates for developers. Link each from the other. ## The part that doesn’t change Whichever format you choose, the hard step is the same: turning what engineering did into something a customer can read. That translation is where updates die, because it requires someone to read a week of commits and pull requests and decide what matters. [The Changebot Agent](/product/agent/) does that pass from your GitHub or Bitbucket history and hands you a draft to edit and approve. Publishing the result is free — a [hosted changelog](/product/publishing/), a widget, your own domain, Slack, RSS, and [MCP](/glossary/mcp/). ## Related reading - [What are release notes?](/glossary/release-notes/) - [What is a changelog?](/glossary/changelog/) - [Changelog best practices: a ten-point checklist](/blog/changelog-best-practices-checklist/) ## Frequently Asked Questions Is a changelog the same as release notes? No, though they overlap. A changelog is the continuous dated record of changes; release notes are the narrative for a single release. In practice most products publish release notes as dated entries in a changelog, so the same page serves both purposes. Do you need both a changelog and release notes? Only if you ship versioned software where a release is a discrete event customers upgrade to. Continuously deployed products generally need one dated changelog, with longer narrative posts for launches that deserve their own page. Who writes release notes? Whoever owns customer communication for the release — usually product marketing or the product manager, with engineering supplying what actually changed. The handoff between those two is where most release notes stall. What is the difference between release notes and a product update email? Release notes are the reference record and live on your site permanently. An update email is a distribution channel with a narrower selection, usually the two or three items worth interrupting someone for. The email should link back to the release notes, not replace them. ## Table of Contents - [The short version](#the-short-version) - [Where they actually differ](#where-they-actually-differ) - [Why the distinction is collapsing](#why-the-distinction-is-collapsing) - [What each format demands](#what-each-format-demands) - [Which one you need](#which-one-you-need) - [The part that doesn’t change](#the-part-that-doesnt-change) - [Related reading](#related-reading) Stop writing the changelog by hand The Changebot Agent drafts customer-ready updates from your GitHub history. Publishing is free. [Get Started for Free →](https://app.changebot.ai/signup) [← Back to Blog](/blog) # When changelogs Become Customer Retention Tools (Beyond Mere Obligations) URL: https://www.changebot.ai/blog/changelogs-as-customer-retention-tools/ Description: Most companies treat changelogs as a checkbox. Smart companies use them to save at-risk accounts and prove ongoing value. Here's how. Last updated: 2025-12-05 Best Practices # When changelogs Become Customer Retention Tools (Beyond Mere Obligations) [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder December 5, 2025 3 min read ![Illustration of changelog entries flowing toward a customer, with retention icons like circular arrows and a shield, representing changelogs as customer retention tools](/_astro/featured.nfffnZlS_ZeEl6h.webp) During a recent call with a Director of Product at a B2B SaaS company, she mentioned something that stuck with me. Her customer success team tracks product development velocity to show contract value to at-risk customers. Read that again. They’re using their changelog as a retention weapon. ## The Retention Signal You’re Ignoring When a customer is considering churning, what do they really want to know? - Is this product still being actively developed? - Are they listening to feedback? - Will this get better, or is this as good as it gets? Your changelog answers all three questions. But only if it exists. And only if it’s good. ## The Customer Success Playbook Here’s what smart CS teams are doing: **Before the renewal conversation:** They pull a summary of everything shipped in the customer’s contract period. Beyond “we shipped 47 features,” they say “here are the specific improvements that addressed the feedback you gave us in Q2.” **During QBRs:** They show development velocity as a value metric. “In the last quarter, we shipped X improvements to the workflows you use most.” **For at-risk accounts:** They show momentum. “I know you’ve had concerns about _specific issue_. Here’s what we’ve shipped to address it, and here’s what’s coming in the next 30 days.” One Director of Product described this as giving the CS team “ammunition” for these conversations. Without a clear record of what’s shipped and why it matters, CS teams end up saying “trust us, we’re working on it.” ## The Competitor Comparison Problem Here’s an uncomfortable truth: when prospects are evaluating you against competitors, they often check changelogs. A product-savvy buyer will look at both products’ update histories and ask: - Which one is shipping more frequently? - Which one is addressing customer feedback? - Which one seems more alive? I’ve lost deals because a competitor’s changelog showed weekly updates while mine showed monthly (or worse, quarterly). It didn’t matter that we’d shipped more total value. The perception was that they were more active. Your changelog is a signal of organizational health. Treat it like one. ## Turning Obligation into Asset Most companies think about changelogs like compliance: something you have to do, a box to check, a task to delegate to whoever has bandwidth. That mindset produces changelogs that sound like this: - “Fixed bug in settings page” - “Improved performance” - “Added new feature” Useless. These tell customers nothing about value. Compare to changelogs that sound like this: - “Settings now load 3x faster, so you spend less time waiting” - “You can now export reports in the format your finance team actually wants” - “The workflow you asked for in our feedback session is live” The difference goes beyond writing quality. The first treats the changelog as a log. The second treats it as a conversation with customers about why they should stay. ## The Proof Point for Value A Director of Product at a creator economy platform described their challenge perfectly: they need to maintain trust with creators who have many platform options. Every update is an opportunity to reinforce that the platform is investing in their success. For them, changelogs aren’t about transparency for its own sake. They’re about continuously earning the right to keep those creators on the platform. This is especially true in markets with: - Low switching costs - Many alternatives - Customers who actively weigh options If that sounds like your market, your changelog is existential. ## Making It Sustainable The challenge, of course, is that writing good changelogs takes time. Time that product teams don’t have. Time that gets deprioritized in favor of shipping the next thing. The solution isn’t “try harder.” It’s building systems that capture the context automatically. When a feature ships, the information about what it does and why it matters already exists — in the PRD, in the tickets, in the code itself. The question is whether that information makes it to the people who need it, in a format they can use. Teams that crack this unlock a flywheel: 1. Features ship with context attached 2. Customer-facing updates get generated automatically 3. CS teams have ammunition for retention conversations 4. Customers see ongoing value 5. Renewals become easier 6. More resources get allocated to building 7. More features ship The alternative is the opposite flywheel: features ship silently, customers wonder if anything is happening, CS teams scramble to prove value, renewals get harder, resources get cut. Your changelog is either working for you or against you. There’s no neutral. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # Changelogs: The PM's Secret Weapon URL: https://www.changebot.ai/blog/changelogs-the-pms-secret-weapon/ Description: Five ways product managers turn ordinary release notes into a customer magnet that prevents churn and drives expansion revenue. Last updated: 2024-12-20 Best Practices # Changelogs: The PM's Secret Weapon [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder December 20, 2024 6 min read ![Changelogs: The PM's Secret Weapon](/_astro/featured.BjQbr1-X_Z1TFCBk.webp) In the hustle of building and shipping features, it’s easy to overlook one of your most powerful, low-effort growth levers: **regular, well-crafted product updates**. Often treated as an afterthought, product updates can be a secret weapon. They don’t just keep current users in the loop—they can help retain existing customers, attract new ones, justify future price increases, boost expansion revenue, build trust, and even generate valuable customer testimonials. As one seasoned product professional noted: **“You’re leaving money on the table by not publishing frequent, benefits-focused product updates.”** In this guide, we’ll break down **5 ways to turn your product updates into a customer magnet**, pulling insights from extensive research and real-world examples. Let’s turn your product updates from “meh” status reports into must-read growth engines. ## About the Author “Who are you, and why do you care about updates so much?” Great question. I’m Brian Sierakowski, and I’ve run a bunch of saas products over my 15 year career. During my time as the CEO of Baremetics I had the good fortune to meet with tons of entrepreneurs looking to improve their metrics, and after dozens of calls I realized that the raw math of growing a saas business came down to a few “growth pillars.” You can **only** grow by:getting more new customers, increasing revenue from existing customers, reducing churn, increasing reactivations, and reducing downgrades. Most things you can do as a business can improve one or two of these areas, but as I kept meeting with founders (and gaining first hand experience) I realized that there’s one criminally underused resource that can improve all of the above: **frequently updating a public changelog**. The rest of this article covers five insights on how to make your product more “magnetic” by attracting new customers and keeping the ones you already have close. ## The Key Insights The five insights are how to: 1. Turn customer updates into a churn-prevention tool. 2. Attract new customers by making updates public. 3. Use updates to drive expansion revenue. 4. Set the stage for price increases. 5. Build trust and earn testimonials with your changelog. ## **1\. Turn Updates into a Churn-Prevention Tool** **Key Insight:** Without frequent updates, customers may assume your product is stagnating. Product updates serve as tangible evidence that you’re working hard to improve the tool they pay for. We have two quotes we share all the time: 1. You need to get credit for your code. 2. You need to send more updates than invoices. For product managers, this is crucial. Customers who see a constant stream of improvements are more likely to feel your team is invested in their success. This consistency sends a subtle yet powerful message: “We value you and are actively working to enhance your experience.” It’s a moment of re-selling your product at every invoice cycle. **Action Step:** Create a simple, repeatable process for updating customers at least monthly—whether it’s a short blog post, an in-app message, or a release note email. Even small improvements (“faster page load times,” “bug fix for easier admin access”) remind customers you’re invested in their success. (Or use [Changebot](https://www.changebot.ai/) to write your updates for you.) ## **2\. Attract New Customers by Making Updates Public** **Key Insight:** Potential customers review past product updates before deciding to buy. This insight is shared with great detail in our ebook “ [The Art of The Update](https://www.changebot.ai/blog/the-art-of-the-update#toc-why-should-we-send-customer-updates?)” ← _if you want to read more, this link sends you directly to the section “why should we send customer updates?”_ To paraphrase for the purpose of this section: Prospective customers aren’t using the product and may not understand the significance of each update, so their evaluation is binary: ‘Do they frequently improve the product, yes or no?’ As a PM, ensure that updates are visible not only to existing users but also to prospects. Public, easy-to-find product updates signal to newcomers that the product is actively maintained and improved. This helps differentiate you from competitors who appear stagnant. **Action Step:** Maintain a public changelog or “What’s New” page linked from your marketing site. Consider surfacing recent highlights directly on your homepage or pricing page. When sales or marketing teams talk to leads, encourage them to mention frequent updates as a key differentiator. ‍ [Changebot](https://www.changebot.ai/) provides a hosted public updates page so you can share your updates with the world instantly. ## **3\. Use Updates to Drive Expansion Revenue** **Key Insight:** “As the complexity of a product increases, the proportion of customers familiar with all of its features decreases.” Your updates can spotlight features customers haven’t fully explored—especially ones in higher-tier plans or paid add-ons. For product managers, this is your chance to re-introduce underutilized functionality. Frequent reminders can be the nudge customers need to upgrade or purchase an add-on they didn’t realize existed. An ex-customer once told the original author: “We would have stayed if we would have known that (feature) existed.” Don’t let good customers churn on your watch. **Action Step:** Include a brief highlight of a lesser-known feature or add-on in each update. Clarify who can access it (“Available to Business plan customers and above”) and how it enhances their workflow. Over time, these reminders can prompt organic expansions and upgrades. [Changebot](https://www.changebot.ai/) considers your entire product deployment history with each update, automatically referencing other related (but potentially hidden features.) **‍** ## **4\. Set the Stage for Price Increases** **Key Insight:** Down the road, you may need to raise prices. Without a track record of frequent, meaningful improvements, justifying a higher cost is tough. With a robust history of product updates, you can confidently say, “Look at the value we’ve delivered over time.” By communicating improvements consistently—features, speed boosts, integrations, user experience enhancements—you build a narrative of continuous improvement. When price increase season rolls around, customers can see for themselves that they’re paying more for a product that’s measurably better than it was when they first signed on. **Action Step:** Keep your updates archived and easily accessible. When announcing a price increase, link to these past updates or include a summary of your most significant achievements. This transparency helps customers understand the “why” behind the new price point. [Changebot](https://www.changebot.ai/) keeps your updates in a publicly accessible place, and the Update Engine is tuned to maximize the number of updates written, ensuring that anyone looking through is blown away by the number of improvements. ## **5\. Build Trust and Earn Testimonials** **Key Insight:** “Frequent customer updates start a conversation. Each customer interaction is a lottery ticket, and the jackpot is them responding: ‘This is great!’” Over time, these positive responses can yield testimonials, referrals, and case studies. For product managers, trust is currency. Customers are more likely to share feedback, respond to surveys, and even help with beta tests when they’ve seen genuine care and consistency from your team. A steady cadence of updates fosters an environment where customers feel heard and appreciated. **Action Step:** After sharing each update, invite feedback—“We’d love to know what you think!”—and capture positive responses as testimonials. Over time, you’ll build a backlog of social proof that marketing and sales can leverage. This positive feedback loop helps PMs strengthen their roadmap decisions and align features more closely with customer needs. [Changebot](https://www.changebot.ai/) writes the update so you can focus on looping in key quotes from customers and team members. ## ‍ **Conclusion: Your Updates = Your Competitive Edge** Product updates aren’t just housekeeping. They’re the heartbeat of your product narrative, showing that you’re listening, evolving, and investing in your customers’ success. By embracing a schedule, making updates public, highlighting expansions, preparing for future price changes, and using them to build trust, you’re transforming ordinary release notes into a magnet for customers new and old. As one product leader put it: “Remember, you’re already improving your product; you deserve credit for that hard work.” With these five strategies, your updates can become a secret weapon—turning routine communication into a source of sustainable growth. If you haven’t noticed the notes throughout the article—I’m a bit biased but I happen to think that Changebot is a critical tool for busy teams shipping a lot of code. [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # CodeRabbit vs Product-Aware Summaries URL: https://www.changebot.ai/blog/coderabbit-vs-product-aware-summaries/ Description: Why product framing beats commit-level blurbs when support and marketing need customer impact. Last updated: 2025-11-15 Best Practices # CodeRabbit vs Product-Aware Summaries [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder November 15, 2025 3 min read ![Two paths from code to customer: raw commits vs product-aware summaries](/_astro/featured.jPjj9por_1t7ART.webp) Most teams already have an automated tool that scrapes commits and spits out a list of changes. It feels convenient until support gets blindsided and marketing has to rewrite everything from scratch. On calls with Product team execs, we keep hearing: > “CodeRabbit logs releases but it’s engineer-centric. Support finds out after the fact, and the blurbs don’t line up with what PMs say.” They’ve asked to pilot Changebot alongside their AI powered code review tools to see if **product-aware summaries**, grounded in code _and_ customer value, would keep support and PMM ahead of launches without spamming users. Here’s the breakdown we shared. ## 1) Commit blurbs vs product framing - **Commit-level blurbs:** Repeat PR titles, assume readers know the codebase, bury the “why,” and often don’t match the original PM narrative. - **Product-aware summaries:** Start from the code, but translate into customer-facing value (“login reliability restored,” “payout speed up 18% for debit users”) with the right audience in mind. Support, CSMs, and PMM need customer impact and who’s affected. ## 2) One size does _not_ fit all audiences For high-velocity consumer apps: - **Consumers:** Sensitive to over-communication; cadence must be tight. - **Support/MX:** Needs every fix _today_ to triage tickets. - **Product/Eng:** Wants proof of work without another meeting. You can’t route a commit dump by audience, but you can filter and push product-aware summaries to: - Internal Slack for support/CS. - Compact investor/leadership bullets. - Throttled consumer-facing updates. ## 3) Cadence and signal-to-noise Commit feeds fire on every merge. For most teams that’s too granular a view. Product-aware systems: - Tag “key updates” that actually change customer experience. - Distinguish staging/beta vs production so you don’t announce ghost features. - Let you bundle into weekly/biweekly recaps while keeping a full internal trail. ## 4) Support-first, not engineer-first One CEO’s complaint: “We changed authentication internals but support didn’t go back to the “I can’t login” tickets because the blurb didn’t say ‘customers can log in again.’” Product-aware summaries rewrite the impact in support language: - Issue resolved? Who’s unblocked? - Any known edge cases? - Where to point users (help article / status)? That’s the difference between busywork and fewer tickets. ## 5) Learning your voice over time CodeRabbit-level blurbs are static. Product-aware summaries get better as you edit: - Feed past PMM/support copy as tone examples. - Edit and save; the system learns your brevity, style, and banned phrases. - Move from “rewrite from scratch” to “light edit and ship.” ## 6) What a side-by-side pilot could look like **Scope:** Run Changebot in parallel with CodeRabbit on the next sprint. - Connect GitHub (no new fields for engineers). - Auto-generate weekly recap + spotlights for fixes/features. - Push internal feed to support Slack; throttle external pushes. - Compare clarity/actionability vs CodeRabbit output. **Success criteria:** - Support learns about fixes before tickets escalate. - PMM can paste/edit, not rewrite. - No over-communication to millions of consumers. ## Takeaways Commit scrapers are fine for engineers, but we introduce a failure state when we expand the audience beyond developers. PMM, Support, Sales, and Marketing need customer impact, readiness, and voice. If support and marketing are still blindsided, the automation isn’t working. Product-aware summaries: - Translate code into outcomes. - Respect audience and cadence. - Learn your tone. - Give you credit for the code _and_ the story. [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # Developers Lose 10 Hours a Week to Status Theater URL: https://www.changebot.ai/blog/developers-lose-10-hours-a-week-to-status-theater/ Description: Your engineering team spends 5-10 hours every week in meetings explaining what they built. Then you wonder why they're not shipping fast enough. Last updated: 2026-02-02 Best Practices # Developers Lose 10 Hours a Week to Status Theater [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder February 2, 2026 4 min read ![Clock split between productive coding and wasted status meetings, with a chain of figures passing information in a telephone game](/_astro/featured.KqEEKq0c_1iiJvF.webp) During a market feedback conversation, an advisor laid out the math that should make every engineering leader uncomfortable: developers spend five to ten hours a week in meetings explaining what they’ve built. That’s 20-40 hours a month, per developer, spent narrating work instead of doing it. (If you have the heart, do the math of what 40 hours per month per developer costs you on a yearly basis.) Then, the next month, leadership asks why the team isn’t shipping fast enough. He paused and said: “That should be your pitch.” ## The meeting tax Here’s how status theater works in practice. The engineering team builds something. Then they explain it to the product manager. The product manager explains it to the product marketing team. Product marketing explains it to sales. Sales explains it to customers. At each step, the team loses context, simplifies details, and the message drifts further from what actually shipped. A product leader at a physical access management company described this as a “telephone game.” By the time information passes through engineering, PM, and product marketing, the update is either late, inaccurate, or both. He’d seen launches where someone told product marketing on Wednesday that something was going live on Monday, leaving no time for proper communication. And this isn’t a small company problem. A standards organization we spoke with has 4,000+ members requesting “45-minute” product update calls just to understand what changed. Their product managers spend significant time in these recurring sessions, walking through changes that an async update could have covered. ## The irony of engineering velocity The irony gets worse when you factor in AI-accelerated engineering. Teams are adopting tools like Claude Code, Cursor, and Copilot to ship faster. Engineering velocity is genuinely increasing. Some founders describe it as shipping 10x more code than before. The communication infrastructure hasn’t scaled at all. One founder we spoke with captured the paradox: “We don’t have a problem with our product. We can’t keep up with the pace of delivery.” The engineering team is outrunning the organization’s ability to process and communicate what they’re building. The result: developers shipping faster than ever, and then spending the same 5-10 hours per week, maybe more, in meetings explaining what they shipped. The net productivity gain from AI tooling gets eaten by the communication overhead. ## What developers actually hate Ask any engineer what they dread most about the job, and “posting updates to Slack” or “sitting in status meetings” will come up fast. An AI strategy leader told us about the Slack update channel that exists at every company: “I have this Slack channel. I’m intimately familiar with it from every role I’ve had.” Every time something goes to production, someone has to write a message in that channel. It’s manual, it’s tedious, and it competes directly with the work the team actually wants to be doing. At a video messaging platform, the engineering team’s release communication consisted of posting to an internal Slack channel. Support, marketing, and sales all monitored that channel as their source of truth for what shipped. If the developer didn’t post, nobody knew. The system was entirely dependent on someone remembering to do the thing they liked least about their job. ## The real cost isn’t meetings The meeting time is visible. What’s harder to measure is the opportunity cost. Every hour a developer spends in a status meeting is an hour they’re not building. Every hour a PM spends assembling update emails is an hour they’re not talking to customers. Every hour a marketing person spends chasing engineering for “what shipped this month” is an hour they’re not working on growth. Scale that across a 20-person team and you’re looking at hundreds of hours per month dedicated to the act of describing work, rather than doing it. For a startup trying to outpace larger competitors, that’s a massive tax on your most expensive resource. And the output of all those meetings? Often it’s still incomplete. A documentation strategist told us that “no one person has complete cross-functional knowledge” to produce the full picture. The engineer knows the technical details, the PM knows the business justification, and the marketer knows how to frame it for customers. No single meeting captures all three perspectives, so the update that finally reaches customers is always a compromise. ## Status should be a byproduct, not a ceremony Better meetings won’t fix this. Neither will better Slack post templates. Neither will hiring a dedicated person to chase everyone for updates. The fix is making status a byproduct of shipping. When code merges, the update should generate itself, pulling from the actual changes, the product context, and the business context to produce something that’s useful to every stakeholder, whether that’s the engineering lead who wants a technical summary or the CEO who wants to know what value customers received. This isn’t a fantasy. The information already exists. It’s in the code diffs, the PR descriptions, the ticket context, and the product’s historical patterns. The problem is that extracting it has always required a human to sit in a room and narrate it. It doesn’t have to. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # Feeding Your AI Agents: Why Product Updates Need Structure URL: https://www.changebot.ai/blog/feeding-your-ai-agents-why-product-updates-need-structure/ Description: AI-forward companies are building internal agents for sales enablement, support, and more. But these agents are starving for reliable product change data. Here's how to fix that. Last updated: 2026-01-05 Best Practices # Feeding Your AI Agents: Why Product Updates Need Structure [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder January 5, 2026 5 min read ![AI agent icon with empty fuel gauge surrounded by disconnected data sources](/_astro/featured.SIA2wRub_Z8rzpT.webp) The most AI-forward companies I talk to have a surprising problem: their agents are starving. They have compute. They have model access. What they lack is data. Specifically for structured, reliable data about the reality of their team and product. ## The agent-building boom Over the past year I’ve watched a shift happen. Product marketers, operations leads, and technical PMs aren’t just using AI tools, they’re building them. During a recent conversation, a product marketer at a large enterprise company told me she “hires an agent” whenever there isn’t staffing for a new project. She’s built a conversational agent for sales enablement that answers questions about product features and pricing. She’s building another agent to rewrite value statements based on product updates and brand guidelines. She’s not an engineer. She’s a product marketer who learned that agents can fill gaps in her org faster than headcount requests can get approved. And she’s not alone. In call after call, I’m hearing about internal RAG pipelines, AI copilots trained on company knowledge, and automated workflows that need to know what the product is doing. The problem? These agents rest on quicksand. ## Stale docs, stale answers Here’s the typical pattern: Someone builds an internal agent. They connect it to Notion, or Confluence, or a shared drive full of product documentation. And the agent works… well, sort of. It can answer questions about features the team documented six months ago. Then someone asks: “What changed in the last release?” At best you get nothing, and at worst you get hallucinations. The agent doesn’t know because nobody told it. The documentation is stale. The release notes live in a Slack thread somewhere. The actual truth of what shipped exists only in the heads of engineers who have already moved on to the next sprint. A CEO at a CRM startup described this perfectly: they use an AI copilot that sits on top of all their notes and CRM data. “You can ask it anything about your customers,” he said. But ask it about your own product changes? It draws a blank. ## Why product updates are different Product documentation is static. It describes the product as it exists at a specific moment. Product updates are dynamic. They describe what changed, when, and why it matters. Most internal AI systems handle the static case well. They’re great at answering “How does feature X work?” They fail at “What’s new this month?” or “Did we fix that bug the customer reported?” The sales enablement agent that can’t answer “what shipped lately” is worse than useless because it’s confidently wrong. It gives answers based on outdated information, and the sales rep has no way to know. ## The missing data layer What AI-forward teams actually need is a structured feed of product changes that can serve as a knowledge source for their agents. Not raw commits. Not Jira ticket dumps. A curated, contextualized stream of: - What changed - When it shipped - Why it matters to customers - What audience it affects This becomes the foundation layer that other AI systems can build on. Your sales enablement agent can query it: “What customer-facing changes shipped this month?” Your support bot can reference it: “Here’s the fix that addressed your reported issue.” Your value statement rewriter can use it as input: “Based on these recent changes, update the product positioning.” ## Beyond communication: AI infrastructure This is a shift in how to think about product update systems. The first-order value is communication: keeping humans informed about what shipped. That’s valuable on its own. The second-order value is infrastructure: providing structured data that other systems can consume. When you capture your product updates in a consistent, queryable format, they become a building block. Every internal AI tool you build can tap into the same source of truth. No more brittle integrations with scattered documentation. No more agents hallucinating about features that don’t exist. ## What structured looks like A structured product update feed isn’t just a changelog. It includes: **Temporal data**: What changed and when, with precision. Your agent needs to know if something shipped yesterday or last quarter. **Audience tagging**: Is this change relevant to customers? Internal teams? Specific segments? Your sales agent and your support agent need different slices. **Semantic context**: What kind of change is this? New feature? Bug fix? Performance improvement? Security update? The category matters for how agents should surface it. **Benefit framing**: Beyond the technical change, what does it mean? “Added database index” is useless to an agent. “Improved dashboard load time by 40%” is actionable. **Relationship data**: How does this change relate to previous changes? To customer requests? To roadmap items? Rich connections enable richer agent responses. ## The compounding advantage Companies that get this right have a compounding advantage. Every product change automatically enriches their internal AI capabilities. Their sales team has up-to-date ammunition. Their support team can reference recent fixes. Their product marketing can generate accurate summaries without manual research. Meanwhile, companies without structured product data stay in manual mode. Every new agent they build requires its own brittle integration. Every knowledge base gets stale. Every RAG pipeline surfaces outdated information. The AI-forward PMM I mentioned earlier understood this intuitively. She wanted Changebot as a data source she could pipe into her other agents. “If your tool helps internally,” she said, “that sounds great.” ## Start with the feed If you’re building internal AI capabilities, start by asking: where does product change data come from? If the answer is “scattered across Jira, Slack, and the heads of engineers,” you have a data problem that will undermine every agent you build. Fix the data problem first. Create a structured, automated feed of product changes. Then let your agents consume it. That is also why Changebot is moving toward the agent-first changelog. The update feed should not only sit behind an API waiting for another system to query it. It should be writable from the agent surfaces where teams already work. Ask the Changebot Agent for a monthly recap. Use MCP from Claude Code to draft a customer update. Bring in a release note generated from Linear. The same structured changelog can serve humans, support bots, sales agents, and search systems because the publishing workflow keeps the data current. The agents you build will be smarter. The knowledge they surface will be accurate. And you’ll have infrastructure that gets better with every release, not documentation that rots. * * * If you’re building internal AI agents and struggling to keep them informed about product changes, [start free](https://app.changebot.ai/signup) and give them a changelog feed that stays current. To see the MCP publishing workflow, read the [Changebot MCP example](/blog/publish-your-changelog-from-claude-code). [← Back to Blog](/blog) # Backlog to Spotlight URL: https://www.changebot.ai/blog/from-backlog-to-spotlight/ Description: How Changebot's Recaps and Spotlights turn buried product work into customer-ready updates. Last updated: 2025-06-03 Best Practices # Backlog to Spotlight [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder June 3, 2025 3 min read ![A spotlight shining on a changelog entry rising from a backlog pile](/_astro/featured.B3h1Juci_Z25VpNU.webp) Every product team has committed to sharing monthly updates with customers. And every product team knows how that tends to go: the update shows up late, or it never shows up at all. The process is brutal. Someone has to figure out what actually shipped last month. Then decide what matters enough to talk about. Then translate technical work into customer benefits. Then turn it into something polished and customer-friendly. That’s a multi-hour process on a good month. On a bad month, it stretches into days, and by then the next month’s work is piling up. Changebot solves this with two core features: **Recaps** and **Spotlights**. Here’s how they work. ## Recaps: Your monthly update in 60 seconds Need a weekly digest? Done. Monthly newsletter? Easy. Quarterly board deck? Recaps handle that too. Instead of spending hours digging through Jira tickets and PR titles, Changebot scans your code history and generates a customer-ready recap automatically. It knows what shipped, understands the customer impact, and writes it in your brand voice. What used to take hours (or days) now runs in about 60 seconds. ### Why Recaps are the starting point for most teams When new customers ask where to begin with Changebot, we almost always point them to Recaps. Here’s why: **You’ve already committed to this.** Your team has probably promised monthly updates to customers, your board, or your internal stakeholders. That commitment exists regardless of whether you have time to fulfill it. **The bottleneck is research.** The hardest part of a monthly update is uncovering what actually shipped, deciding what’s worth mentioning, and understanding the customer benefit of each change. Changebot handles the research so you can focus on the writing. **Consistency compounds.** One monthly recap is nice. Twelve monthly recaps show customers you’re actively improving the product. That trail of progress builds trust in a way that sporadic announcements never will. ## Spotlights: The narrative for major launches While Recaps summarize the full picture, Spotlights zoom in on a single feature or improvement that deserves its own moment. Spotlights tell stories. Where Recaps give you bullet points, Spotlights explain what the feature does, why it matters, and how customers benefit. They’re perfect for: - **Internal announcements:** Get sales, support, and leadership up to speed before you go external. - **Customer communications:** Share directly with customers who’ve been waiting for this feature. - **Marketing launches:** Use as the foundation for blog posts, emails, and social content. The key difference: Recaps are comprehensive summaries. Spotlights tell the story of work that deserves special attention. ## The internal communication problem Here’s something we’ve noticed across dozens of product teams: most companies aren’t sharing enough updates with customers because they’re not communicating well internally first. Think about it. When sales, support, marketing, and leadership all know what’s shipping and how it benefits customers, looping in customers is easy. You just extend the conversation outward. On the flip side, if your own team is fuzzy on what shipped last month, customer communication becomes almost impossible. You can’t tell customers what you don’t know yourself. This is why Recaps work so well as a starting point. They serve your team first. When product, sales, and support all see the same recap, everyone speaks the same language. Customer updates become a natural extension of internal communication, not a separate (and often neglected) process. ## How the two features work together Most Changebot customers use both features in a rhythm: 1. **Weekly or monthly Recaps** keep everyone informed on the full scope of product changes. These go to internal stakeholders first, then to customers via changelog, email, or Slack. 2. **Spotlights for major launches** give important features the attention they deserve. These get shared internally to brief the team, then externally to customers and prospects. The recap is the heartbeat. The spotlight is the celebration. ## What this looks like in practice **Before Changebot:** Product manager spends 4-6 hours at the end of each month pulling together an update. It’s always late. Half the team doesn’t see it. Customers get a watered-down version, if they get anything at all. **After Changebot:** Recap generates in 60 seconds, the PM reviews and makes light edits, and the internal team sees it the same day. Customers get a polished update on schedule. When a major feature ships, a Spotlight goes out within hours, not weeks. The backlog of “we should announce this” items? It stops growing. Because now you have a system that turns shipped work into customer-ready updates automatically. That’s the shift, backlog to spotlight. [← Back to Blog](/blog) # Five Hours Down to Five Minutes: The Monthly Recap Problem URL: https://www.changebot.ai/blog/from-five-hours-to-five-minutes/ Description: Monthly product recaps shouldn't take days. Here's why they do, and how to reclaim that time. Last updated: 2025-12-22 Best Practices # Five Hours Down to Five Minutes: The Monthly Recap Problem [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder December 22, 2025 5 min read ![Illustration showing scattered Jira tickets, GitHub PRs and Slack messages flowing through a funnel into a clean summary dashboard, representing the transformation from chaotic manual recaps to streamlined automation](/_astro/featured.0eHPIBRu_Z2fRlXi.webp) “That one button just saved me five hours… every single month.” A Head of Product said this after watching a monthly recap get generated in about thirty seconds. She’d been doing this process for years, and the time savings hit her immediately. Five hours. That’s what many teams spend producing their monthly customer update. Some teams I’ve talked to take days. And this happens every single month. Where does all that time go? ## The Hidden Time Sinks Monthly recaps look simple: list what shipped, write a summary, send it out. In practice, they consume time through: **Discovery.** What actually shipped last month? This requires checking Jira, asking engineering, reviewing release notes, scanning Slack… and still missing things. **Translation.** Technical changes need to become customer language. “Implemented rate limiting on API endpoints” becomes “improved reliability during high-traffic periods.” This requires understanding both the technical change and the customer impact. **Coordination.** The draft needs review. Engineering confirms accuracy. Marketing approves messaging. Legal checks the language. Each handoff adds delays. **Formatting.** Different channels need different formats. The blog post isn’t the same as the email isn’t the same as the in-app notification. Same content, separate production efforts. **Catch-up.** By the time you sit down to write December’s recap, November feels like ancient history. You’re reconstructing context you had three weeks ago but have since lost. Add these up, and “just write the monthly update” becomes a multi-day project. ## Why This Matters Five hours per month is 60 hours per year. For a product leader, that’s nearly two full work weeks spent summarizing what their team already did. The cost goes beyond time. Consider the opportunity cost: **Delayed communication.** The longer recaps take, the later they go out. Some teams are still finalizing November’s update in mid-December. **Reduced frequency.** The pain of monthly recaps prevents weekly or bi-weekly updates that might serve customers better. **Inconsistent quality.** When teams rush recaps (because they always take longer than expected), quality suffers. **Burnout.** Nobody enjoys this work. It’s widely seen as a necessary chore, not valuable contribution. Most critically: if recaps take this long, they often don’t happen at all. Teams skip months. Updates slip: monthly becomes quarterly becomes “when we remember.” ## The Archaeology Problem A Director of Product described their release process as “controlled chaos.” By the end of the month, figuring out what shipped is an archaeological dig. The information exists somewhere: - Merged PRs in GitHub - Completed tickets in Jira - Announcements in Slack channels - Notes from standup meetings - Memories of people who worked on things It’s scattered across systems, fragmented across time, and encoded in language that needs translation. The person writing the recap becomes a detective, piecing together a narrative from evidence left behind. This is valuable work, but it’s work that shouldn’t be necessary. ## What Five Hours Buys You Here’s what else you could do with five hours per month: - Talk to five customers - Review analytics and identify trends - Write a detailed product brief - Mentor a team member - Take a half-day off Every hour spent reconstructing what shipped is an hour not spent on higher-leverage work. And unlike strategic thinking, recap writing doesn’t compound. Next month, you begin again with nothing. ## Breaking Down the Problem To reduce recap time, attack each component: **Discovery → Automation.** If the information already lives in systems (GitHub, Jira, deployment logs), extract it programmatically. Don’t make humans hunt for data computers can aggregate. **Translation → Templates.** Most changes fall into categories: new features, improvements, bug fixes. Each category has a translation pattern. Templates reduce creative effort per item. **Coordination → Parallel workflows.** Instead of sequential review (engineering → marketing → legal), structure reviews to happen in parallel with clear ownership. **Formatting → Single source.** Write once in a format you can transform. Don’t rewrite for each channel. **Catch-up → Continuous capture.** Don’t reconstruct context at month-end. Capture it continuously as changes ship. ## The Gold Standard The goal goes beyond faster recaps. Aim for recaps that barely require effort. Here’s what that looks like: 1. At month-end, you open a dashboard 2. Key changes are already identified and drafted 3. You review, make light edits, approve 4. Distribution happens automatically to configured channels Total time: 15-30 minutes. Not five hours. Not days. The human role shifts from “write the recap” to “approve the recap.” That’s a fundamentally different level of effort. ## Why This Remains Unsolved If this is so painful, why do teams still do it manually? **Integration complexity.** The information lives in many systems. Connecting them requires technical work that’s hard to rank against feature development. **Translation difficulty.** Converting technical changes to customer language requires judgment. Until recently, computers couldn’t handle this well. **Low urgency.** Monthly recaps are never the most urgent thing. They get deprioritized, which means the pain continues but never triggers action. **Accepted suffering.** Teams assume this comes with the territory. “Recaps take days” becomes normalized rather than questioned. The good news: these barriers are now surmountable. The technical integration is simpler than before. AI can handle the translation. And the cumulative time cost is large enough to justify action. ## Making the Change If you’re spending hours on monthly recaps, here’s a path forward: **Audit your process.** Track where time actually goes. Discovery? Writing? Review? Formatting? You can’t optimize what you don’t measure. **Identify the biggest bottleneck.** Often it’s discovery or coordination. Start there. **Automate discovery first.** The most common wins come from automatically aggregating what shipped, before any human touches it. **Set a target.** “Under one hour” is achievable for most teams. “Under 30 minutes” is achievable with the right systems. **Measure the improvement.** Track time spent over a few months. Celebrate the wins. ## The Bigger Picture Monthly recaps are a proxy for a larger challenge: turning continuous product development into periodic customer communication. The fundamental problem is temporal mismatch. Engineering ships continuously. Communication happens in batches. Bridging that gap is work, and that work falls on someone. The long-term solution goes beyond faster recaps. Build communication systems that keep pace with development systems. When shipping automatically generates customer-ready summaries, the recap doesn’t need writing. It needs review. That’s the difference between five hours and five minutes. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # Getting Paid to Build Is Easy. Getting Credit for It? Hard. URL: https://www.changebot.ai/blog/getting-paid-to-build-is-easy/ Description: Your team is shipping features every week. Your customers think you haven't improved the product in months. Here's why the credit gap exists, and what it costs you. Last updated: 2025-12-23 Best Practices # Getting Paid to Build Is Easy. Getting Credit for It? Hard. [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder December 23, 2025 4 min read ![Iceberg visualization showing a small visible tip above the waterline with a few feature cards, and a massive collection of code commits, bug fixes, and shipped work hidden below the surface](/_astro/featured.BbJqLC4p_sDNm9.webp) Years ago, I worked at a dev firm that charged premium rates per hour per developer. We deployed in pairs, doubling our daily rate. Clients had one reasonable question: “What exactly are we getting for all this money?” We made a decision: every client got a weekly update. No exceptions. Every Friday, a summary of everything the team built that week landed in their inbox, ready for Monday morning. This wasn’t about transparency for its own sake. When you’re billing enterprise rates, silence is dangerous. Silence lets clients fill the void with doubt. Most companies don’t charge hundreds of dollars an hour. Most still have the same problem. ## The Credit Gap Here’s a pattern I see in nearly every product organization I talk to: Engineering ships constantly. Customers think nothing is happening. A VP of Product Marketing at an observability company described it this way: one of the most important reasons for churn is that customers don’t know what they have. They cancel for missing features that already exist. They leave for competitors who do the same things, just with better communication. At a consumer fintech company, the CEO explained that their support team frequently discovers changes after the fact. The team produces updates, but the people who need the information most (the ones talking to customers daily) learn about features when customers complain. A Director of Product at a workplace management company said CSMs constantly flag micro-details the product team missed communicating. After a major overhaul, customers care about every small change. The team can’t keep up. The work is happening. The credit isn’t. ## What Invisible Work Costs You The business impact is real and measurable. **Churn.** Customers leave for problems you’ve already solved. They just didn’t know. A VP of Product Marketing put it bluntly: “To me, one of the most important reasons for churn is like the customer just doesn’t know what we have done.” **Support load.** When customers don’t know about fixes or improvements, they keep filing tickets. Your support team spends time on problems that no longer exist. **Billing friction.** For consultancies and agencies, the question “what have you been doing?” is an indictment. Every hour of work that isn’t communicated is an hour the client questions. **Lost expansion.** You can’t upsell features customers don’t know about. Product updates drive expansion, not just retention. **Internal misalignment.** If your own sales team doesn’t know what shipped, they’re selling blind. If your marketing team doesn’t know, they’re positioning against stale information. ## Why This Keeps Happening The gap persists because communicating work is genuinely hard. Writing good updates requires understanding both the technical change and the customer impact. That’s rare — engineers know what they built and product marketers know how to position it. The person who can do both often doesn’t exist, or doesn’t have time. A product manager at a creator economy company described the challenge: “Engineering does way more than anyone sees. New features are just the tip of it.” The team has a process for announcing big features. Everything else (the improvements, the fixes, the optimizations) disappears into the void. At an enterprise data management company planning a move to CI/CD, the documentation burden is the blocker. They can technically ship faster, but they can’t communicate faster — so they don’t ship faster. The faster you build, the harder this gets. Quarterly releases give you time to assemble a changelog. Continuous delivery means the communication debt compounds daily. ## The Lesson Back at the dev firm, those weekly updates did more than justify invoices. When the bill arrived, clients could point to the update and see exactly what they paid for. No surprises. No awkward conversations. They built trust. Clients who see consistent progress trust the team, extend contracts, and refer other clients. They caught problems early. Sometimes writing the update revealed that we hadn’t actually delivered what we thought we had. The communication forcing function improved the work itself. They created advocates. Clients who received regular updates talked about us differently. They could explain what we were doing. They became salespeople for our services. None of this happened by accident. It happened because we treated communication as part of the engagement, not an afterthought. ## Getting Credit You’ve Earned The fix is simple in theory, hard in practice. **Capture context at the source.** The best time to document why a change matters is during the build, not three weeks later when you’re assembling a recap. **Lower the activation energy.** If writing updates requires a PM to reconstruct context from Jira tickets and interrogate engineers, it won’t happen consistently. Make the path of least resistance produce good communication. **Push to where people are.** An update that lives in a wiki no one checks is worse than no update. Meet your audiences where they already work. **Make it sustainable.** One great monthly update is nice. Fifty-two weekly updates that people can count on changes behavior. ## The Uncomfortable Math Consider this: if your team ships 100 improvements this year and customers know about 10 of them, are you capturing 100% of the value or 10%? The work happened — your team spent the engineering hours, maintained the infrastructure, and deployed the code. From the customer’s perspective, only the visible work exists. You’re already doing the hard part. You’re building. The question is whether you’re getting credit for it, or leaving that credit on the table for competitors who communicate better. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # Here's how Github uses their developers to write better changelogs URL: https://www.changebot.ai/blog/heres-how-github-uses-their-developers-to-write-better-changelogs/ Description: Getting customer quotes slows down your changelog—here's how GitHub uses developer quotes to maintain speed while building trust. Last updated: 2024-12-03 Best Practices # Here's how Github uses their developers to write better changelogs [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder December 3, 2024 3 min read ![Here's how Github uses their developers to write better changelogs](/_astro/featured.Bg_Rsrbv_12IQ7i.webp) Including customer quotes is a top tier changelog technique. Why? Because it’s always better to have someone else say something nice about you, especially when that person actively pays for your product. Think of it as a micro testimonial. However this introduces two problems. First, you need to loop a customer into your changelog release cycle, which means slowing down the process. Second, you can’t rely on your customers to transfer all the necessary technical details, especially if you have a product with a technical ICP. To learn how to solve both of these problems at once we can take a look at how our friends at GitHub handle it. **Their secret technique is to have a staff developer write a quote the same way an end user would.** This works especially well for them because Github sells primarily to developers, so they can capture this “customer language” in the form of quotes from their development team. Let’s review an example from their update titled “ [GitHub Copilot Chat now generally available for organizations and individuals.](https://github.blog/2023-12-29-github-copilot-chat-now-generally-available-for-organizations-and-individuals/)” Below is an example of one of these quotes from GitHub’s Principal Solutions Engineer, David Losert. You don’t need to read it word for word, but take a quick skim to see how a pro level developer quote looks: ![GitHub Developer Quote](/_astro/github-developer-quote.BKma_wfJ_Z2vTtTJ.webp) This is a serious quote! Two full paragraphs from a very senior engineer at Github, with a specific real world scenario. Since Github sells to and is used by engineers, this stands in for a customer quote in a pretty compelling way. Of the 1,000 words in the update, almost 600 are directly from their developers. This is specifically a good approach for Github, but also generally good to get a quote from your development team. > **“One benefit in frequent, detailed customer updates is building trust. It’s really hard to trust someone you never hear from, and hearing directly from the development team further builds that trust.”** It’s like when the chef of a fancy restaurant comes out to talk to you. ![The Bear - Chef](/_astro/the-bear.C0IQTTFw_14sXaF.webp) For some bonus points Github also **embraces being multimedia** by including a video of the update as well since this was announced at their conference, they smartly included a 10 minute clip during the announcement: ![GitHub Video Clip](/_astro/github-video-clip.BTa4Rvmk_1IkSX4.webp) While adding video adds a considerable amount of work to the update, I do like providing the option for the people who prefer video, and for the distribution. This video is on YouTube with 81k views, and comments are open allowing them to get messages like this: ![GitHub YouTube Comment](/_astro/github-youtube-comment.DY-l9xuL_ZzEyLK.webp) **They could farm these comments for customer quotes, and since it’s YouTube there’s also plenty of complaints they could use to make some improvements.** * * * If you’ve made it this far but still aren’t sure how to implement developer quotes in your updates, Changebot can help! We’ll write the first draft of all relevant updates and can notify your developers allowing them to add a short quote, all on autopilot. * * * Two more positive notes on Github’s updates: - When talking about tech they **increase clarity by addressing the common questions up front**. For example, they specify that copilot chat is powered by GPT-4, which is a phrase likely everyone who’s familiar with copilot will understand, and, one that most people would be happy with. (of course with consideration to the wide array of opinions on AI technologies, no one is happy about everything.) - Github is **on a schedule with customer updates**, constantly updating their blog with product updates and developments from the field, averaging 3-4 updates a month! For a bit of constructive criticism I was surprised **they weren’t explicit on customer benefits**. AI tools for developers are prime to say “your company will save X money, Y time, and get through your backlog X00% faster.” They hit on it in the video “Even adding a small feature can take hours out of your day.” This last point of not taking the final step to customer benefit is extremely common and drives me a bit crazy. I think to myself as companies release feature updates “what was the point of building this? How does this make our business stronger? Why are we here?” Perhaps Github specifically avoids this language because developers hate being “sold” to, but there’s plenty of room for Github to walk up to that line. The next time you’re writing an update consider if a quick note from the head chef wouldn’t help communicate the benefits in a fast and effective way. [← Back to Blog](/blog) # High-Velocity PMM Without More Meetings URL: https://www.changebot.ai/blog/high-velocity-pmm-without-more-meetings/ Description: How product marketing can stay ahead of rapid engineering output without living in standups, Slack threads, or demo day. Last updated: 2025-11-25 Best Practices # High-Velocity PMM Without More Meetings [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder November 25, 2025 4 min read ![Product marketer watching a fast-moving launch train while sipping coffee](/_astro/featured.B6sNec3O_1cmXJt.webp) Product Marketing (or “PMM”) used to mean “write the launch brief and show up on release day.” In 2025, without the right processes your sprints will feel more like rolling a boulder up a hill. Features land daily, flags flip quietly, and the team expects you to tell a coherent story _without_ adding more meetings. A VP of Product Marketing described the modern PMM dilemma perfectly: > We can’t be in every sprint meeting. We find out after the fact, then we’re chasing releases across Slack and the changelog to decide what’s newsletter-worthy. PM leaders feel the same pain, in a recent call a VP of Product echoed that sentiment: > We’ve got 15 repos, one PM, and weekly updates that still miss details. We need a single view of what actually shipped. Here’s a practical playbook to stay ahead of high-velocity engineering _without_ adding process overhead. ## 1) Make “discovery” continuous, not meeting-based **Problem:** The only consistent signal comes from sprint demos and ad-hoc Slack posts. PMMs arrive late to the narrative. **Move:** Subscribe to ground truth (code, PRs, and deployments) instead of just Jira/Linear tickets. Use it to auto-surface “key updates” by customer impact (not every commit). - Track staging _and_ production so you see what’s coming before GA. - Bias for high-velocity areas where you’ll need ongoing storylines, not just one big launch. **Result:** You replace “Can someone update me?” with a self-serve feed of what’s actually shipping. ## 2) Filter by readiness: shipped, beta, in-flight **Problem:** Feature-flagged/partial rollouts get mis-labeled as GA, creating retractions and trust debt. **Move:** Label work by environment and flag state. Build three buckets: - **In-flight** (staging/flagged): for PMM planning and enablement. - **Beta**: for selective customer comms and CSM call prep. - **GA/Production**: for newsletters, changelog, and PR. **Result:** You can brief sales/CS early without promising what isn’t live. ## 3) Create two default cadences: weekly recap + surgical spotlights **Problem:** Monthly mega-updates either ship late or become a wall of text no one reads. **Move:** - **Weekly (or biweekly) recap:** Auto-generate from key updates; classify into new features, improvements, fixes, performance. - **Spotlights:** One-page deep dives on a single change that matters (e.g., “Slack destination now supports investor-mode brevity” or “New feature includes sharing update”). Start internal-first. Once you dial in the tone, reuse the same artifacts externally. **Result:** You always have something shippable for internal awareness _and_ a ready-made template for customer-facing noise. ## 4) Finding the right voice **Problem:** AI drafts can feel like end-user marketing when you just need internal clarity, or they’re too technical for non-eng audiences. **Move:** - Feed past PMM copy as tone examples. - Edit-and-save inside your tool so the system learns your style (concise? playful? benefit-first?). - Add a 1–2 line summary to every item for quick scanning; reserve detail for the spotlight body. **Result:** Drafts get closer to “publish” than “rewrite,” shrinking edit time below writing from scratch. ## 5) Route by audience and channel automatically **Problem:** PMMs chase release details scattered across Slack, changelogs, and wikis. **Move:** - Define destinations per audience: - **Internal:** Slack #releases, product ops, leadership digests. - **Customers/partners:** Public changelog, blog/CMS, in-app “What’s New.” - **Investors/board:** 5-bullet “credit for the code” view. - Allow republish-with-edits so fixes propagate to every channel without manual cleanup. **Result:** Everyone gets the right level of detail in the channels they already use. ## 6) Respect B2C cadence and support reality **Problem:** Consumer apps can’t spam millions of users, yet support needs to know what changed _today_. **Move:** - Maintain a full, internal “proof of work” trail. - Throttle external pushes (weekly/monthly) while piping every fix to support/CS in Slack/CRM. - Map fixes to ticket themes so agents can triage faster. **Result:** Users aren’t spammed; support stops getting blindsided. ## 7) For multi-repo portfolios, aggregate first, curate second **Problem:** PMs with 10–20 repos waste hours reconciling what landed where. **Move:** - Aggregate all repos into one recap; auto-tag by product/surface. - Let PMM pick the 10% that’s customer-facing and push those to the external feed. **Result:** Leadership gets a single view; PMM spends time curating, not collecting. ## Bringing it together (and how Changebot helps) You don’t need another standing meeting. You need: - Continuous discovery from code/PRs/deploys (not just tickets). - Readiness labels (staging/beta/GA). - Two cadences: weekly recap + spotlights. - Voice-tuned drafts that are faster to edit than to write. - Automatic routing to the right audiences and channels. - Cadence control for B2C and support coordination. - Cross-repo aggregation with product tags. Changebot handles exactly this. It reads code, tracks staging vs prod, writes recaps and spotlights, learns your tone from edits, and publishes approved updates to Slack, changelog, blog, and investor briefs. Engineers don’t have to change their workflow at all. [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # How Cringe Should Customer Updates Be? URL: https://www.changebot.ai/blog/how-cringe-should-customer-updates-be/ Description: Finding the right balance between boring corporate speak and over-the-top enthusiasm in your customer updates. Last updated: 2024-06-03 Best Practices # How Cringe Should Customer Updates Be? [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder June 3, 2024 4 min read ![Here's how Github uses their developers to write better changelogs](/_astro/featured.CJmKqClh_Z2cxQmf.webp) Here’s a question teams don’t ask before publishing updates: how cringe should it be? When we started working on Changebot back in January we had two problems when dialing in the amount of cringe. First, even though that’s just a few months ago, the number of fast, smart LLM models were way smaller. The second is that we weren’t really sure how to address the problem… so we did a lot of things wrong. The second problem was easy to solve (we simply learned how to do AI correctly), but the first problem around limited models was challenging. Using a “worse” model results in an update’s cringe being through the roof. When we used GPT 3.5, we’d frequently get back updates saying things like: “Dear customers, we hope you’re sitting, because today we announce our revolutionary, groundbreaking new customer interface: featuring links” … when all you’ve done is make links easier to see. As the underlying technology improved, we unconsciously started optimizing Changebot towards a zero cringe future, and at that point realized that the updates were getting worse through becoming lifeless. Paradoxically, optimizing for zero cringe results in bad updates. A completely flat and expressionless transmission of “just the facts” leads to a boring and basically unreadable update. You need a bit of cringe to make the updates sing, I’m excited with the current state of updates through our increased ability to understand what’s changing in the codebase, what the intent of those changes are, and bringing that information to AI models more efficiently to write a bit more like a human. Here’s some examples of an update with different levels of cringe so you can judge for yourself. For background, this is our Changebot generated update for when we released the feature allowing customers to edit their updates in their browser. With not enough cringe, that update looks like this: We’ve updated Changebot. Starting today, you can modify your updates. All changes are tracked, so you know who made the last edit. Let us know what you think. This is short, to the point, and accurate, but this feels less like an announcement and more like a tweet. Also, this feels like it was written by a robot (which it was, but the goal is **not** to sound that way). While this conveys the change literally, there’s no art to it, and it’s not enjoyable to read. Moving on, with too much cringe, the same update looks like this: Hold onto your hats, Changebot users! We’ve got an INCREDIBLE update that will revolutionize the way you interact with Changebot! 🌟✨ This update isn’t just based on your feedback; it’s the culmination of the most groundbreaking evolution in our product’s history! Are you ready for the ride of your life? Buckle up! 🚀🎢 Let’s take a quick trip down memory lane. We started with admin-generated customer updates, then brought you user approvals and the ability to revert approvals. But you wanted more! You craved the power to edit those updates. We heard you loud and clear, and now we’re delivering the most EPIC feature yet! 💪💥 Starting TODAY, you can fully customize suggested updates! YES, you read that right! You’re now the MASTER of your updates. Tweak, edit, and perfect them to your heart’s content! And don’t worry, we’ve got your back—every single change is meticulously tracked, so you’ll always know who made the last edit. 🕵️‍♀️🔍 We couldn’t be more THRILLED to bring you this mind-blowing feature and we can’t wait to see the magic you’ll create with it. This is just the beginning of a new era in customer interaction! 🌠🎉 As always, we’re here, dedicated to crafting the ultimate Changebot experience for you. Dive into these stellar updates and let us know how much you LOVE them! 🌟🚀💖 This generally speaks for itself, but we’ve gone from zero to 13 emoji, all caps words, and there was the unironic use of the word “epic.” How people react to this level of cringe says a lot about their personality. I have to admit that I don’t hate it… but that probably makes sense if you know me. We can, however, say that we’re doing so much in addition to providing the facts that it might be difficult to discern what the update is, thereby defeating the purpose. Here, in our opinion, is the update with just the right amount of cringe as to be engaging, but without going over the top: We’ve got an awesome update for you that makes your interaction with Changebot even more collaborative. This release is based on your feedback and the evolution of our product since the initial creation of customer updates. Let’s dive in! 🎉 First, a quick look back. We started out with admin-generated customer updates, later introduced user approvals and reversion of approvals. You told us that you loved the ability to approve updates but also wanted the power to edit them. We listened and now we’re delivering on it! 💪 Starting from today, you can make changes to the suggested updates! Yes, you heard it right. You’re now in the driver’s seat. Go ahead, tweak those updates until they’re just right for your audience. And don’t worry, we’re keeping track of all changes, so you’ll always know who made the last edit. 🕵️♀️ We’re thrilled to bring you these updates and can’t wait to see what you do with them. As always, we’re here, ready to create a better Changebot experience with you. Enjoy the latest changes and let us know what you think! 🌟 We’re a bit engaging, we reference how this feature came to be from a historical perspective, we’re specific about what’s changing, and we’re back down to a more sober 5 emoji. What do you think? Does this help tune your cringe senses? Want to write updates differently now? [← Back to Blog](/blog) # How GitHub Squeezes The Juice From Their Updates URL: https://www.changebot.ai/blog/how-github-squeezes-the-juice-from-their-updates/ Description: GitHub publishes 29 updates per month—here's how they squeeze maximum value from their changelog with relentless consistency and smart distribution. Last updated: 2025-03-07 Best Practices # How GitHub Squeezes The Juice From Their Updates [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder March 7, 2025 4 min read ![How GitHub Squeezes The Juice From Their Updates](/_astro/featured.DhPnM86N_Mlc23.webp) Do you ever wonder how GitHub squeezes the most value out of their team to provide amazing product updates? I was curious, so I analyzed their 2,381 (!!) updates to uncover where precisely the value lies and how they extract it. [Play](https://youtube.com/watch?v=avRO8Mp7gGE) Here are three things GitHub does with their changelog that you should steal: ## Squeeze One: Relentless Updates GitHub squeezes every single product change for changelog marketing benefit. They are cooking and have published over 2,300 updates since April 2018—nearly 29 updates PER MONTH. 🤯 Here’s a bit of data for your viewing pleasure: ![GitHub Changelog Data Analysis](/_astro/changelog-data-analysis.D3kc9Bl8_tB22B.webp) Aside from the pure volume, the longest gap between updates is just 15 days, and every month receives equal attention. They’re also shipping more updates over time, growing from an impressive 40-60 updates per quarter to an unbelievable 120-160 updates every quarter. They publish so frequently that there was even an update published during my analysis—I went in with 2,380 updates and came out with 2,381. Their team stays focused on improving the product for customers, and they’re not shy about getting credit for that work. One additional note: GitHub’s changelog is separate from their marketing blog. While it’s not necessary to have a separate changelog, I love that they committed from the start to updating their changelog so frequently that it’s become a stand-alone product and marketing asset. ## Squeeze Two: Team Generated Quotes I’ve said before that including customer quotes is an S-tier changelog technique to both communicate value and sprinkle in social proof, all in one move. The downside of this expert maneuver is that you need to coordinate with a third party to get updates out the door. While I have tips on making that process faster, GitHub skips it entirely with a genius realization: Our customers are developers, our developers are developers… why not have our developers talk about the great things our product is doing? Here’s a great example of a quote directly from one of their Principal Solutions Engineers: ![GitHub changelog entry featuring a quote from David Losert, Principal Solutions Engineer, describing how GitHub Copilot Chat helps with seamless translation between programming languages](/_astro/github-developer-quote.BKma_wfJ_Z2bbn2O.webp) To be clear, this isn’t “free”—I imagine a Principal Solutions Engineer has a full work schedule at GitHub! However, the company clearly understands the value of making the changelog as informative and clear as possible, so they treat this as an investment that will yield ROI. ## Squeeze Three: Planning The Next Step GitHub looks for every opportunity to guide their changelog readers further down the funnel, adding numerous outbound links in their posts. Like this: ![GitHub changelog entry about GitHub Copilot VS Code extension with multiple outbound links to documentation, settings, and Copilot Edits feature](/_astro/github-vision-agent-mode-links.np_6TDjI_ZtQSA6.webp) Or this: ![GitHub changelog entry about viewing and iterating on generated files in Copilot Chat with links to documentation, community feedback, and interactive examples](/_astro/github-view-and-iterate-links.C8F0D2L6_ifHDd.webp) Or even this: ![GitHub changelog entry announcing OpenAI o3-mini model availability in GitHub Copilot Free with links to Copilot Free, GitHub, VSCode, and documentation](/_astro/github-o3-mini-links.Cle18Bhm_1Hzzro.webp) This shows that GitHub understands their changelog content interests everyone: existing customers, past customers, and potential future customers. Given this wide and relatively engaged audience reading these product-specific updates, how do we maximize the benefit of that interaction? GitHub’s approach is to move readers to the next step in their funnel, whether that’s trying a new feature, reviewing detailed documentation, or finding the direct location to upgrade their account. ## Small Recommendations If GitHub’s product marketing team hired me to further improve their changelog, I’d point out that there’s room to be more specific about the benefits to end users. I understand their audience is mostly developers, who are generally pretty anti-“getting sold to,” but let’s look at the changelog entry that provided the team quote. Further down the post, there’s this section on the functionality being provided in the new GitHub Copilot Chat feature: > Powered by GPT-4, GitHub Copilot Chat is a contextually-aware AI assistant designed specifically for developer scenarios. Teams of developers and individuals alike can prompt Copilot Chat in the natural language of their choice–from German to Portuguese and beyond–and receive real-time guidance without ever leaving the IDE. From explaining complex coding concepts to detecting security vulnerabilities and writing unit tests, Copilot Chat can help every developer innovate at the speed of thought. To ascend to the elite level of changelog writing, your customers shouldn’t have to wonder, “What was the point of building this? How does this make our business stronger? Why are we here?” My rewrite would focus on making developers faster and more productive with fewer bugs, which gives us endless choices on what to promote. For an optimistic spin, how about: > Powered by GPT-4, GitHub Copilot Chat is a contextually-aware AI assistant designed specifically to both improve the speed and quality of the code you’re writing. Whether it’s shipping roadmap features without breaking a sweat, or solving a critical customer bug without skipping the tests, GitHub copilot chat keeps your team happy, which in turn keeps your customers happy. From explaining complex coding concepts to detecting security vulnerabilities and writing unit tests, Copilot Chat can help every developer innovate at the speed of thought. Focusing on the outcomes that make your customers money is always a great idea, but is especially true when you ship to the crazy standard that GitHub does. Connecting to your customers bottom line is the best way to make sure your updates aren’t just noise. * * * Want to update your changelog as frequently as GitHub does, but that seems like a lot of work? We can do the hard work for you by analyzing the changes you’re making, flagging the ones that create customer value, and writing the first draft for you. We’ll even help make sure that your customers and prospects see the updates too! [← Back to Blog](/blog) # How Linear uses its changelog to announce product updates URL: https://www.changebot.ai/blog/how-linear-uses-product-updates-to-create-yell-from-the-rooftop-fans/ Description: I analyzed 192 Linear changelog entries. They stay public, ship about 3 times a month, and explain the why. Here's what to copy. Last updated: 2025-03-07 Best Practices # How Linear uses its changelog to announce product updates [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder March 7, 2025 4 min read ![How Linear uses product updates to create yell-from-the-rooftop fans](/_astro/featured.vTn5qUMc_g0iEK.webp) Obsessed with Linear? We are too. I analyzed all of their 192 changelog entries to figure how this ‘boring’ tool became everyone’s favorite product. Here’s three ways Linear uses customer updates to create lifetime advocates. [Play](https://youtube.com/watch?v=Ppc5ZCvf71k) ## Public by Default Linear’s changelog is accessible to everyone (not just customers). The company knows how polished and professional their changelog is, so they let the updates speak for themselves — going as far as making their changelog one of the primary links on their marketing site: ![Linear’s changelog promoted front and center.](/_astro/linear-changelog-screenshot.B0HAXQ2W_1QW060.webp) Most companies only share updates with existing customers, but potential customers also want to see that the team is hard at work! There’s also the second order effects: if your team knows that the updates will be public, you naturally put more love and care into the updates, and you make sure that the updates can stand on their own. Sending a message to a customer who has been subscribed for five years allows for all sorts of shortcuts and shared language, but if the update might be read with someone brand new to your product you’ll naturally explain the updates (and the reason for that update) from the ground up. ## Consistently Frequent Linear has published (a whopping) 192 updates since April 11th, 2019, averaging 2.8 updates a month. They’ve kept up this pace for the entire life of the company, with the vast majority of their updates having 4-7 days in-between, followed by 8-14 days. When I analyzed their updates I only counted **two** 30 day gaps between, which is wild. Most companies changelogs have 30 day gaps between every single update! Here’s the results from my analysis for your viewing pleasure: ![Linear customer update analysis](/_astro/linear-update-frequency-chart.oLR4sac-_1bAWT2.webp) ## Tell the Story Most companies do a great job of explaining the “what” when they send an update to customers, but Linear also does a great job explaining the “why”, and they do this through story telling. Let’s use this update, simply titled “ [Customer Requests](https://linear.app/changelog/2024-12-09-customer-requests)” as an example. ![Linear’s Customer Requests update](/_astro/customer-requests-update.B_RxsQzc_1QQGHo.webp) They use story telling to explain how customer feedback is often scattered across support tickets, Slack messages, and calls – outside the product team’s workflow and sometimes entirely out of reach. This creates a disconnect between what gets built and what customers actually want. Instantly this framing helps us understand the headspace their product team was in designing this feature, and some of the direct pain points they’re looking to solve. This could easily have been “New feature, customer requests, click here to add one!” but they walked us through the process step by step. ## Gentle Recommendations If I had to provide constructive feedback to the customer update GOATs, I would pretend to struggle for a moment and then respond with two things: 1. Directly connect updates to the bottom line, and 2. Get credit for the “heartbeat.” ### Directly Connect Updates to the Bottom Line Lets use the following update as an example, [Slack Channel Notifications for Custom Views:](https://linear.app/changelog/2024-08-23-slack-channel-notifications-for-custom-views) ![Linear’s update for notifications around custom views.](/_astro/slack-notifications-update.DODD3f8Y_Z1LKpjV.webp) They stick to their great story telling by explaining the situations that happen in a business where they might want to get notifications on custom views, but what’s the business purpose? How do these views make me more money? Does it prevent a product development bottleneck so our biggest customers don’t churn due to a forgotten bug? Or does this help us ship fasters to keep ahead of our competitors, bringing in new customers? It might seem obvious to you, but most of our (lovely) customers and prospects are skimming, you can make it clear how you’re hard at work making their business stronger without needing to go over the top trying to “sell” the benefits of the update. ### Get Credit for the “Heartbeat” Karri Saarinen, Linear’s CEO, shared an update on Twitter with a jaw-dropping stat: 95% of reported bugs get fixed within 5 days. ![5 days!!](/_astro/karri-twitter-bugs.CpYs76OO_stAUd.webp) If you’ve operated a tech company at any level of scale it’s hard to imagine winning on all fronts in the way Linear does, both launching new, large, impactful features while also quickly resolving bugs as they’re reported. I shared earlier that Linear shared ~2 updates per month with the large improvements they’re making. This is awesome, but doesn’t share the day to day blocking and tackling they’re doing to ensure the quality of the features they’ve already launched remains high. What if there was a place where they could showcase those bug resolutions? I’d bet there’d be hundreds of entries a month on top of the new large feature that would further show how far Linear is ahead of their competition. ## In Conclusion If you’ve read this far I’ll bet you want to get more value out of the product improvements you’re already hard at work making. Here’s a recommendation on how to get more out of your changelog: check out my 92 page book called the [Art of the Update](https://www.changebot.ai/blog/the-art-of-the-update), available completely for free, no email required, right here on the blog. [← Back to Blog](/blog) # How to Publish a Changelog From GitHub URL: https://www.changebot.ai/blog/how-to-publish-a-changelog-from-github/ Description: Four ways to turn GitHub history into a published changelog — GitHub Releases, a CHANGELOG.md file, a generator in CI, or an agent that drafts entries — and how to pick between them. Last updated: 2026-09-18 Best Practices # How to Publish a Changelog From GitHub [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder September 18, 2026 5 min read ![A robot inspecting commit cards on a conveyor belt that delivers a published changelog page and a chat message](/_astro/featured.DWLM-wiQ_Zs6icl.webp) In short To publish a changelog from GitHub, pick where the source of truth lives: GitHub Releases, a CHANGELOG.md in the repository, a generator running in CI, or an agent that reads your commit and pull request history and drafts customer-facing entries for review. Only the last one produces updates a non-technical reader can use. Your GitHub history already contains everything a changelog needs. The problem is that it contains it in the wrong language, at the wrong grain, mixed with hundreds of changes no customer will ever notice. There are four common ways to close that gap. They are not equally good, and the right answer depends almost entirely on who reads the result. ## Option 1: GitHub Releases Tag a release, write notes, publish. GitHub will even generate a first draft from merged pull request titles. **Good for:** open source projects, developer tools, CLIs, libraries — anywhere the audience is already on GitHub and comfortable reading pull request titles. **Bad for:** commercial products with non-technical customers. The notes live on github.com rather than your domain, which means they don’t build your search presence, they aren’t styled like your product, and your customers will never think to look there. ## Option 2: A CHANGELOG.md in the repository The convention documented by [Keep a Changelog](https://keepachangelog.com/): one Markdown file, Added / Changed / Fixed / Deprecated headings, updated as part of the pull request that makes the change. **Good for:** keeping the changelog honest. Writing the entry while the change is fresh, in the same pull request, is the single most reliable way to stop entries from being reconstructed later from memory. It also gives you a real review flow — comments on a text diff instead of [screenshots of drafts pasted into tickets](/blog/sharing-screenshots-of-your-changelog-drafts-is-a-red-flag/), which is what review becomes in tools where a draft is only visible to its author. **Bad for:** reaching anyone outside the repository. A file in a repo is not a published changelog. Most teams that stop here eventually build a page that renders the file, at which point they discover that entries written for a repository don’t read well as customer communication. ## Option 3: A generator in CI Tools like `git-cliff`, `release-please`, or `standard-version` parse conventional commit messages and produce a changelog on every release. Wire one into a GitHub Action and the file updates itself. **Good for:** versioned software with disciplined commit conventions. It is accurate, it is free, and it never forgets. **Bad for:** anything a customer reads. The output is your commit messages, reorganized. `fix(sync): handle null cursor on paginated fetch` becomes a bullet point, and the customer who lost their comments last Tuesday still has no idea that this is the line that says it’s fixed. Generation solves recall. It doesn’t solve translation. ## Option 4: An agent that drafts from history Connect the repository to an agent that reads commits and pull requests, groups related work, decides what is customer-visible, and writes each entry in plain language for a human to approve. This is not the commit-dump-into-a-chatbot experiment, which fails the same way for everyone who tries it: the model weights whatever produced the most pull requests, so the Python 2-to-3 migration becomes the headline while the fix customers actually noticed gets a bullet — all delivered in a tone of enthusiasm nobody believes. A product lead at an observability company told us exactly that story: the migration ran through months of their internal notes and, correctly, never earned a word in their public changelog. An agent has to [score customer impact, not activity](/blog/ai-cant-tell-your-biggest-feature-from-a-dependency-update/), and that takes context about the product and who uses it. This is what [the Changebot Agent](/product/agent/) does. It connects to GitHub or Bitbucket, reads your history, and drafts updates in your categories and voice. You edit, you approve, and it publishes. **Good for:** products with customers who are not developers, teams shipping faster than anyone can write, and anyone whose changelog is currently three weeks behind. **The tradeoff:** a draft is a draft. The agent decides what looks customer-facing, and sometimes it will include something you consider internal or miss context that never made it into a commit message. Review is part of the workflow rather than a formality, which is why publishing stays behind human approval. ## Publishing the result Wherever the entry comes from, it still needs somewhere to land — and this is where the third system creeps in. Plenty of teams run an app repo, a marketing-site repo, and a changelog tool that talks to neither, which guarantees the changelog is the surface that goes quiet. A changelog that reaches people usually has four: 1. **A public page on your own domain.** Crawlable, dated, and yours — so it accumulates search and AI-assistant visibility instead of donating it to github.com. 2. **An in-app widget.** The people most likely to care are already using the product. A [changelog widget](/glossary/changelog-widget/) puts the update in front of them without an email. 3. **A feed.** RSS or Atom, so power users and internal tools can subscribe. 4. **Slack or Discord.** Both for customers in a shared channel and for your own support and sales teams, who need to know what changed before a customer asks them. With Changebot, that whole publishing layer is free — hosted page, widget, custom domain, Slack, Discord, RSS, and [MCP](/glossary/mcp/). The [$99 per repository per month](/pricing/) covers the agent that writes the drafts. ## A workflow that holds up Ask what a changelog costs and people count the writing — ten, fifteen minutes. The real bill is everything around it: working out what actually shipped, and copying the result into every place it needs to appear. That’s [the fifteen-minute illusion](/blog/the-fifteen-minute-illusion/), and it’s the part a workflow has to remove. The version that survives contact with a busy sprint looks like this: 1. Ship normally. No new commit conventions, no changelog file to maintain by hand. 2. Once a week, have the agent draft the update from that week’s merged work. 3. Spend ten minutes editing: cut the internal items, fix the one entry that describes the implementation instead of the effect, add a screenshot to anything visual. 4. Approve, and let it publish to the page, the widget, the feed, and Slack at once. The failure mode this avoids is the one every team knows: nobody publishes, because publishing starts with a blank page and a week of commits nobody wants to reread. ## Related reading - [Release notes template: four formats you can copy](/blog/release-notes-template/) - [Changelog examples: five formats and what makes them work](/blog/changelog-examples/) - [Your commit messages were never meant for customers](/blog/your-commit-messages-were-never-meant-for-customers/) ## Frequently Asked Questions Can you generate a changelog from git commits? Yes, and tools like git-cliff or release-please will do it from conventional commit messages. The output is accurate but written in engineering language, so it works for developers reading a repository and not for customers reading a product update. Should you use GitHub Releases as your changelog? GitHub Releases works well for open source and developer tools, where the audience already lives on GitHub. For a commercial product with non-technical customers it is the wrong surface: it is not on your domain, not styled like your product, and not somewhere customers think to look. How do you publish a changelog automatically when you merge a pull request? Trigger on the merge event, either with a GitHub Action that appends to a file and commits it, or with an agent or API call that creates a draft entry. Keep a human approval step before anything customer-facing goes live; fully automatic publishing turns merge noise into customer noise. Do conventional commits make changelogs better? They make generation reliable, which is not the same as making the changelog good. Conventional commits give you clean grouping and versioning; they do not turn 'fix(sync): handle null cursor' into a sentence a customer understands. ## Table of Contents - [Option 1: GitHub Releases](#option-1-github-releases) - [Option 2: A CHANGELOG.md in the repository](#option-2-a-changelogmd-in-the-repository) - [Option 3: A generator in CI](#option-3-a-generator-in-ci) - [Option 4: An agent that drafts from history](#option-4-an-agent-that-drafts-from-history) - [Publishing the result](#publishing-the-result) - [A workflow that holds up](#a-workflow-that-holds-up) - [Related reading](#related-reading) Stop writing the changelog by hand The Changebot Agent drafts customer-ready updates from your GitHub history. Publishing is free. [Get Started for Free →](https://app.changebot.ai/signup) [← Back to Blog](/blog) # How to Update Your Changelog Before a Price Increase URL: https://www.changebot.ai/blog/how-to-update-your-changelog-before-a-price-increase/ Description: Raising prices with an empty changelog is asking for churn—here's how to avoid that mistake. Last updated: 2024-08-19 Best Practices # How to Update Your Changelog Before a Price Increase [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder August 19, 2024 6 min read ![How to Update Your Changelog Before a Price Increase](/_astro/featured.Cw1e1wEe_ZgXGKw.webp) When increasing your price it’s natural for customers to ask the question “What additional value am I getting for the price?” Companies tend to address this with a well worded announcement email which covers: - key improvements made since the previous price was established, - key goals that the company looks to achieve, and if it’s relevant - meaningful increases in expense. While the announcement message MUST be well thought out, a majority of customers will want to see these improvements for themselves. The best case scenario is them getting to scroll through a long list of new features, fixes, and improvements since the day they agreed to pay the original price. ## I’ve learned this lesson the hard way The last time I announced a price increase sent customers flying to our changelog, which just so happened to have a four month gap. The price increase announcement email was sent April first (yes, seriously) and the newest update was posted January 10th. Clearly there were a large number of mistakes here, but the most painful part was that in reality we had deployed several dozen features, updates, and fixes since January 10th—this was the fastest development velocity that we had ever had as a team. However, we skipped the step where we decided to tell our customers and get credit. It’s possible to dig yourself out of this hole by explaining all the recent improvements, why put yourself in that position in the first place? ## The Three Paths I’m assuming you’re reading this article because you’re both planning a price increase and aren’t already updating a public list of product improvements. Moving forward you have three paths in front of you: - Path 1: launch the price increase with a barren changelog and incur the wrath (and churn) of angry customers (hereinafter referred to as “the dumb way.”) - Path 2: push back the price increase to give yourself time to write, review, edit, and publish dozens of changelog entries (hereinafter referred to as “the hard way.”) - Path 3: use a tool to automatically generate well written updates which populates your changelog, allowing you to stay on schedule and minimize churn (hereinafter referred to as “the smart way.”) ## The Dumb Way There aren’t many positive aspects to this approach. If forced, I’d point out that being dumb takes no additional time or effort: you will keep on schedule and not need to change your price increase launch plan. The negative aspects of the dumb way are numerous, voluminous, and ominous (pronounced “oo-MAN-ouse” to maintain rhyme scheme.) The two most obvious downsides are that: 1. Your customers will be (rightly) frustrated with you because they feel like they’ve entered into a bait and switch arrangement, and 2. Frustrated customers churn. It can be challenging to maintain perspective in a price increase, however take a moment to consider what your customers see. The customer is (hopefully) happily using the product, despite thinking that there aren’t many updates being made, then, out of the blue, they get an email about “how hard you’re working” and that they need to pay 2-3 times more for “the same” product! This is taking the continuous, low grade mistake of not updating your customers on improvements and layering on the high grade, acute mistake of asking them for way more money! To close, if you’re set on taking the dumb way: the most I can say is that you will not literally perish (despite what it feels like) and you have entered into a great learning experience that you’ll reflect on for years. ## The Hard Way The hard way is hard because if you already had a great process for getting updates in the hands of your customers and the public you’d already have a great changelog. In addition, it’s much easier to write about new improvements as they happen. The further you are from a specific change, especially a small fix, the further your team is from the context around that improvement. It’s trivial to talk about the motivation behind a small bug fix the day it’s launched, you probably still have the email in your support inbox where the customer requested the fix. Months or years later? Good luck. It’s like the Blade said in the movie Blade: some of my friends are always trying to ice skate uphill. If you’re truly committed to this approach, I have the following pieces of advice: ### Demonstrate Consistency One of the benefits in consistently updating your changelog is demonstrating consistency to your customers. Given that, if you were limited to writing just 10 updates, instead of doing 10 updates from last month, I’d do 2 updates for each of the past 5 months. One update a week for the last two years would be ideal, but since you’re doing things the hard way I imagine you’ll tap out before 100 updates. ### Tomes Not Required Each update doesn’t need to be a 12 page essay—some customers appreciate updates that have no “fluff” and simply outline the improvement they’re getting access to. (I’m personally a fan and champion of fluff, but I digress.) Since we’re on hard mode you may have to settle for 2-3 line updates. This is fine, but make sure the update at least hits which benefits the customer is getting. A potential template would be: 1. A line describing what changed (e.g., “We’ve launched a new feature that allows you to publish updates hosted by us.”) 2. A line describing the benefits to the customer (e.g., “This saves you time by not needing to publish on a third party CMS, allowing you to spend time on each update.”) 3. A line describing why the customer is better from the benefits (e.g., “This means more updates, which means happier and higher retention customers and easier to close customers in the top of funnel.”) ### Make it a Team Sport Everyone has something to add, and let’s be honest: you don’t have the time to get this done on schedule with only one person working on it. Brainstorm a list of the updates you want to publicize, assign an owner, and let it rip. ## The Smart Way Ah, so you’ve chosen the smart way: you are a true connoisseur of the entrepreneurial arts. Here’s where our story takes a twist—we’ve talked about the importance of product updates in a price increase, and we’ve discussed how to write all these updates manually… but you are not going to believe this coincidence. Not only am I aware of a product that will write product updates for you automatically. Not only will that product write those updates lovingly, considering the entire context of your business. Not only will that product host those updates for you, or publish them to a blog of your choice. Not only will that product also write updates for changes earlier in history to backfill your product updates. **But you are on the blog of that very product.** 1.1 billion websites exist on the internet, and the blog with this article is the same product that solves the problem. They say it’s good to be good, but it’s better to be lucky. Here’s what you can do to solve this customer updates problem now, in the past, and forever into the future: 1. Sign up for a Changebot account. 2. Connect your Github account 3. Changebot will start working to understand your company, product, features, benefits, and customers, then write a handful of updates for you to review. 4. You can review, edit, approve, and publish those updates and you’re already much closer to having a rich source of product updates to share with your customers. 5. After upgrading to a paid plan you can specify how far into the past you want to generate updates for. Changebot jumps in, does the heavy lifting, and you move forward with your price increase backed by solid proof of everything your team’s getting done. Even better, you’ll use Changebot to keep customers updated at least once a week, so you’re never left scrambling or going quiet when customers expect improvements. [← Back to Blog](/blog) # I created this process and now it's eating me alive URL: https://www.changebot.ai/blog/i-created-this-process-and-now-its-eating-me-alive/ Description: You championed release notes when nobody else would. Now you're the permanent owner. Here's why the 'person who cares' always gets stuck. Last updated: 2026-03-09 Best Practices # I created this process and now it's eating me alive [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder March 9, 2026 3 min read ![Illustration of a person tangled in vines growing from a process flowchart they originally created](/_astro/featured.B82ojyQQ_ZOls7D.webp) A VP of Product told us something on a call that made me wince. “I did this to myself. When I started they didn’t even do release notes. And I, foolishly, said OF COURSE we should have release notes, our customers need to know!” And she was right, they should of course have release notes. The problem is that years later, she’s still the one writing them! Internal and external release notes at least every two weeks for five different audiences… delivered by a team of two and a half people. ## The ownership trap This happens in product organizations everywhere. Someone sees a gap, communication is bad, customers don’t know what shipped, and support gets blindsided every release. The most capable, most customer-focused person on the team raises their hand and says “we should fix this.” They build a process. And the good news is that it works! The bad news is that people start depending on it, then the person who created it becomes permanently responsible for it. Simply because they’re the one who knows how to do it, they care enough to do it well, and nobody else has volunteered to take it over. ## Why it’s always the same person The people who notice communication gaps tend to be the same people who understand both the technical and customer side of the product. They can read a Jira ticket and translate it into something a support rep can use. They know which bug fixes matter to customers and which ones are internal cleanup. That combination of skills is rare. It’s also exactly why these people shouldn’t be spending their time on repetitive translation work. They should be talking to customers, shaping product direction, and doing the strategic work that requires their unique perspective. Instead, they’re going through Jira one by one, rewriting the same information for internal teams, support, customers, marketing, and leadership. Every two weeks. Because the process depends on them. ## The guilt feedback loop Here’s what makes this especially hard to escape. The person who created the process feels responsible for it, so if they stop, communication breaks down. Support gets blindsided, customers don’t hear about fixes, and leadership asks what happened. They keep doing it. Even as the team ships faster. Even as the release cadence tightens. Even as AI coding tools make engineering output 10x while the communication side stays manual. The VP we spoke with said it plainly: “We want to do more, but we can’t get to it because we’re stretched so thin.” It’s not a matter of being inefficient, it’s because they’re doing their work, plus the addition work of a system that should exist (but doesn’t.) ## The process outgrows the person The thing about championing good process is that when it works, it creates demand. Once support gets used to receiving release notes, they expect them. Once leadership gets their weekly summary, they depend on it. Once customers see updates in the help hub, the absence becomes conspicuous. Each audience that starts receiving communication becomes a stakeholder who expects it to continue. The person who started with “we should have release notes” now has five audiences waiting for translated updates every two weeks. This is a systems failure, not a personal one. The person identified a real need and filled it with manual effort. That was the right first step. The missing second step is recognizing when a manual process needs to become infrastructure. ## When to stop being the system If you’re the person who created the release communication process at your company, and you’re still the one running it months or years later, you’re not a writer. You’re a system. The question isn’t whether the process should exist. It should. You were right about that. The question is whether a human should be the execution layer. The signs are clear: the process takes the same time every cycle, the inputs are predictable (tickets, PRs, release scope), and the outputs follow a pattern (internal notes, support context, customer-facing language, marketing angles, leadership summary). That’s a system. It should run like one. You did the hard part. You proved the value. Now let something else do the repetitive work so you can get back to the strategic work that only you can do. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # "I Had No Idea This Exists": The Feature Awareness Problem URL: https://www.changebot.ai/blog/i-had-no-idea-this-exists/ Description: Your team shipped the feature. You announced it. And customers still don't know it exists. Here's why the gap between shipping and awareness is bigger than you think. Last updated: 2026-01-15 Best Practices # "I Had No Idea This Exists": The Feature Awareness Problem [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder January 15, 2026 4 min read ![Illustration showing a communication gap between a product team shipping features and customers unaware of them, with a changelog bridge spanning the gap](/_astro/featured.Zcxg6EH4_Z18mJ15.webp) A Product Marketing Manager told me something that stuck with me. She was describing customer conversations about new features – features her team had launched, announced, and that had been live for months. The response from customers? “I had no idea this thing exists.” This happens constantly. And it’s one of the most demoralizing experiences in product work. ## The gap between shipping and knowing Your team worked for weeks on a feature. Engineering built it, product defined it, and you launched it. Maybe you sent an email. Maybe you posted in Slack. Maybe you updated the changelog. And somehow, when a customer needs exactly that feature, they don’t know you have it. They complain about the missing functionality, consider switching to a competitor, and eventually churn. Then someone mentions, “Actually, we shipped that three months ago.” The worst version: customers churn because they wanted a feature you already have. I’ve lived this. At a previous company, we’d get cancellation reasons like “I’m switching to Competitor X because they have Feature Y.” And we’d look at each other and say, “We have Feature Y. We’ve had it for six months.” Damn it. ## Why announcements don’t stick The math works against you. A typical SaaS product might have thousands of users. When you send an announcement email: - Maybe 30% open it - Maybe 10% click through - Maybe 5% actually read and remember the information - The other 95% have no idea what you shipped Now multiply this by the dozens of features and improvements you ship each year. Customers receive a fraction of your communications and remember a fraction of that fraction. A VP of Product at a creator commerce platform put it bluntly: “Engineering does way more than anyone knows about. The new features are just the tip of it.” The work is happening. The communication isn’t landing. ## The ephemeral launch problem There’s another dimension to this problem: launches are events, but awareness needs to be continuous. A Sr. Product Marketing Manager described it perfectly: “Launches are ephemeral. They happen, they finish, and all that content disappears.” You create a landing page for the launch, send the announcement email, and post on social media. The launch week ends, and a month later a new customer signs up who never saw any of it. That customer has no way to discover what you shipped unless they happen to find your changelog (if you have one) or stumble across a help article. The launch content has vanished into the archive. Meanwhile, your competitor’s changelog shows active development. Your most recent update was three months ago. Which company looks more alive? ## The internal echo of the external gap When customers don’t know what shipped, internal teams often don’t know either. A VP of Engineering told me his company created a separate Slack channel just for “small stuff that support doesn’t know about.” Because support kept getting questions about features they’d never heard of. At a fintech company, the CEO described how support teams discover changes “after the fact.” Teams produce updates but nobody consumes them. The communication arc breaks somewhere between engineering and the people who talk to customers. If your own support team doesn’t know what you shipped, how would customers? ## The compound effect Feature awareness isn’t a one-time problem. It compounds. Each feature you ship that customers don’t know about is: - A missed retention opportunity - A missed upsell conversation - A missed competitive differentiation - A missed proof point for your roadmap credibility A product leader at a mid-market software company told me their customer success team now tracks development velocity specifically to show contract value to at-risk accounts. They use their changelog as a retention weapon. They recognized the alternative: customers not knowing what they’d built. The compound effect works both ways. Consistent, discoverable communication builds trust over time. Inconsistent communication erodes it. ## What a steady drumbeat looks like The Sr. Product Marketing Manager who described the “I had no idea” problem also described what she wanted instead: a steady drumbeat of communication. Not just launches. Not just big announcements. A consistent cadence where customers can expect to learn what’s new, even if they missed last month’s update. This requires: **Persistence.** Updates need to live somewhere customers can find them later. A changelog, a release notes page, an in-app feed. Something that doesn’t disappear after launch week. **Consistency.** Monthly, bi-weekly, whatever cadence fits your velocity. The regularity matters as much as the content. Customers learn to expect and check for updates. **Easy to find.** Updates need to be findable from many paths: email, in-app, search, help center. Customers come looking at different times through different doors. **Cumulative evidence.** Over time, the archive of updates becomes proof of momentum. Prospects checking your product can see you’re alive and active. ## Closing the gap The feature awareness gap doesn’t close by trying harder at launches. It closes by building systems that continuously communicate what ships. The teams that don’t have this problem share common traits: they’ve automated the capture of what changes, they publish consistently, and they make updates discoverable long after launch week ends. One product marketer I spoke with said it perfectly: customers checking a competitor’s changelog and seeing regular updates will choose that competitor over one whose last update was months ago. “It doesn’t matter that you shipped more total value. The perception is that they’re more active.” Perception becomes reality when customers make decisions based on what they see. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # Introducing the Changebot Agent URL: https://www.changebot.ai/blog/introducing-the-changebot-agent/ Description: Changebot is becoming the agent-first changelog: write, edit, review, and publish product updates from the workflow you already use. Last updated: 2026-06-13 Updates # Introducing the Changebot Agent [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder June 13, 2026 3 min read ![AI agent icon with empty fuel gauge surrounded by disconnected data sources](/_astro/featured.SIA2wRub_Z8rzpT.webp) For a long time, changelog tools have assumed the same basic workflow: log in, open an editor, write the update, copy it somewhere else, and hope people see it. That workflow is starting to feel backwards. The work already happens in agents, terminals, chat tools, issue trackers, pull requests, and Slack threads. The draft often starts there too. Someone asks Claude to summarize a diff. Linear generates a release note. A product lead writes a rough customer announcement in ChatGPT. A support lead asks what changed last week. Then the update gets stuck. It has to be copied into a changelog tool, reformatted, reviewed, and published manually. The AI workflow helped with the writing, but it did not close the loop. Changebot is becoming the agent-first changelog so that loop can close. ## What the Changebot Agent does The Changebot Agent helps you understand, write, edit, review, and publish product updates from a conversation. Ask for a monthly recap. Ask for a single launch note. Ask for a support-friendly version. Ask for a shorter Slack version. When the update is ready, publish it to your hosted changelog, embeddable widget, Slack, or custom-domain release page. The same context is useful before anything becomes a changelog post. Support can ask what changed in a feature over the past month. Sales can ask what is new for a segment of customers. Leadership can ask for a quick brief on the last week of product work. Changebot answers at the feature and benefit level instead of handing non-technical teams a pile of commits. The agent is not meant to remove human judgment. Customer-facing release communication still needs approval, tone, positioning, and timing. The agent handles the repetitive work around discovery, drafting, rewriting, formatting, and routing. ## Why this matters now AI coding tools made teams ship faster. Release communication did not get the same upgrade. The result is familiar: support asks what shipped, customers miss fixes they were waiting for, marketing rewrites technical notes, and someone promises to update the changelog next week. Next week rarely comes. The agent-first changelog changes the default. Instead of opening a blank editor, you ask for the update you need. Instead of copying between tools, you review and publish from the same workflow. Instead of leaving AI-generated drafts stranded in chat, Changebot turns them into a durable update customers can find. ## Start free, expand when you need context The free version of Changebot lets you publish updates to a hosted changelog, embed a widget on your site, use a custom domain, publish to Slack, and push updates through MCP or the API. If you want Changebot to understand what shipped without you supplying the source material, connect GitHub or Bitbucket through the paid agent plan. That unlocks codebase-aware recaps, daily or weekly updates, and automation for the teams that want the fuller workflow. The point is to match the tool to the amount of effort people actually want to invest. You can start by publishing one update for free. You can grow into $99/repo agent automation when the workflow is ready for Changebot to write from source context. ## The changelog should live where work happens Changebot is not trying to become another destination you have to remember to check. The goal is the opposite: use the agent or AI workflow you already like, and let Changebot handle the changelog publishing layer. Your customers get a real URL. Your product gets a visible record of progress. Your team stops treating release communication like a separate ceremony. [Start free](https://app.changebot.ai/signup), or [choose your workflow](/start). [← Back to Blog](/blog) # Investor Updates From Code URL: https://www.changebot.ai/blog/investor-updates-from-code/ Description: How Changebot turns your shipped code into investor-ready updates that prove progress and build confidence. Last updated: 2025-07-22 Best Practices # Investor Updates From Code [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder July 22, 2025 4 min read ![Five concise bullets emerging from a stream of code updates for investors](/_astro/featured.Cwez3cEd_1CUjj.webp) Investor updates are a funny thing. Every founder commits to sending them. And every founder has, at some point, stared at a blank document wondering what to write… even when the team has been heads-down building for weeks. The problem is translating engineering work into investor language takes time most founders don’t have. Updates slip. They go out late. Or they’re so high-level they don’t actually say anything. Changebot fixes this by generating investor updates directly from your source code. Here’s how it works and why it matters. ## Why source code is the right starting point Most investor updates start with memory. Someone tries to recall what shipped, what mattered, and what’s worth mentioning. That process is slow, incomplete, and biased toward what’s top of mind. Changebot starts with your actual code history. Commits, PRs, merges. The ground truth of what your team built. This matters for a few reasons: **You’re reporting reality.** Investors have seen enough slide decks about the future. What they want is proof that you execute. When your updates draw from shipped code, you’re showcasing tangible accomplishments. **Nothing gets forgotten.** That reliability improvement your backend team shipped? The accessibility fix that took longer than expected? The security patch that prevented a potential issue? It’s all in the code history. Changebot surfaces work that would otherwise go unmentioned. **The timeline is accurate.** No more “I think we shipped that last month?” Your code history knows exactly when things merged and deployed. ## Focus on customer benefits, not technical details Here’s something investors won’t tell you directly: they don’t care about the technical implementation. They care about customer value. “Refactored the authentication flow” means nothing to an investor. “Reduced login failures by 18% on Android” tells them customers are having a better experience and you’re protecting revenue. Changebot automatically translates technical work into customer-benefit language. A database optimization becomes “checkout is now 200ms faster and cart abandonment should drop.” This is a unique feature of how we built Changebot. We don’t just summarize commits. We translate them into the language of customer impact, which happens to be exactly what investors want to hear. ## What investors actually care about When an investor reads your update, they’re looking for signals: **Momentum.** Are you shipping? Is the team productive? Is there forward motion? **Customer value.** Are real users benefiting from the work? Is the product getting better in ways that matter? **Good stewardship.** Is their money going to work? Are you focused on the right things? Technical details don’t answer these questions. Customer outcomes do. That’s why Changebot frames everything around who benefits and how. ## Investor pet peeves (and how to avoid them) Let’s be honest about what frustrates investors: ### Late updates Nothing signals organizational trouble like a late investor update. If you can’t get a monthly email out on time, what else is slipping? The irony is that updates are often late because the team is busy building. All investors see is silence. Changebot generates your update in about 60 seconds. No more “I’ll get to it this weekend” that turns into next week. Set a monthly reminder, run a Recap, make light edits, and send. On time, every time. ### Surface-level updates with no detail “Made good progress on the product” is not an update. Neither is “The team has been busy.” Investors want specifics. What shipped? Who does it help? What’s the impact? Generic updates feel like you’re either hiding something or you don’t know what your own team is doing. Because Changebot pulls from your actual code history, the specifics come free. You’ll mention the exact features that shipped, the customer segments they help, and the measurable improvements where they exist. ### Roadmap without execution Updates that are all forward-looking (“next month we plan to…”) without any backward-looking proof (“last month we shipped…”) raise red flags. Investors want to see execution and delivery. Recaps are inherently backward-looking. They start with what actually merged and deployed, demonstrating execution. You can add a forward look at the end if needed. ## Demonstrating operational excellence Here’s the thing about investor updates: they signal how you run the company. A founder who sends detailed, specific, on-time updates is demonstrating: - **Organization:** You know what your team shipped. - **Communication:** You can translate technical work into business value. - **Discipline:** You follow through on commitments (like monthly updates). - **Transparency:** You’re not hiding behind vague language. These are the same qualities investors want to see in how you run the business. Your update is a proxy for your operational acumen. When you use Changebot to generate investor updates from code, you’re demonstrating that you have systems in place, that you’re tracking real work, and that you’re managing their investment well. ## What this looks like in practice **Without Changebot:** Founder spends 2-3 hours at month end trying to remember what shipped. Asks engineering leads what’s worth mentioning. Writes something generic because there isn’t time for detail. Sends it three days late. **With Changebot:** Founder runs a monthly Recap and reviews the customer-benefit summaries for each shipped item. Picks the top 5-7 updates, adds a brief forward look, and sends on the first of the month. Same team. Same work. Different investor experience. ## The compound effect Twelve months of detailed, on-time investor updates tells a story. Investors can look back and see the arc of your product development. They can see that you shipped consistently. They can see the customer value accumulating. That track record matters when you’re raising your next round. It matters when you need board support for a pivot. It matters when investors are deciding whether to make follow-on investments. Investor updates are an opportunity to build confidence over time. Changebot helps you maximize that opportunity. [← Back to Blog](/blog) # Product Manager Fiction: Why Your PRDs Aren't the Source of Truth URL: https://www.changebot.ai/blog/product-manager-fiction/ Description: PRDs and specs describe a future that may never exist. The code that ships is your actual tether to reality. Here's why this disconnect matters. Last updated: 2025-12-10 Best Practices # Product Manager Fiction: Why Your PRDs Aren't the Source of Truth [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder December 10, 2025 5 min read ![Faded spec document floating like a dream contrasted with solid grounded code blocks](/_astro/featured.BvadUFir_ZP8ntR.webp) A Product Operations professional recently introduced me to a phrase I can’t stop thinking about: “product manager fiction.” PRDs, specs, initiative briefs — these are stories about a future world where the feature works exactly as planned. They’re forward-looking documents describing intent. And they’re almost always wrong by the time the code ships. ## The Fiction Problem Here’s what happens in most organizations: 1. A PM writes a detailed spec describing how a feature should work 2. Engineering starts building 3. The team learns things — technical constraints, user feedback, shifting priorities 4. The code evolves to reflect reality 5. Nobody updates the original spec A Director of Product at a workplace software company described their release process as “controlled chaos.” The week of launch, product is still iterating. The spec from three months ago? It’s a historical artifact, not a current description. The underlying issue is a fundamental mismatch between how we document intent and how software actually gets built. ## Why Specs Become Fiction The problem isn’t that PMs are lazy about updating documents. It’s that updating documents provides almost no value in the moment. When you’re in the middle of a sprint and you’ve learned that the original approach won’t work, your options are: 1. Stop everything and update the PRD (which no one will read) 2. Solve the actual problem and ship working code Every rational person chooses option two. The PRD becomes fiction not through neglect but through entirely reasonable prioritization. A VP of Product Marketing at an observability company put it bluntly: “There’s no relationship with what was actually put into a PR and documentation.” The spec exists in one world. The code exists in another. And the connection between them is a PM’s memory — which is already overloaded. ## The Spec-Reality Gap Here’s where it gets dangerous. Leadership still references those specs when making decisions. They assume the spec represents reality. They ask questions like “How far along are we on the Q3 initiative?” and expect the spec to be the answer. Here’s the paradox: if the spec and code matched 100% it would actually be a bad sign ( it would mean the team learned nothing during development) so the spec can never be an accurate measure of progress. One Product Operations leader described it this way: if you expect specs and shipped code to match 100%, you probably have team dysfunction. Learning should change the plan, so the code that shipped is your tether to reality — while the spec only captures what you believed when you wrote it. ## What Actually Happened vs. What We Said Would Happen The code tells a different story than the spec. Consider two teams that both shipped a Slack integration: - Team A built it for a CRM, giving sales reps faster visibility into lead activity - Team B built it for a project management tool, notifying teams about status changes The code might look nearly identical — same Slack API endpoints, similar data structures. But the customer value differs entirely. The spec might have mentioned “Slack integration” in both cases, but the code combined with context reveals the actual intent. This is why teams that try to measure progress against specs get frustrated. The spec says “build Slack integration.” The code says “give sales reps instant lead updates.” These are the same work but different stories. ## The Source of Truth Problem Most organizations have no single source of truth for what actually shipped and why. They have: - **Specs and PRDs** — forward-looking fiction - **Jira tickets** — task management without context - **PR descriptions** — technical, not customer-focused - **Release notes** — often written weeks later from memory - **Team meetings** — ephemeral, no record A Head of Developer Relations at a startup told me their docs and tutorials “lag behind engineering velocity.” The team ships faster than anyone can document. The source of truth becomes whatever the most knowledgeable person remembers. This is why so many organizations rely on meetings as their actual source of truth. If you want to know what shipped and why, you schedule a call with the PM. That’s not scalable, and it’s not searchable, but it’s often the only option. ## Making Code the Record The alternative is treating the code itself (the commits, the PRs, the diffs) as the authoritative record of what happened. Not what we planned to happen. What actually happened. This requires a shift in thinking: **From:** The spec defines the feature; code implements it **To:** Code defines the feature; specs are early hypotheses When you make this shift, three things change: 1. **Progress tracking** becomes about analyzing what shipped, not comparing against outdated specs 2. **Communication** starts from reality and works outward, not from plans 3. **Documentation** can come directly from what actually exists — no reliance on memory The code doesn’t lie. It might be messy, it might have workarounds, but it represents real decisions made by people with real context. Those decisions are valuable data. ## Living Documents That Actually Live Some teams are experimenting with what one leader called “living documents” — artifacts that update automatically based on what’s actually happening, not what someone remembers to write down. Imagine a strategy document that updates itself when meetings happen, when code ships, when the team makes decisions. Not a static artifact that becomes fiction the moment it’s written, but a dynamic record of reality. This sounds futuristic, but the raw material already exists. Every PR contains context, every commit tells a story, and every merge is a decision point. The question is whether you can extract that context and connect it to something meaningful. ## The Path Forward Product manager fiction isn’t going away. Teams will always write specs, and specs will always diverge from reality. The goal isn’t to kill specs — they serve a purpose in rallying teams around intent. The goal is to stop treating fiction as fact. This means: 1. **Accept that specs are hypotheses** — early guesses that will evolve 2. **Build systems that capture what actually ships** — the reality, regardless of the original plan 3. **Connect code-level changes to customer value** after the fact — once you know what really happened 4. **Make the code searchable and meaningful** to non-technical teams The PM who wrote the spec three months ago had the best information available at the time. The engineer who shipped the code last week has better information now. Both are valuable. But only one is true. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # Product Marketing Across 20 Products URL: https://www.changebot.ai/blog/product-marketing-across-20-products/ Description: Most PMM advice assumes you own one product. But what happens when you're responsible for 10, 20, or 100? The playbook breaks down. Here's how to scale without losing your mind. Last updated: 2026-01-11 Best Practices # Product Marketing Across 20 Products [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder January 11, 2026 6 min read ![Single figure with radiating connections to many product icons showing coverage spreading thin](/_astro/featured.3_OAoZzT_IvMzE.webp) Most product marketing advice assumes a simple model: one PMM, one product. You own the positioning and you know the roadmap. You’re embedded with the engineering team, attending sprint reviews and reciting the feature list from memory. Then reality hits. You’re a product marketer at a growing company, and suddenly you’re responsible for five products, then ten, then twenty. The playbook that worked for one product doesn’t scale. And nobody talks about what to do instead. ## The multi-product reality During a recent call, a product marketer described her situation: she’s responsible for approximately 20 significant products at a large enterprise company. Not 20 features. Not 20 SKUs. Twenty distinct products, each with its own engineering team, roadmap, and release cadence. “I get updates from many teams,” she told me. “Sometimes I need to join the call to actually know what’s going on.” For each quarterly event, she compiles updates across all 20 products into a document that stretches to 100 pages. The process is, in her words, “terrible.” She’s not unique. As companies grow, PMM coverage spreads thin. A mid-market SaaS company might have three PMMs covering a dozen products. An enterprise software company might have product portfolios where one person covers an entire category. The math doesn’t work if you try to apply single-product techniques at multi-product scale. ## What breaks at scale **Deep product knowledge becomes impossible.** You can’t attend every standup for 20 products. You can’t read every PRD, join every sprint review, absorb every technical decision. The mental overhead alone would consume your entire week. **Relationship maintenance multiplies.** Each product has its engineering lead, its PM, its key stakeholders. When you cover one product, maintaining those relationships is natural. When you cover twenty, it becomes a part-time job just to stay connected. **Update collection becomes your full-time work.** If gathering updates for one product takes an hour a week, gathering updates for twenty products takes… well, more than twenty hours, because the coordination overhead compounds. **Context-switching destroys depth.** You can’t do deep positioning work when you’re constantly switching between products. Every switch has a cognitive cost. By the time you’ve rebuilt context on product #15, you’ve lost the thread on products #1-14. **Event prep becomes a death march.** Quarterly business reviews, sales kickoffs, partner summits: each one requires comprehensive updates across your entire portfolio. The weeks before major events turn into pure information gathering, leaving no time for actual marketing work. ## The coverage myth There’s a tempting fantasy that you can cover many products with the same depth as one product if you just work harder or get more organized. This is a myth. At some point, you have to make a strategic choice about what kind of coverage is actually possible. You can’t do everything at the same quality. Something has to give. Most multi-product PMMs end up with implicit tiers: - **Tier 1**: Products getting active marketing attention. Maybe two or three at any given time. - **Tier 2**: Products getting maintenance coverage. You update the materials when someone asks. - **Tier 3**: Products that technically have a PMM but effectively don’t. You know they exist. That’s about it. This tiering is rational. It’s also often invisible and unacknowledged, which means leadership expects Tier 1 coverage on Tier 3 products and is perpetually disappointed. ## The leverage question When you’re stretched across many products, every workflow question becomes a leverage question: what can I do once that benefits many products? The single-product PMM can afford bespoke processes: a custom launch checklist, hand-crafted release notes, individually written customer emails. The multi-product PMM needs systems: repeatable templates, automated collection, and scalable distribution. The highest-leverage activities for multi-product PMMs are often not product-specific at all: - Building systems that capture updates across all products automatically - Creating templates that work for any product with minimal customization - Establishing distribution channels that can carry any product’s message - Developing relationships that give you “push” notification when something important ships The lowest-leverage activities are the ones you repeat twenty times: - Joining each product’s standup to stay informed - Writing bespoke updates for each product from scratch - Manually compiling information that automation could pull - Having the same “what shipped?” conversation with twenty different teams ## Automation as survival For single-product PMMs, automation is a nice-to-have. It saves time, but the work is doable without it. For multi-product PMMs, automation is survival. Consider the update collection problem. If you’re covering three products, you can probably keep up manually. Some Slack monitoring, a few meetings, occasional Jira diving. It’s not fun, but it’s manageable. At twenty products, manual collection is impossible. You physically cannot watch twenty Slack channels, attend twenty standups, and query twenty Jira projects. Something has to do that work for you. The PMM I mentioned earlier described her aspiration perfectly: she wanted a tool that could give her recurring summaries across all her products, updated automatically, so she could spend her time on positioning and messaging instead of information archaeology. ## Different products, different cadences One complication at multi-product scale: not all products move at the same speed. Some products ship weekly while others ship quarterly. Some are in active development; others are in maintenance mode. A single-product PMM can match their cadence to the product. A multi-product PMM needs a system that handles variable cadences gracefully. The approach I’ve seen work best: **Unified visibility, differentiated action.** Have a single system that surfaces updates across all products. But don’t treat all updates equally. Some warrant immediate attention. Others can wait for the monthly rollup. The system shows you everything; your judgment decides what to act on. **Event-driven prioritization.** Ahead of a major event, temporarily increase your focus on the products you’ll feature. After the event, return to baseline coverage. This is explicitly opportunistic, and that’s okay. **Proactive alerting.** Instead of checking twenty products every day, get notified when something significant ships. Let the products that need attention surface themselves. ## The role evolution Something changes in how you approach your job when you’re covering many products. You stop being the person who knows everything about one product. You become the person who can quickly synthesize information about any product in your portfolio. You stop being the bottleneck for every piece of product communication. You become the architect of systems that generate communication at scale. You stop attending every meeting. You become skilled at extracting meeting outcomes asynchronously. This is a different kind of expertise. The PMM who can effectively cover twenty products has skills that the single-product PMM doesn’t develop: systems thinking, prioritization under constraints, scalable process design. ## Getting to sustainable If you’re drowning in multi-product coverage, here’s a starting point: **Acknowledge the math.** You cannot provide single-product depth across twenty products. Stop trying. Explicitly tier your portfolio and make the tiers visible to stakeholders. **Automate collection first.** The biggest time sink is gathering information. Solve that problem, and everything downstream gets easier. **Standardize your outputs.** Create templates for updates, launch materials, and event documentation that work across products. The time you save on formatting is time you can spend on thinking. **Build push, not pull.** Instead of constantly querying teams for updates, create systems where updates come to you: automated feeds, Slack notifications, and API integrations that make information flow to where you need it. **Protect strategic time.** Block calendar time for deep work on your Tier 1 products. The urgent requests from Tier 3 products will always try to consume this time. Protect it ruthlessly. ## The hidden opportunity Here’s what I’ve noticed about the best multi-product PMMs: they develop a cross-portfolio perspective that single-product PMMs lack. They see patterns across products. They notice when the same customer objection arises in different contexts. They identify messaging that works broadly. They develop an instinct for what matters and what doesn’t. This perspective is valuable, but only if you have the time to think. If you’re buried in update collection and meeting attendance, you never develop it. The goal of building systems is creating space for the strategic thinking that only someone with your breadth of coverage can do. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # Product Marketing Is the Ascendant Discipline in 2026 URL: https://www.changebot.ai/blog/product-marketing-is-the-ascendant-discipline/ Description: Top-of-funnel SEO content is dying. LLMs are the new discovery channel. The companies that win are the ones writing about what their product actually does, not chasing keywords. Last updated: 2026-02-12 Best Practices # Product Marketing Is the Ascendant Discipline in 2026 [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder February 12, 2026 5 min read ![Product content cards ascending a staircase into a spotlight while generic SEO blog posts fade below, with AI chat bubbles at the top](/_astro/featured.CzAQQKXs_ZnHJua.webp) A co-founder said something on a call recently that crystallized what we’ve been seeing across dozens of conversations: “Product marketing is the ascendant discipline in marketing now. Writing about your product and what it does is how you’re found.” He’s not wrong. And the implications are bigger than most marketing teams realize. ## The old playbook is collapsing For the past decade, SaaS marketing meant content marketing. And content marketing meant top-of-funnel blog posts. “What is a changelog?” “10 best practices for release notes.” “The ultimate guide to product communication.” All designed to capture search traffic and nudge readers toward your product. That playbook worked when Google was the starting point for every buying decision. It’s not anymore. Buyers are going directly to LLMs with questions that would have been Google searches a year ago. But the questions are fundamentally different. Instead of “best changelog software,” they’re asking: “I have a 15-person engineering team using GitHub and Linear, shipping twice a week, and I need something that automatically creates customer-facing updates from our PRs. We use Slack internally and want updates distributed there too. What should I use?” The LLM doesn’t care about your “What is a changelog?” blog post. It cares about whether it has enough information about your product to recommend it for that specific, contextual query. ## Why product marketing wins Product marketing, the discipline of describing what your product does, who it’s for, and why it matters, has always been important. But companies have always treated it as a supporting function. The real money was in demand gen, SEO, paid acquisition, event marketing. That’s inverting… here’s why: When discovery moves from search engines to LLMs, the nature of what gets found changes. SEO rewarded broad, keyword-rich content that matched generic queries. LLM-driven discovery rewards specific, detailed, accurate product information that matches highly contextual questions. A product lead at a documentation-focused company told us that public-facing updates and release notes increasingly matter for LLMs crawling content just as much as for human prospects. She described steady release communication as a credibility signal for both audiences. An AI strategy leader put it more bluntly: “You’re starting to optimize for the models now. It’s not optimizing for SEO.” ## The specificity advantage In the old world, you’d never write a blog post about a minor bug fix. There’s no SEO value in “we fixed an edge case in our Slack integration.” Nobody’s searching for that phrase. In the new world, someone absolutely is typing into their LLM: “I use Slack and keep running into this problem with notifications from product update tools. Which ones handle this well?” If you’ve published detailed content about your Slack integration, including the edge case fix, the LLM can recommend you. If you haven’t, you’re invisible for that query. This changes the calculus on what’s worth publishing. Every feature, every integration, every fix, every comparison — they all matter because you can’t predict the context someone will ask about. One founder captured the scale of this challenge: you need content for “every different permutation of your product and everything you integrate with. Every problem it might solve, every technical feature, how it connects into every tech stack.” That’s a staggering amount of content. Far more than any marketing team could write manually. ## Product marketers have been starving for this Here’s the irony: product marketers have always wanted to write about the product, because that’s literally their job. But a system that undervalues their work has held them back. At many companies, product marketing doesn’t even exist as a dedicated function until the company reaches 200+ employees. Before that, PMs handle launch communications reluctantly, and the first marketing hire must be a generalist covering social, events, content, and product messaging simultaneously. One product lead at a startup told us she would ship features and then “hold off for weeks” on the announcement email because product marketing wasn’t her strength or her passion. The features launched. The communication didn’t. A standards organization we spoke with has 30+ releases per year supported by one part-time marketing consultant. The product managers handle most communication themselves, on top of their actual jobs. Companies have understaffed and underresourced product marketing for years. Now it’s the most important marketing function. The gap between what’s needed and what exists is enormous. ## This shift is structural This isn’t a trend that’s going to reverse. LLMs are getting better at product evaluation, not worse. More buyers are using them as their primary research tool, not fewer. The percentage of buying decisions influenced by LLM recommendations is growing, not shrinking. Companies that recognized this early and invested in detailed, comprehensive product content are already seeing the results. Their products get recommended more often, which means more customers and more feedback. Better feedback means better product, and better product means more content to publish. Meanwhile, the company still investing in “What is {concept}?” blog posts is producing content that LLMs can answer without ever sending anyone to their site. ## The practical challenge If product marketing is the ascendant discipline, the practical question is: how do you produce enough product content to matter? Your engineering team ships changes every week. Each change has a customer benefit. Each benefit could match someone’s LLM query. But translating code changes into customer-facing product content at the pace of engineering output is a volume problem that no marketing team can solve with headcount alone. The old model was: ship a feature, wait for the PMM to write it up, review, publish, and move on. That model produced maybe one or two pieces of product content per month. The new model needs to produce detailed product content with every shipped change. That means understanding the code, the customer context, and the competitive field well enough to generate accurate, benefit-focused content at the speed of engineering. That’s not a people problem. That’s an infrastructure problem. And the teams that solve it first will own the LLM discovery channel while everyone else is still writing top-of-funnel blog posts for a search engine that’s losing its monopoly. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # Proof of Shipping: The New Table Stakes for Vendor Evaluation URL: https://www.changebot.ai/blog/proof-of-shipping/ Description: Prospects check your changelog before they book a demo. Investors want evidence of velocity. A stale update history says 'abandoned' louder than any pitch deck can overcome. Last updated: 2026-02-17 Best Practices # Proof of Shipping: The New Table Stakes for Vendor Evaluation [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder February 17, 2026 4 min read ![Two changelogs side by side: a vibrant stack of update cards with a verification badge versus a sparse faded timeline with cobwebs](/_astro/featured.BBaEHGWA_1EbBq1.webp) An operations lead at a CRM company told us they needed Changebot for a simple reason: they needed a way to show “we’re alive and we’re still working on stuff” when prospects assess their product. Nobody had touched their changelog page in two or three years. They wanted to start fresh rather than draw attention to the gap. If you look at the problem literally you’d have to say it’s a documentation problem, but the root issue is that you’re losing credibility. ## The evaluation checkbox Somewhere in the past few years, checking a vendor’s update history became a standard part of the buying process. Prospects don’t just look at your features page. They look at your changelog, your release notes, your recent updates. They want to see evidence that you’re actively building. A savvy buyer will scroll through your last few months of updates before they even book a demo. If they see consistent, detailed product updates, they think: this team is shipping. This product is improving. This company invests in their product. If they see a last update from 2024 or a changelog that someone abandoned months ago, they think: does anyone still maintain this product? Is this company even still around? One product marketing leader described the downstream effect: customers and prospects say “I had no idea this exists” about features the team shipped and announced. The features were there. The proof wasn’t visible enough. When the proof isn’t there, the default assumption is that nothing is happening. ## Investors want receipts The scrutiny extends beyond prospects, private equity firms and VCs increasingly want to see detailed evidence of shipping velocity. An AI strategy leader shared that PE-backed companies face rigorous tracking expectations. Investors want to know “every bit and piece” that the team has shipped, consistently. It’s not enough to say “we had a productive quarter.” They want the receipts: what shipped, when, and what it means for the product. One founder described the investor skepticism that haunts every early-stage AI company: “Anyone could build this.” The counter-argument? A visible history of consistent, complex shipping. When an investor can see that you’ve pushed meaningful updates three times a week for the past year, the “anyone could build this” argument loses its teeth. Proof of shipping is proof of execution. And execution is the one thing competitors can’t fake. ## The stale changelog death spiral Here’s what typically happens. A team launches a changelog with great intentions, and the first few entries look detailed and polished. Then the person responsible gets pulled into a feature sprint. One month passes without an update, then two, then six. By the time someone notices, the changelog has become an embarrassment rather than an asset. And the thought of backfilling six months of updates feels so overwhelming that the team decides to just… leave it. Now you have a public page on your website that tells visitors your product is dead. Every day it sits there, it’s working against you. Prospects see it and move on. Competitors with active changelogs win the deal before you even know there was one. The team we spoke with who had a two-to-three-year gap in their changelog chose to begin fresh rather than try to resurrect the old page. That’s a reasonable response, but it also confirms that years of product development went undocumented. ## Shipping cadence as competitive moat A steady stream of product updates does more than impress evaluators. It builds a narrative over time. When a prospect scrolls through twelve months of consistent updates, they’re not just checking a box — they’re building confidence. They can see the trajectory of the product, which areas get attention, and that the team responds to feedback and fixes issues quickly. This is especially powerful in competitive evaluations. If a buyer is choosing between two similar products and one has a rich, detailed update history while the other has a marketing page and a pricing page, the product with visible shipping history wins. Every time. One founder described it this way: showing a consistent shipping cadence is “how you get credit for what you’re doing.” Without it, all the engineering work is invisible. The product improves, but nobody sees it. ## The feedback loop Proof of shipping creates a virtuous cycle. Customers who see regular updates are more engaged, and more engaged customers provide better feedback. That feedback drives better product decisions, which lead to more meaningful updates. Teams that publish regularly also develop a sharper sense of what matters. When you have to describe every shipped change in customer terms, you start making different product decisions. You think about the customer benefit earlier in the process. You write better tickets. You scope features with communication in mind. The companies that treat shipping visibility as a core practice, not an afterthought, end up building better products. The proof of shipping doesn’t just show what you’ve built. It shapes what you build next. ## Table stakes, not nice-to-have Five years ago, a changelog was a nice-to-have. A quarterly newsletter was enough. Customers didn’t expect to see a real-time feed of product improvements. That’s changed. Prospects expect it, investors demand it, and competitors are already doing it. LLMs are indexing it to decide who gets recommended to the next buyer who asks “which tool should I use?” Proof of shipping has become table stakes. The question isn’t whether to maintain a visible shipping cadence. It’s whether you can sustain one without burning out the people responsible for creating it. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # Publish Your Changelog From Claude Code URL: https://www.changebot.ai/blog/publish-your-changelog-from-claude-code/ Description: A practical example of the Changebot MCP workflow: ask for an update, review the draft, and publish without leaving your agent surface. Last updated: 2026-06-13 Examples # Publish Your Changelog From Claude Code [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder June 13, 2026 2 min read ![Developer workflow with AI coding tools and release communication signals](/_astro/featured.KqEEKq0c_1iiJvF.webp) Claude Code is becoming a natural place to ask, “What did we just ship?” That question should not end with a paragraph trapped in your terminal. It should end with a reviewed changelog entry, a durable URL, and the right version routed to the right audience. That is the point of the Changebot MCP workflow. ## The basic flow Start with the question you already want answered: ``` Ask Changebot: write a customer-facing changelog update for what shipped last week. ``` Changebot can return a draft, the source context it used, and a review URL: ``` Draft ready: "Billing exports are easier to reconcile" Review: https://app.changebot.ai/review/billing-exports Suggested destinations: hosted changelog, customer widget, internal Slack ``` Then you keep working in the same surface: ``` Make it less technical, add a support-team version, and publish the customer version. ``` The important part is not the exact command syntax. The important part is the shape of the workflow: ask, review, edit, approve, publish. ## Why MCP changes the changelog workflow Most changelog tools assume you will leave your work, log in, and write inside their interface. MCP flips that. The agent surface becomes the starting point. Claude Code, ChatGPT, Slack, or another MCP-compatible client can collect intent and source material. Changebot turns that into a publishable update and sends it to the changelog destination. That matters because the source material is already scattered: - The actual code lives in GitHub or Bitbucket. - The planning context lives in Linear, Jira, or Slack. - The draft might start in Claude or ChatGPT. - The final customer-facing record needs to live on a URL. Changebot connects the last mile. ## What happens after the draft A generated release note is not done just because the words exist. Someone still needs to decide whether the update is customer-facing, whether it should be internal-only, how much detail support needs, and where the final version should live. The MCP workflow keeps those decisions explicit: 1. The agent drafts the update. 2. Changebot returns a review link. 3. A human edits or approves. 4. Changebot publishes to the hosted changelog, widget, Slack, API, or custom domain. That is different from raw summarization. Raw summarization gives you text. Changebot gives you a publishing workflow. ## Start with one update You do not need to connect every repo on day one. Start with one update. Paste a rough launch note, ask for a customer version, review the draft, and publish it to your hosted changelog. When that workflow works, add GitHub or Bitbucket so Changebot can draft from what actually shipped. [Start free](https://app.changebot.ai/signup), or read more about the [Changebot MCP](/product/mcp). [← Back to Blog](/blog) # Release Notes Template: Four Formats You Can Copy URL: https://www.changebot.ai/blog/release-notes-template/ Description: Four copy-paste release notes templates — standard release, single feature launch, bug fix roundup, and breaking change — with guidance on when to use each. Last updated: 2026-09-18 Examples # Release Notes Template: Four Formats You Can Copy [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder September 18, 2026 3 min read ![A figure fitting a green block into a dashed placeholder slot on a large template page, surrounded by completed pages](/_astro/featured.BnjobCpF_15V8LT.webp) In short A release notes template is a reusable structure for announcing a change: a plain-language title, one sentence on what changed, one on why it matters to the customer, and a link to docs or the feature itself. Four formats cover almost every release: standard, feature launch, fix roundup, and breaking change. Most teams don’t have a release notes problem. They have a blank page problem. The work is shipped, the pull requests are merged, and someone still has to decide how to open the sentence. So the update slips a day, then a week, and eventually the changelog reads like an archaeology project. A template removes that decision. Below are four formats that cover almost every release, along with when to use each. ## The standard release template Use this for a normal release with several unrelated items. ``` ## [Release name or date] ### New **[Feature name]** - [What it does, in one sentence.] [Why it matters to the customer, in one sentence.] [Link to docs.] ### Improved **[Area]** - [What is better now.] [What the customer will notice.] ### Fixed - [Symptom the customer saw, not the root cause.] - [Symptom the customer saw, not the root cause.] ``` Two rules make this format work. Group by what it means to the reader (new, improved, fixed) rather than by team or service. And describe fixes by the symptom the customer experienced, not by the internal cause. “Fixed a race condition in the sync worker” tells the customer nothing. “Comments no longer disappear when two people reply at the same time” tells them whether the thing that annoyed them is gone. ## The feature launch template Use this when one item deserves the whole update. ``` ## [Feature name] [One sentence on what it is and who it is for.] **The problem.** [The situation the customer was in before.] **What is new.** [What they can now do, in two or three sentences.] **How to use it.** [The shortest path to trying it: where to click, what to run.] [Screenshot or short clip.] [Link to documentation.] [Link to the feature.] ``` The problem paragraph is the part teams skip and the part readers need. A feature announced without its problem is a list of nouns. The same feature announced with its problem is a story the reader can place themselves inside. ## The bug fix roundup template Use this for maintenance releases where nothing is individually newsworthy. ``` ## Fixes and maintenance - [date] We spent this cycle on stability. Highlights: - **[Area]** - [Symptom that is now gone.] - **[Area]** - [Symptom that is now gone.] - **[Area]** - [Symptom that is now gone.] Plus [number] smaller fixes across [areas]. ``` Maintenance releases are worth publishing precisely because they look unglamorous. They’re proof that the product is maintained, and for a customer evaluating whether you’re still shipping, that’s the signal they’re looking for. We wrote more about that in [why bug fixes deserve announcements](/blog/why-bug-fixes-deserve-announcements/). ## The breaking change template Use this whenever a customer has to do something before a date. ``` ## [Change name] **Action required by [date].** **What is changing.** [Precise description of the old and new behavior.] **Who is affected.** [Specific: which plans, endpoints, versions, or integrations.] **What you need to do.** [Numbered steps, shortest viable path.] **What happens if you do nothing.** [The consequence, stated plainly.] [Link to migration guide.] [Link to support.] ``` The last section is the one people cut, and it’s the only one that reliably drives action. A customer who can’t tell what breaks will assume nothing does. ## Filling the template is still the hard part A template solves the blank page. It doesn’t solve the part where someone has to read a week of commits, work out which of them a customer would care about, and translate each one out of engineering language. That translation is what [the Changebot Agent](/product/agent/) does. It reads your GitHub or Bitbucket history, picks the changes that are customer-facing, and drafts the entry in these shapes for a human to approve. The trade is what makes the cadence sustainable: editing is faster than writing, and a ten-minute review beats an afternoon of composing from a merge list. Publishing the result — to a [hosted changelog](/product/publishing/), an embedded widget, Slack, or RSS — is free. ## Related reading - [Changelog vs release notes: what is the difference?](/blog/changelog-vs-release-notes/) - [Changelog examples worth copying](/blog/changelog-examples/) - [How to publish a changelog from GitHub](/blog/how-to-publish-a-changelog-from-github/) ## Frequently Asked Questions What should a release notes template include? A title in customer language, a one-sentence summary of what changed, a sentence on why it matters, who it affects, and a link to documentation or the feature. Anything beyond that is optional, and anything less leaves the reader guessing. How long should release notes be? Two to four sentences per item for most releases. A major launch can justify a few paragraphs and a screenshot. If an entry needs more than that, it wants its own page and a link from the changelog. Should release notes include internal ticket numbers? No. Ticket numbers mean nothing to customers and make an update read like an internal report. Keep them in the commit or pull request, where they already are, and write the customer-facing entry in plain language. How often should you publish release notes? Publish on a rhythm your customers can learn, usually weekly or per release. Consistency matters more than frequency: a predictable weekly update gets read, while a sporadic one gets ignored even when the work behind it is good. ## Table of Contents - [The standard release template](#the-standard-release-template) - [The feature launch template](#the-feature-launch-template) - [The bug fix roundup template](#the-bug-fix-roundup-template) - [The breaking change template](#the-breaking-change-template) - [Filling the template is still the hard part](#filling-the-template-is-still-the-hard-part) - [Related reading](#related-reading) Stop writing the changelog by hand The Changebot Agent drafts customer-ready updates from your GitHub history. Publishing is free. [Get Started for Free →](https://app.changebot.ai/signup) [← Back to Blog](/blog) # Sharing screenshots of your changelog drafts is a red flag URL: https://www.changebot.ai/blog/sharing-screenshots-of-your-changelog-drafts-is-a-red-flag/ Description: When your team reviews changelog entries by taking screenshots of drafts and pasting them into tickets, the tool has become the bottleneck. Last updated: 2026-02-13 Best Practices # Sharing screenshots of your changelog drafts is a red flag [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder February 13, 2026 1 min read ![Illustration of a clunky workflow with screenshots being pasted between a changelog editor, a capture frame, and ticket comments](/_astro/featured.CgeNT2Li_Z1MiiNF.webp) A founder told us how his team reviews changelog entries before publishing. He writes a draft in his changelog tool, takes a screenshot, pastes it into a Linear ticket, and asks his teammate for feedback. On a screenshot. Of text. His teammate comments on the image. He reads the feedback, switches back to the changelog tool, and manually applies the changes. If the feedback requires a rewrite, they go another round. Screenshots, comments, transcription. He wasn’t embarrassed about it. It’s just how they work. Their changelog tool doesn’t support collaborative drafting, so they invented a workaround. ## The workaround tells the story When a team builds elaborate processes around a tool’s limitations, the tool has become the bottleneck. Screenshots in project management tickets, drafts shared over email, “just tell me in Slack what to change” — these are all symptoms of software that wasn’t built for how teams actually collaborate. Changelogs are customer-facing writing. They deserve the same review process as any other customer-facing content: drafting, feedback, iteration, and approval before publishing. ## Changelog software should work like the rest of your tools We built Changebot in a world where collaboration between you, your team, and AI is the default. Draft an update, refine it with AI, share it for review, iterate on the language, and publish when it’s ready. No screenshots required. Your changelog tool should fit your workflow. Not the other way around. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # Signal vs. Noise: What Customers Actually Care About URL: https://www.changebot.ai/blog/signal-vs-noise-what-customers-care-about/ Description: Not every code change is worth announcing. Database indexes, infrastructure tweaks, and internal refactors are valuable work but noise to customers. Here's how to filter. Last updated: 2025-12-07 Best Practices # Signal vs. Noise: What Customers Actually Care About [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder December 7, 2025 5 min read ![Illustration of a filter separating a chaotic stream of technical items into two paths: a highlighted signal path with key updates flowing to customers, and a faded noise path with internal changes](/_astro/featured.CAUlgTrj_Z1NRQ7H.webp) I was recently helping a Chief Product Officer review their release notes for the month. We went through the list of changes together, and about halfway through, they paused. “Half of these items are like adding a database index,” they said. “I know that was a valuable change… but that’s noise when communicating benefits to customers.” They were right. And this is a problem I see at almost every company: the inability to distinguish between work that matters internally and work that matters to customers. ## Not All Work Is Customer-Facing Here’s a sample of what engineering shipped last month at a typical SaaS company: - Added new onboarding wizard - Upgraded to PostgreSQL 15 - Fixed race condition in payment processing - Added database index on user lookups - Implemented new dashboard analytics - Refactored authentication module - Fixed typo in error message - Migrated to new hosting provider - Added retry logic for failed API calls - Updated dependencies to patch security vulnerability Some of these are major customer-facing improvements. Some are important but invisible. Some are somewhere between. And the challenge is that to the people who did the work, all the changes feel significant. ## The Filter Problem When teams don’t filter, two bad things happen: **Option A: They share everything.** The monthly update becomes a wall of technical changes that customers can’t parse. The important stuff gets buried. Customers skim, learn nothing, and stop reading updates altogether. **Option B: They share nothing.** Faced with the difficulty of filtering, the team delays or skips the update entirely. Customers don’t know what shipped. The company gets no credit for its work. Neither outcome serves the customer or the business. ## What Makes Something Customer-Facing? Here’s a simple framework for filtering: **Customer-visible:** Will customers notice this change in their day-to-day use of the product? - New onboarding wizard: Yes - Database index: No **Customer-impactful:** Does this change affect something customers care about (speed, reliability, cost, capability)? - Fixed payment processing race condition: Yes - Refactored authentication module: Probably not directly **Customer-communicable:** Can you explain the benefit in terms the customer understands? - “Faster page loads” is communicable - “Reduced technical debt in auth layer” is not If a change passes at least one of these tests, it’s a candidate for customer communication. If it passes none, it’s probably noise. ## The 80/20 Reality A CEO at a fintech company told me: “Roughly 80% is good to know internally, 20% relevant externally. There’s no good system today for separating internal vs. external.” This ratio holds at most organizations. Engineering ships a lot of work, and most of that work stays invisible to customers by design. That’s not a problem — that’s how good products get built. Infrastructure improvements, technical debt reduction, and internal tooling all matter. The problem is when organizations can’t distinguish between the two categories, leading to either over-communication (noise) or under-communication (silence). ## Why This Is Hard Filtering requires context that doesn’t live in any single place: **Technical context:** What did this change actually do? (Lives in the code) **Business context:** Why did we build this? (Lives in the PM’s head) **Customer context:** Who cares about this? (Lives in support/success knowledge) **Communication context:** How should we talk about this? (Lives in marketing) No single person or system has all four. Engineers know what changed but not necessarily why it matters to customers. Marketing knows how to communicate but not what actually shipped. Support knows customer pain points but not the technical details of fixes. This is why filtering often fails: it requires synthesis across organizational boundaries that rarely happens organically. ## Signs You’re Getting It Wrong **Too much noise:** - Customers stop reading your updates - Updates read like technical changelogs - “Bug fixes and improvements” appears regularly without specifics - Internal stakeholders forward updates asking “what does this mean?” **Too much silence:** - Customers don’t know about features that exist - Support gets surprised by changes - Churn mentions “we didn’t know you had that” - Sales team has stale battle cards **The worst case:** - You’re doing both: sharing too much detail about things that don’t matter while missing the things that do ## Practical Filtering Approaches **Review as a team.** Don’t let one person filter alone. A quick 15-minute review with engineering, product, and marketing catches misses and reduces noise. **Use explicit categories.** “Customer-facing” vs. “internal” as a required label on every change. Forces the question early. **Separate internal and external channels.** Internal teams might care about the database index. Customers don’t. Have different destinations for different audiences. **Ask the support test.** Would support need to know about this to help customers? If yes, it’s probably customer-facing. **Apply the “so what” test.** For every item, ask: “What does this mean for the customer?” If you can’t answer directly, it’s probably noise. ## The Key Updates Paradigm When showing a demo to a Head of Product recently, I showed her our “key updates” filter, an automatic classification of which changes represent customer value. Her response: “That’s a game changer.” The insight is simple: you need a system that separates signal and noise before a human ever has to review it. If the starting point is “here are 100 changes, you figure out which ones matter,” you’ve already lost. The cognitive load is too high. The better approach is “here are the 12 changes we think customers will care about, plus the full list if you want to dig.” Reduce the filtering burden to validation, not discovery. ## Building the Filter Muscle Filtering is a skill. Teams that do it well have built the muscle over time: **They document patterns.** “We never communicate dependency updates unless there’s a security angle.” **They create templates.** “New features get a spotlight. Bug fixes get a line item. Infrastructure gets internal-only.” **They review retroactively.** “Last month we shared X and got no engagement. This month we’ll try different filtering.” **They listen to feedback.** “Sales said they need more on pricing changes. Let’s adjust our filter.” Like any skill, filtering improves with practice. The first few attempts will be rough. That’s normal. ## The Goal: Appropriate Communication The goal is appropriate communication, not less communication. Customers should know about things that affect them. Internal teams should know about things that affect their work. Everyone should be able to find more detail if they want it. This means many channels, many formats, many levels of detail. It means thinking about audience before writing. It means accepting that one update won’t serve everyone. The companies that get this right ship just as much as everyone else. They just communicate it more effectively. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # The 100-Page Update Doc Nobody Reads URL: https://www.changebot.ai/blog/the-100-page-update-doc-nobody-reads/ Description: Every quarter, product marketing teams assemble massive update documents for events and stakeholder reviews. They take weeks to compile, and nobody reads them end-to-end. There's a better way. Last updated: 2026-01-09 Best Practices # The 100-Page Update Doc Nobody Reads [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder January 9, 2026 4 min read ![Towering stack of documents with scattered papers versus a clean tablet showing a concise summary](/_astro/featured.Jw8Dybi8_1VToof.webp) You know the document I’m talking about. It’s the one that lands in everyone’s inbox two days before the big event: the quarterly business review, the sales kickoff, the partner summit. It’s got sections for every product, every team, every initiative. Screenshots, bullet points, version numbers, roadmap slides. It’s 100 pages long. And nobody reads it. ## The ritual nobody questions During a recent call with a product marketer at a large enterprise company, she described her update document process as “terrible.” Her exact words. Every quarter, and especially before major events, she has to compile updates from across 20 different products. This means joining calls she wouldn’t otherwise need to attend just to understand what shipped, chasing down engineering leads, translating technical changes into business value, and formatting everything into a consistent structure. The result? A document so comprehensive that it becomes useless. Leadership skims the executive summary, sales scrolls to find their specific product, and support doesn’t know it exists. “And each time we just manually update it,” she told me. The same document, rebuilt from scratch, quarter after quarter. ## Why we keep doing this The 100-page update doc persists because it solves a real problem: nobody knows what shipped. When teams work in silos (and they always do at scale), there’s no single source of truth for product changes. Engineering knows what they built, product knows what they planned, and marketing knows what they announced. But nobody has the complete picture. We create the document. We make it comprehensive because we’re terrified of leaving something out. We make it long because there’s genuinely a lot happening. We distribute it widely because everyone might need some piece of it. And then we wonder why nobody reads it. ## The hidden costs The obvious cost is time. A Director of Product Marketing spending weeks assembling updates is a Director of Product Marketing not doing strategic work. The subtler costs hurt more: **Staleness**: By the time you compile, review, and distribute the document, some of the information is already outdated. That feature you called out? It got delayed. That bug fix? It shipped two weeks ago. **Fragmentation**: The document becomes the canonical source, but it’s immediately forked. Sales pulls out their section and modifies it. Support creates their own summary. Now you have three or four versions of truth floating around. **Meeting multiplication**: The document creates more meetings instead of replacing them: a meeting to walk through the document, follow-up meetings to clarify specific sections, and prep meetings to prepare for those meetings. **Learned helplessness**: When updates only come quarterly, people stop expecting them and develop workarounds. They message engineers directly, they ask in Slack channels. They’ve learned that the official channels don’t work. ## What actually works The solution is eliminating the need for the document entirely. Here’s what that looks like: **Continuous visibility instead of periodic dumps**: When stakeholders can see what shipped as it ships, they don’t need a quarterly catch-up. The 100-page document exists because the default state is ignorance. Change the default. **Audience-appropriate summaries**: Your CEO doesn’t need the same update as your support team. Instead of one massive document for everyone, provide targeted summaries that respect people’s time and context. **Automated collection**: The reason the document takes weeks to compile is that gathering updates is manual. Every conversation, every Slack message, every Jira query: it’s all human labor. Automate the collection, and the synthesis becomes manageable. **Living updates instead of static documents**: A document is dead the moment it’s exported to PDF. A continuously updated feed stays current. People can check it when they need it, not when you decide to distribute it. ## The meeting that changes One thing I’ve noticed with teams that move to continuous product updates: the meetings don’t disappear, but they transform. Instead of spending 45 minutes reading through what shipped, everyone shows up already informed. The meeting becomes a discussion of the two or three things that actually need debate. Strategy, not status. Decisions, not downloads. A product marketer told me that her meetings used to be “lengthy calls to debate product value forever.” That’s what happens when people are learning information in real-time. Give them the information ahead of time, and suddenly the meeting has a different character entirely. ## Start small If you’re staring down your next 100-page document, you don’t have to boil the ocean. Pick one product. Set up automated updates for that product alone. Let stakeholders experience what it’s like to have continuous visibility into what shipped. Then do another product. And another. Eventually, the quarterly document becomes a formality, a lightweight summary that points to the detailed, continuously-updated source of truth. Or it disappears entirely, and nobody misses it. The goal is to make the 100-page document unnecessary. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # The Agent-First Changelog URL: https://www.changebot.ai/blog/the-agent-first-changelog/ Description: The next changelog is not a CMS you remember to update. It is a publishing layer your agents can write to. Last updated: 2026-06-13 Best Practices # The Agent-First Changelog [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder June 13, 2026 2 min read ![A changelog sitting at the end of a long product workflow](/_astro/featured.pnGxyg_q_Z1Yu70o.webp) The changelog is usually the last thing a team updates. Not because nobody cares. Because the work sits outside the flow. Engineering ships in GitHub. Product plans in Linear or Jira. Support talks in Slack. Founders draft in ChatGPT. Developers ask Claude Code what changed. Then, after all of that, someone is supposed to remember to open a separate changelog tool and turn scattered context into a polished update. That model made sense when changelogs were just small CMSes. It makes less sense when agents are becoming the place where teams ask questions, synthesize work, and decide what to do next. ## What agent-first means An agent-first changelog starts from intent. You ask: - What did we ship last month? - Turn this pull request into a customer update. - Rewrite this for support. - Publish this to our changelog. The changelog system should understand that workflow. It should help draft, revise, review, and publish without forcing every update through a manual copy-paste step. The agent is the interface. The changelog is the durable output. ## Why “AI changelog” is too small “AI changelog” usually means a model summarizes commits. That is useful, but it is not enough. Teams do not just need a paragraph. They need a publishing workflow. They need a hosted page, a widget, a custom domain, internal Slack routing, customer-safe review, and a way to turn the same underlying work into versions for different audiences. They also need a path that does not require a heavy implementation project before the first update goes live. That is why the agent-first changelog starts free. Publish the update first. Use a hosted page, widget, custom domain, Slack, MCP, and APIs without turning the publishing layer into a procurement decision. Pay when you want Changebot to understand source context, write the update, and automate weekly or monthly recaps. ## The missing last mile Linear can help generate release notes, but it does not give every team a public changelog page. Claude can summarize a diff, but it does not publish a customer-facing update to a durable URL. Slack can contain the context, but it is not a canonical release history. Changebot exists for that last mile: from draft to reviewed update to published changelog. ## What changes for customers Customers should not have to infer progress from support replies, roadmap rumors, or a stale docs page. With an agent-first changelog, the update history becomes easier to keep alive because publishing happens where the work already is. The release note can start in the agent, move through human review, and land on a page customers can revisit. The best changelog is not the one with the most formatting options. It is the one that stays current because the workflow matches how teams actually work. [Try the agent-first changelog for free](https://app.changebot.ai/signup), or [choose the workflow that fits your team](/start). [← Back to Blog](/blog) # The Art of the Update URL: https://www.changebot.ai/blog/the-art-of-the-update/ Description: The complete guide to writing product updates that prevent churn, attract customers, and prove your value. Last updated: 2024-03-25 Best Practices # The Art of the Update [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder March 25, 2024 66 min read ![The Art of the Update](/_astro/featured.R4nmcstn_sXp31.webp) Nine out of ten companies fail to regularly publish product updates for their customers. For those that do, most aren’t that good. It’s a shame because properly executed updates can remind current customers of the value they receive, entice new customers to join, and, should you increase your prices, help customers understand what they are paying more for. You’re leaving money on the table by not publishing frequent, benefits-focused product updates. This extensively researched piece will: 1. Help you understand the value of writing great customer updates. 2. Provide extensively researched examples of customer updates. 3. Break down best practices derived from our research into rules you can follow, and 4. Offer you some easy-to-use templates. Remember, you’re already improving your product; you deserve credit for that hard work. Let’s dive in. ## Why don’t we send customer updates? I’ve spent many years consulting with product teams in one way or another. Despite having been convinced of the value of product updates for some time, I’ve been somewhat surprised by how few teams decide to write frequent product updates. When I ask directly I’ve gotten several reasons why teams don’t publish product updates more frequently, including: 1. “We don’t have an existing process to write and format the update.” 2. “We’re already so busy building the product, we don’t have time to publish updates.” 3. “We don’t have a team or person who’s accountable for publishing updates.” These are all pretty reasonable, and generally delivered with a straight face from a sane person. I have two parallel theories here. The first theory is that if you’re not in the habit of doing anything, the activation energy required to start is high. Companies of every size, from startups to the largest companies in the world, feel overworked. So the notion of spending 10 hours building and 10 hours writing updates is rejected in favor of 20 hours of building. Moreover, it can be surprisingly complex to figure out who “owns” this process. The developers are most familiar with the changes, but are also stereotypically the worst at communicating with customers. The marketing team is great at talking to customers, but might not have the full story on the changes that are happening. There’s definitely a team effort involved which gets way easier once the process is in motion. The second theory is that most teams dramatically underestimate the value of what great customer updates can do for them. Let’s talk about that. ## Why should we send customer updates? By the way—if you’re overwhelmed by trying to write these frequent, churn reducing, upsell inducing customer updates while also running your business… Changebot can do this for you automatically. Just like a customer reading your product update, you want to know: “What’s it in for me? How does following this make my business better?” Awesome customer updates benefit your business by: - Preventing churn - Increasing new customers - Boosting expansion revenue - Setting up for a price increase - Building trust - Earning referrals and testimonials ### Preventing churn Great customer updates **prevent churn** in two key ways. First, it’s easy to toil away on the product without updating your customers. You might reason that if you’re going to spend 10 hours improving the product, and 10 hours writing an update, it’d be **better** spending 20 hours improving the product. Wrong! (Actually, doubly so, as writing customer updates should be fast. We’ll cover that later.) You need to get **credit for your code**. Without updates, customers cannot see your hard effort, and most products appear to stagnate. Getting frequent customer updates does triple duty: it shows that your team is hard at work, it shows that you’re always delivering more customer value, and it shows that your team is thoughtful and customer-focused. Consider this from your customer’s perspective. Say you’re a business that has two software subscriptions billed monthly, both are right on the edge of how much you’d like to pay a la Van Westendorp’s Price Sensitivity Meter where “the price is starting to get expensive, but you would still purchase the product.” One company sends weekly updates with new features, changes, and ways that people are using their product to make more money. The second company sends nothing. Which product is more likely to get cut when the budget tightens? I’ve heard this line directly from customers: every monthly invoice is a decision on whether they should churn. Most subscription products auto-renew. Don’t mistake that to mean staying is the presumptive choice for every customer. You’ll be right until the moment you’re wrong, and then they’re gone. You must strive to win your customers’ business with every invoice and never take them for granted. Frequent customer updates are our way of showing customers that they are important to us. Also, It turns out that small, frequent updates appeal to investors too! ![Image 1](/images/blog/the-art-of-the-update/twitter-investor-update.png) Shaan Puri on portfolio company updates. ### Increasing new customers Many businesses mistakenly think that only existing customers are interested in product updates. This misconception is self-reinforcing since many businesses hide product updates behind a login screen, and new customers never see them. The reality is that many potential customers will review the past customer updates to gauge whether the product is stagnating or improving. After an extended sales process, a large customer I was courting chose a competitor. Since I had formed a strong working relationship with this company, they were willing to share their “considerations spreadsheet” with me. The spreadsheet captured all of the reasons they went with our competitor. This was eye-opening on a few fronts. Notably, one item stood out: the number of product updates last quarter. Ours was at zero – not because we hadn’t made any updates, but because they couldn’t find them on our blog. It felt awful reading this because we had published updates to our customers over this timeline, but there wasn’t any way for their team to find them. We were marked with a big “X” – not even a zero, but an “X”.” However, there are two silver linings. First, since prospective customers aren’t using the product and may not understand the significance of each update, their evaluation is binary. “Does the company we’re considering have frequent updates, yes or no?” This means that you can get into the “yes” column by simply showing up. Second, once you establish a reputation for frequent updates, this becomes a potent selling point. Ensure that anyone speaking to leads or trials emphasizes your commitment to frequent updates; it will differentiate you! Though it’s not really my style, if you’re aware of a competitor consistently failing to update their customers, you could use this to your advantage. You always hear stories like “worse product but better marketing, so they won the market.” Frequent customer updates are a big part of that marketing advantage. ### Boosting expansion revenue “As the complexity of a product increases, the proportion of customers familiar with all of its features decreases.” - Sierakowski’s Law. Put another way, the more effort you put into your product, the harder you must work to educate customers about it. If you really want your eyes opened on this I’d recommend conducting synchronous cancellation calls (as opposed to self serve/email cancellation). Simply ask, “Why are you leaving?” and/or “Is there anything we could have done to keep you?” The number of customers who could have been retained had they known about a specific feature – one that you indeed offer – is maddening. This happened to me all the time at Baremetrics: > Me: “I’m so sorry we couldn’t meet your needs. To help us improve our product for future customers, is there anything we could have done to keep your business?” Ex-Customer: “Yeah, no worries, we’ve found a product that works better for us. We would have loved to have stayed but we needed a product that supported custom dashboards.” > > Me: “Oh, wild. We actually do offer custom dashboards!” > > Ex-Customer: “Oh, weird! Haha. We would have stayed if we would have known that.” > > Me: “Yeah, that’s wild you left because you thought we didn’t have that.” > > Ex-Customer: “Yeah, hahaha, wild.” > > Me: “…” > > Ex-Customer: “……” > > Me: “Well, thanks for your time!” This dialogue highlights a significant oversight: the assumption that customers are aware of the entire product. If a customer isn’t using a specific feature we assume they know about it, but just don’t want it. This is particularly true for add-on features, or those that are exclusive to higher-tier plans. With add-ons “out of sight, out of mind” it’s very likely that your customers are simply unaware these features exist. Frequent customer updates can bring these features to light. Below, in the research section, we explore various techniques to maximize expansion revenue through customer updates, including: 1. Finding new ways to talk about add-on features, repeatedly. 2. Clearly stating feature availability, for example, “available to business plan customers and above” or “for users of our commerce hub add-on.” 3. Providing space for persistent reminders, such as, keeping an add-on feature on the “what’s new” page for several months after launch. In short, great customer updates tell your customer when add-on features are available, remind them they exist, and keep those items top of mind when they’re ready to upgrade. ### Setting up for a price increase Price increases are an often inevitable aspect of running a business. Managing a company is challenging, and the likelihood that you nailed your pricing in those early tumultuous days is slim. Even if you were successful in picking the right price, external factors like inflation and internal factors such as expanding expenses are likely to require adjustments. While your expenses in year one were a $5 Heroku dyno and a $7.99/year domain, you might find yourself in year five with a 20-person team, a $160k per month salary expense, an $80k per month cloud bill, and a $7.99 domain. When all other options are exhausted and you realize a price increase is necessary, best practices dictate transparent communication with customers. This involves outlining the forthcoming changes with your customers, emphasizing the improvements made over the past five years in order to justify the increase. 14 seconds after this email goes out you will get a spike of traffic as customers beeline towards whatever list of product updates you have available to decide for themselves. Woe be upon anyone who decided not to frequently update this list. ![Image 2](/images/blog/the-art-of-the-update/person-no-changelog.png) Person who did not update their changelog before emailing customers about a price increase If customers visit the update log and see that there’s only seven updates spread across the past three years–you’re in trouble. I’ve been there. I know the feeling of being so overwhelmed by a massive feature and bug backlog that you devote 100% of the team’s time to tackling it. Know that if you do this you’re opening yourself for a gigantic pain when its price increase season. Now let’s totally change perspective. Imagine yourself as the customer who’s receiving the price increase update email in this scenario. You get the price increase email. It is well-crafted and includes justifications, but you want to see these justifications with your own eyes. You go to the customer update log and scroll back to three years ago, the date when you became a customer. You see how many posts are ahead of you, they’ve done one a week for the past three years, 156 updates since you started paying for the product. You can be annoyed, and you can also determine that the price is just too much for the value you get, but no one can start to make the argument that that company hasn’t been extremely busy, wholly focused on making the product better for their customers. This is the experience we’re looking to create for our customers should we ever need to increase our prices. ### Building Trust Trust is a simple but powerful outcome of frequent updates. People are wary of strangers, but tend to trust those they hear from frequently. In entertainment, for example, viewers of [Twitch streamers often begin to think they’re friends with them](https://en.wikipedia.org/wiki/Parasocial_interaction). My advice is to strive for regular communication without getting your customers to fall in love with you. If you can avoid it. Building trust opens the door to two-way communication, a vital asset. If you’ve ever tried to speak to a customer who hasn’t been contacted in a long time, it can be challenging to get anything back from them at all. It’s a bit shocking when you experience this first hand. Once, after a prolonged silence, I sent a simple three question survey to over 100k active customers, and only received 14 responses. When I ran [TeamPassword](https://teampassword.com/), I sent out similar surveys. Our list was much smaller, but because I was actively in touch with most customers our surveys would get opened by 30% of recipients, completed by 90% of the people who started them, and 50% of the respondents responded “yes” to “may we follow up with you for more information?” When customers hear from you frequently, they’re less likely to think there’s a hidden agenda. They might even reach out to you first, or at least be more receptive when you ask for product feedback, check in with an account review, or casually inquire if a new add-on might be something they’d find useful. ### Earning referrals and testimonials Sending frequent updates starts a conversation. Each customer interaction is a lottery ticket, and the jackpot is them responding: “This is great!” Companies invest significant time and money in obtaining testimonials, reviews, and referrals because these elements are highly valuable, making the effort worthwhile. Having a customer respond to an update positively is the difference between inbound and outbound sales. Occasionally, a customer’s note is comprehensive enough to screenshot it and feature it on your marketing site (with their permission). At other times you might be able to get to that full testimonial with a few follow-up questions. This process is much easier than collecting customer quotes through an outbound approach. With positive sentiment coming in from your customers, referrals and reviews are just an ask away. Great reviews and referrals exist in a funnel; only a small percentage of customers will write a positive note, and only a fraction of those wlll follow through with a testimonial. That’s OK; maintaining open communication is valuable itself. However, I’ve never seen this level of interaction fail to result in referrals and testimonials, so hopefully, that motivates you to keep the updates coming. ## The Research: Examples in the wild By the way—if you’re overwhelmed by trying to write these frequent, churn reducing, upsell inducing customer updates while also running your business… Changebot can do this for you automatically. I scoured the internet through both space and time to find both the best and worst practices, from the fortune 500 to indie hackers. Below is a summary of my research notes so you can see (and draw your own conclusion) about the best customer update practices and tactics. **Researched Companies:** - Slack - Trello - Github - Basecamp - Mailchimp - HubSpot - Baremetrics ### Slack Slack is perhaps THE customer update OG. I decided to jump into the wayback machine to see how they got on the path of solid customer updates. Here’s a fairly typical update from March 2018: ![Image 3](/images/blog/the-art-of-the-update/slack-march-2018.png) ‍ There’s a lot to like here. The updates are **clear** and **concise**, with a lot of links for people who want to read more (hint: basically no one wants to read more.) Being concise is generally preferred by customers, and it’s less work for us to do! Win win. As a matter of style the language matches their brand, ala “Quicker switcheroos,” making the updates feel **relevant**. This doesn’t mean that your updates should be cheeky, in fact it’s a bit cringe when a serious brand tries to be fun, but it is a best practice observed in the best updates to make sure the language you use in the updates matches your brand. Serious updates are fine for serious companies, I don’t want an update from my doctor that my “panky is all inflamoed.” Slack is not afraid to promote **boring updates** which is a rare but powerful strength. One of the reasons why Slack has pages of updates every month is that they’re not afraid to take credit for their work. “Admin can delete private channels” actually sounds like it could have been a bug (or at least an oversight,) but that’s no reason not to share the update. The people who are impacted by this change will be thrilled to read the update, the people who don’t care will skim past. The outcomes for **promoting boring updates** are either excitement that you made the product better for them or basic appreciation that you’re generally making the product better. The only way to lose is to say nothing (which is what most teams do.) Slack is also **not afraid to share bad news** in updates, consider this note from the may 2018 update: ![Image 4](/images/blog/the-art-of-the-update/slack-bad-news.png) If you don’t remember this was a big deal at the time, and people were pretty upset! Slack had the option to put this update outside of the normal stream, or, not say anything at all. But including this bad news allowed them to get ahead of the conversation by explaining their reasoning, and heading off the biggest area of real concern: accessibility. As a running theme, turning things off and removing features is also work, so if you truly have the conviction that this is best for your customer or your business, take credit for that work too. Removing IRC gateways from Slack infuriated many nerds at the time, but I’m willing to bet exactly zero people remember this, and they seem to have done pretty well subsequently. Slack also excels by having a persistent location to keep track of wins **on a schedule**. When you visit their releases page (< [https://slack.com/releases](https://slack.com/releases)\>) they show the latest product updates chronologically, but support their biggest customer benefits directly below: ‍ ![Image 5](/images/blog/the-art-of-the-update/slack-releases-page.png) Because our goal is to have frequent updates we can’t be sure that our most recent updates cover all of the major benefits we provide to customers. Having a hard-coded benefits section in the same place where a potential customer might review product updates ensures that you have your bases covered, it’s the multi-vitamin of benefits focused language. While I think basically everyone could do a better job at connecting the dots from feature releases to customer benefit, having a relatively static section like the one above makes sure you always have a foundation to work off of. ### Trello Instead of focusing on individual releases Trello tends to **keep their schedule** by rolling up posts which feature new improvements alongside old improvements. While this can make it difficult to see what’s new at a glance, it has the intended effect of seeing a large number of what seem like very large features every time you visit the product page on their blog. Trello shows off a powerful technique, featuring popular posts, at the top of their product page: ![Image 6](/images/blog/the-art-of-the-update/trello-popular-posts.png) They still have posts sorted by most recent below, however having popular posts up top make sure that everyone visiting this page is always hit by the “best of.” This is particularly powerful for prospects, Trello puts their best foot forward **in public** for any potential customers considering the product. Let’s do a deeper dive on the “ [Advanced Checklists](https://www.atlassian.com/blog/trello/advanced-checklists)” roll up post. It’s clear Trello’s goal is to be comprehensive. Because they’re bringing up different checklist use cases and all the associated features they provide a very three dimensional view on what it’s like using checklists in Trello. This also has the added benefit of making the post customer focused since it only exists to help their customers make their way around this feature set, supported by **customer quotes**. I also love their strategy of **adding clarity** by focusing on a specific user type. I barely use checklists in Trello, I’d skip this post. Knowing that only the diehard checklist users will be reading the post allows them to go deep into the topic, spending more time going deep into the specifics: ![Image 7](/images/blog/the-art-of-the-update/trello-streamline-checklist.png) If your goal is to get every update out to every customer you have to appreciate that most users are not going to geek out over a niche feature like checklist task automations. Focusing on a specific user type lets you go deep, presenting each nuance in full detail. A hugely winning strategy from this section is including **customer quotes**. Having a quote from a customer means two things. First, the feature being described actually solved a real problem in the world. Second, it proves that someone cares enough to write a quote. The more you can defer to **customer quotes** the better, they’re the ones that matter. And it might even be less work for you if they proactively write the quote… but more often than not you’ll need to craft or edit the quote as they did (spy the usage of …’s in their quotes.) I have no evidence, but I suspect that this quote was either cherry picked or co-created given the inclusion of the last line “X feature has been the biggest upgrade to Trello for me in a long time.” I’d guess that one of the major reasons for churn and general customer satisfaction is that “Trello hasn’t been upgraded in forever.” This quote arms the team with a bit of backup against that point. Lightning round: - They **build clarity** via a modified bottom line up front, they’re super clear on what makes them “advanced checklists” at the beginning of the article. - **Great “you” language**. For example “view all of your work in one place” and “Get more done by changing your POV.” - They feature both **being precise** and highlight **specific benefits** by specifying who gets access to what feature. Trello has a large number of different plans, they include inline which plan gets which feature. - They dip into **being multimedia** and **increase clarity** by providing plentiful product pictures which pervade the post. Trello’s approach is great to wow current and potential customers who visit the product updates page. Everything is so well crafted and deliberate. That obviously comes at the cost of needing to spend a good amount of time and effort writing these posts. There’s also the question of style, this post begins with a quote from the book “The Checklist Manifesto.” I personally don’t think that’s words well spent, serving as a counter example of **being concise** and **relevant**. If the person is digging into a 5 minute read on your checklist features I think this space would be much better used **including the benefit** by explaining how much time or money is made / saved using great checklists. The **benefit** in the form of a business bottom line is implied, but they never take the last step. I’ll give two examples: ![Image 8](/images/blog/the-art-of-the-update/trello-replicate-checklists.png) Here we’re presenting the feature of being able to copy / paste checklists. They broach the topic: “create them, save them (same thing), and use them repeatedly to decrease your workload” but I’d love to **take the last step to a benefit**, how much time? And I’ll bet businesses get other **benefits**like accuracy—how many times have you created a checklist for a new project and left out a critical step? The best case result is that you’re embarrassed, the worst case result is losing a customer. Use advanced checklists, save time, save customers, stay cool. Coca cola. One more example: ![Image 9](/images/blog/the-art-of-the-update/trello-view-all-work.png) ‍ This is SO CLOSE. We have an easy to understand feature and a **raving customer quote**. Just take the extra moment to be like “what was the cost of not having all these tasks in one place?” What **direct benefit** do I get as a customer by using this feature? Beyond just being frustrating I’ll bet the customer spent way more time getting through their checklists, slowing down production and billable hours, especially if a critical task waiting for their approval sits in limbo. There’s clearly a **benefit to the business** that could have been promoted. ### Github ![Image 10](/images/blog/the-art-of-the-update/github-developer-quote.png) As you can see this is a serious quote, two full paragraphs from a very senior engineer at Github, with a specific real world scenario. Since Github sells to and is used by engineers, this stands in for a customer quote in a pretty compelling way. Of the 1,000 words in the update, almost 600 are directly from their developers. This is specifically a good approach for Github, but also generally good to get a quote from your development team. One benefit in frequent, detailed customer updates is building trust. It’s really hard to trust someone you never hear from, and hearing directly from the development team further builds that trust. It’s like when the chef of a fancy restaurant comes out to talk to you. Github also **embraces being multimedia** by including a video of the update as well since this was announced at their conference, they smartly included a 10 minute clip during the announcement: ![Image 11](/images/blog/the-art-of-the-update/github-video-clip.png) While adding a considerable amount of work to the update, I do like providing the option for the people who prefer video, and for the distribution. This video is on YouTube with 81k views, and comments are open allowing them to get messages like this: ![Image 12](/images/blog/the-art-of-the-update/github-youtube-comment.png) They could farm these comments for **customer quotes**, and since it’s YouTube there’s also plenty of complaints they could use to make some improvements. A few final notes on Github: - When talking about tech they **increase clarity** by addressing the common questions up front. For example, they specify that copilot chat is powered by GPT-4, which is a phrase likely everyone who’s familiar with copilot will understand, and, one that most people would be happy with. (of course with consideration to the wide array of opinions on AI technologies, no one is happy about everything.) - Outside of this one post Github is **on a schedule**, constantly updating their blog with product updates and developments from the field, averaging 3-4 updates a month! - I was surprised they weren’t explicit on **customer benefits**, AI tools for developers are prime to say “your company will save X money, Y time, and get through your backlog X00% faster.” They hit on it in the video “Even adding a small feature can take hours out of your day.” This last point of not taking the final step to **customer benefit** is extremely common and drives me a bit crazy. I think to myself as companies release feature updates “what was the point of building this? How does this make our business stronger? Why are we here?” Perhaps Github specifically avoids this language because developers hate being “sold” to, but there’s plenty of room for Github to walk up to that line. ### Basecamp Basecamp has made a name for themselves by constantly innovating on “the format” (for whichever “format” you can imagine.) The way that they provide customer updates is no different. They don’t really do product updates in the way that we can compare apples to apples, but they do so much right that I wanted to include their approach in my research anyway. To start, they have a **public** page fotemr all their features, [https://basecamp.com/features](https://basecamp.com/features), which includes an intelligently organized and prioritized set of features, interspersed with customer testimonials: ![Image 13](/images/blog/the-art-of-the-update/basecamp-features-hero.png) Lots to love here, the copy is **clear** and **concise** (“project management’s greatest hits”,) **multimedia** via large product screenshots, and each link takes you to a larger, sometimes annotated screenshots: ![Image 14](/images/blog/the-art-of-the-update/basecamp-annotated-screenshot.png) Beautiful drop shadow courtesy of Basecamp. The closest thing Basecamp has to a traditional changelog of customer updates is their “new” page, [https://basecamp.com/new](https://basecamp.com/new), which features large, beautiful, annotated screenshots of all the updates Basecamp has made over the past year: ![Image 15](/images/blog/the-art-of-the-update/basecamp-new-2024.png) This is a fairly brilliant approach, instead of posting constant feature updates, they’ve created a structure where every time you want to see what features are new, they get to take credit for all feature development over the past year. I wish I would have taken a screenshot when this was “NEW for 2023,” but I think that this is the overall feature recap for their newest version of Basecamp (“Basecamp 4.”) Since there’s no timestamping the reader is free to infer whatever they want, and one of those readings would be “this is all new functionality as of 2024.” This is probably the best optimized page I’ve reviewed so far at giving a prospective customer that sense of wow that Basecamp is really turning out meaningful product improvements quickly. There’s not much more here that conforms to the rest of my research such that I can categorize their approach into categories, other than to say that they’ve done something very cool, that very much works for 37signals, and perhaps has some transferable principles for the rest of us. I can see two downsides to this approach, first there’s a lot more room to be more clear about **customer benefits** on each feature, and second this approach loses the sense of **schedule** for people to be able to stay up to speed with the latest feature. The first note is a recurring theme, my position is that basically everyone can do a better job of connecting that last step to **customer benefits**. For example, Basecamp says the following about their _todo lists on their features page:_ ![Image 16](/images/blog/the-art-of-the-update/basecamp-todos.png) _‍_‍ _‍_ This copy is super strong (I tried to pick a good one!) but I’m not sure that “sleep well knowing it’ll get done” walks us all the way to the **benefit**. Perhaps I picked too good of an example, but I imagine that small businesses lose tons of time, money, reputation, and customers all to the root cause of balls getting dropped. With a project management tool I’d love to see the impact on project completion with this and every other feature, presenting some version of products getting done more quickly with fewer people with happier customers seems like a direct way to let these features speak to how they **benefit** the bottom line. On the second point (not establishing a **schedule**): they also don’t post to a Basecamp twitter account instead favoring their 37signals account. This provides some cool upside that they can post about features that tie all of their products together, but if you’re considering buying basecamp and want to see what the last three months has looked like from a development perspective, it might be hard to figure that out. It’s easy to imagine they’ve tested this and realized that they can put all the week over week effort they’d put into having regular customer updates and spend that time once on a polished, beautiful, descriptive page that they only need to update once a major release. Given how unique and beautiful the combination of the “features” and “new” pages are it’s hard to argue with the overall effect they’ve created, and it’s just as challenging to recommend emulating. It’s uniquely 37signals in style and substance, which prompts the question: what’s the “uniquely you” way to keep your customers in the loop? ### Mailchimp Mailchimp runs some of the greatest hits that we’ve seen so far while also adding a few extra bananas. We’ll start with their big, beautiful “What’s new” page which serves as their entry point to learn about their product updates: ![Image 17](/images/blog/the-art-of-the-update/mailchimp-whats-new.png) The button labeled “Try new features now” takes you right to the login page: ![Image 18](/images/blog/the-art-of-the-update/mailchimp-login.png) ‍ This got a laugh out of me the first time I clicked it. My expectation was that I’d get more details on new features… but they’re right! I’m not sure what I expected, but if I want to “try new features now” logging in would be the way to do it. Perhaps eclipsing that was my experience on clicking on the following CTA for “Draft emails with AI”: ![Image 19](/images/blog/the-art-of-the-update/mailchimp-personalized-emails.png) Guess where the “Draft emails with AI” button goes? Did you guess… the pricing page? ![Image 20](/images/blog/the-art-of-the-update/mailchimp-pricing.png) Researching Mailchimp reset my thought process on being direct and conversion optimized. Why was it my expectation that there should be steps in between “here is the feature” and just straight up using the feature, either by logging in or signing up. If Mailchimp, a marketing automation company with near infinite incentive to create marketing content funnels you right to the login / sign up page, we should take notice. Mailchimp’s “what’s new” page also features (haha) a few other great **multimedia** touches: - Large, well designed screenshots - A video overview for the entire page - A lot of **“you” language**, like “Respond to customer and client inquiries 1-to-1 in your Mailchimp Inbox” and “Let AI help generate emails and automations to welcome new customers, recover abandoned carts, and promote new products. You only need to review and send!” One tactic that I’m not sure about is “Coming Soon” features: ![Image 21](/images/blog/the-art-of-the-update/mailchimp-coming-soon.png) Of the nine feature headers on the What’s New page, three of them are marked as coming soon. My personal preference would be zero. Showing coming soon is a double edged sword. It’s great that they’re providing a public view into the roadmap, however, trying to sell more than what’s in the product today can lead to heartbreak (when someone inevitably doesn’t read the “coming soon” part), or can cause people to second guess—should I wait until they have this new feature I really want now that I read it? Should I see if any of their competitors have this feature that I can use today? This needs more research but my assumption is that very few people will say “there’s more features being added eventually? I’ll sign up today!” Switching gears, let’s take a look at a more traditional product update, this is Mailchimp’s fall release 2020 update. I’m a big fan of the comprehensive update style, I especially like the **multimedia** style with a video up top which supports the detailed sections below: ![Image 22](/images/blog/the-art-of-the-update/mailchimp-fall-2020-update.png) This is a nine minute video featuring their chief product officer and other execs within the company, showing how important customer updates are to them. This is perhaps one of the strongest examples of a company showing through effort and attendance that the product updates the company is pushing is front and center to the leadership team. The video also covers a rare product update tenant, which is covering the why behind these new features. This gets bonus points because it’s also directly adjacent to what business **benefit** a customer would get from using the new features. Mailchimp’s overall goal is to make your marketing more effective, which provides a direct path for potential customers to understand how using Mailchimp makes you more money. The video also speaks to their different user types between small business owners, marketers, and developers. Each of the feature sections have some great **“you” language** in addition to links which take you to more details on each feature (which was my initial expectation on the What’s New page): ![Image 23](/images/blog/the-art-of-the-update/mailchimp-creative-assistant.png) Overall a strong update. Light on specific **customer benefits** (how does this make us more money, how much more money does this make us?), but provides a concise description of what the company built and how it’s used by customers, usually with an accompanying screenshot. In all my research I’ve been left wanting for more focus on the business impact of feature development, but their video is as close to being direct on this point as I’ve seen. ### HubSpot HubSpot has been credited with inventing (or at least popularizing (but I think they invented)) content marketing, and as such their website includes thousands of tactical posts ranging from how-to content, basic 101 style content, advanced tips, and of course product specific items. ![Image 24](/images/blog/the-art-of-the-update/hubspot-invented.png) Did HubSpot invented the flywheel? ‍ HubSpot’s customer updates start with their “ [what’s new](https://www.hubspot.com/new)” page which shows (what appears to be) a chronological recap of their most recent three major features. ![Image 25](/images/blog/the-art-of-the-update/hubspot-whats-new.png) I love the layout they’ve used. Focusing on three major updates helps focus the current or potential customer coming to this page. Breaking each feature down into a title, short description, screenshot, long description, and a “learn more” link is a fantastic structure which we’ll come back around to in our templates section. The overall effect is impressive, but, this is not an overwhelming amount of work for each feature release, finding that beautiful middle ground of impressive looking, fast and easy to do, and highly converting. It’s unclear why “TikTok Integration” is a different color and adorned with sparkles. I’m guessing that this is their way of having a main or featured update of the three. Feels like overkill to me unless these are truly the three most recent updates and not curated. Three is curated enough! One other note of interest: two of the three items (Webflow and TikTok) are integrations! They have no fear of promoting **the “boring” stuff**. It also seems that the Webflow app is in the Hubspot app marketplace, meaning the Webflow team built it. This is a challenging play to recreate, but if you can ever find a way to get another business to build on top of your product, you promoting that work is win/win. The company who built the integration gets eyes to the addon / app / content they created, you get the benefit of whatever they built plus customer update credit. CommerceHub, the third “what’s new” item, is the newest “hub” in HubSpot. If you’re not familiar with HubSpot the way they’ve decided to keep a sense of sanity while trying to build around every department is breaking the product up into “hubs”. The most popular hub is the marketing hub, which does all the stuff you probably think of HubSpot to do, landing pages and campaigns and whatnot. They also have a sales hub which is their CRM. This lesson on HubSpot to underscore that a new hub is not a small amount of work, my outsider analysis is that the structure of the what’s new page might be one feature a “partner” has created, one feature that we’ve created, and then the most recent hub or other major section of the app we want to push. It’s unlikely that this is one of the most recent features they’ve pushed because it’s quite a bit larger than a feature (ie, there’s lots of functionality within the commerce hub that could be promoted,) and that they were doing events around commerce hub ~4 months prior. Unrelated, here’s a screenshot that I found researching commerce hub that I think everyone who’s ever spoken to a customer will feel: ![Image 26](/images/blog/the-art-of-the-update/hubspot-simple-feature.png) Yes HubSpot, when will this _simple_ feature be added? Hubs are also a source of expansion revenue, so that could be a part of the analysis of how they construct their ‘what’s new’ list. Below the fold is the “what’s new” section there’s a section for “release materials” where we can dive into a traditional customer product update. ![Image 27](/images/blog/the-art-of-the-update/hubspot-release-materials.png) For further analysis we’ll dive into the “ [November 2023 Release Notes.](https://community.hubspot.com/t5/Releases-and-Updates/November-2023-Release-Notes/ba-p/888758?_gl=1*vj2k5v*_ga*MzQxODcwOTc1LjE3MDI0OTMyMTk.*_ga_LXTM6CQ0XK*MTcwNDI0NTQ0NS4yMS4xLjE3MDQyNDU1NzIuNjAuMC4w)” Off the bat the list of changes is huge. I count **43** updates across 12 sections (mostly organized by hubs, but some that fall outside like mobile, app marketplace, and multi-hub updates.) This happens on **schedule** every month, so the impact snowballs over time. If you’re trying to wow a customer or a prospect to show that your team is hard at work improving the product, 43 updates a month, every month is a great place to start. Hypothetically if you’re frustrated that Hubspot hasn’t added 28 day billing cycles to the commerce hub? Well, it’s not like they aren’t doing anything! Even though that’s a simple feature request… How do they get so many updates? They don’t ignore **boring updates**. They do a good job of providing a **concise** update on each new feature, and since HubSpot has many plan tiers they’re explicit about who gets access to which new feature. On the downside.. This list doesn’t feel prioritized and isn’t written with **“you” language**. For example, this is the first update: “HubSpot has rolled out an update to our integration with Facebook’s Conversions API. The Conversions API is designed to create a direct connection between your marketing data and the systems which help optimize ad targeting, decrease cost per action and measure results across Meta technologies.” A good start would be to flip this, start with the fact that this new feature will help you decrease your cost per action while being able to better measure results—get more customers for less money with more confidence! This brings the **benefit** up front while also using **“you” language**. With the update being this long they definitely could have gotten many more updates, and perhaps have separate places to see those updates. The video is really great—great energy. Super strong way to be **multimedia**. However, the list of features discussed is different from the post. And we’re still not **talking benefits**. The first update discussed is conditional properties, which allows customers to filter one set of attributes based on the selection of another property, the example they gave is that if you set a customers country to Canada, the property “state/province” will automatically be set to just Canada. This is really cool! But, I think it’d cut through just a bit better if they explained a bit of **business value**… what was the problem that got them to build that feature? I’m sure HubSpot customers lose TONS of money because of incorrect CRM data! Overall Hubspot has found a great blend of highlighting their best “recent” updates (even if it’s a few months old) while supporting those cornerstone updates with a HUGE list of monthly updates, presented with text and video. ### Baremetrics Baremetrics is a saas finance analytics platform best known for having a very handsome CEO from mid 2020 through mid 2023. Secondary to that Josh Pigford, the founder of Baremetrics invented a number of tactics we see used, abused, and debated over today. The main principle we see carried through is the idea of radical transparency, sharing not just roadmap items, not just feature updates, but the entire state of the business, which includes both the ups and the downs and the specific financial details of the business. This makes a bit of sense when you’ve built a platform to show MRR, new customers, churn rate, etc, but I don’t think most people would say “hey… lets share all this info with the world.” Nerds continue to debate if this is a good idea to this date, but Baremetrics needs to be included in our analysis of what a great customer update looks like. We’ll take a look at an early product focused customer update, and then for fun we’ll look at a transparency focused customer update. Let’s start with [Baremetrics, New Feature: Customer Profiles](https://baremetrics.com/blog/new-feature-customer-profiles). ![Image 28](/images/blog/the-art-of-the-update/baremetrics-customer-profiles.png) Screenshot courtesy of the Wayback Machine This is one of the oldest feature updates from Baremetrics, dated almost 10 years ago. Despite its age we see all the critical pieces of a great customer update. The update is hyper **concise**, providing an exact screenshot and a clear description of what features are being added: ![Image 29](/images/blog/the-art-of-the-update/baremetrics-feature-description.png) Just two sentences to completely cover an entire new section of the product: 1. Each customer gets their own individual profile showing you that customer’s individual LTV and MRR along with social and location information. 2. In addition, you can view the entire transaction history of that customer from signup to charges to failed charges and cancellation.” They also do a great job of providing further examples without being prescriptive: ![Image 30](/images/blog/the-art-of-the-update/baremetrics-usage-examples.png) The pattern of showing real world use is fantastic. This is best by **taking quotes directly from customers**, but that takes time and effort, and our goal is to get meaningful updates out the door quickly and easily. Using a quote from an internal team member or “the company” instead can provide real world usage examples while getting the update out quickly. To nitpick a customer update from 10 years ago, I’d focus on two things: First, the update has a lot of “we” language, talking about Baremetrics both as the creator of the feature and the user of the feature. If you’re reading in order you’ll know that my goal is to include as much **“you” language** as possible, focusing on the problems your customers are experiencing, and how much benefit they get out of using the feature. Second, the update doesn’t take the last step to **business value**. For example from the opening paragraph: “Baremetrics has largely taken a high-level approach to your metrics, showing you a 40,000-foot view of how your business is doing financially. Today, we’re bringing that view much closer and making it much more personal.” Why are we doing that? What issues prompted Baremetrics to make this feature? And to what business impact? In my research the golden formula for a feature like this is \[the problem customers had that made us make it\], \[what we did\], \[business impacts of that feature.\] For example, If I were to rewrite the opening to the update with these two points in mind, it might look something like: > “As a customer of Baremetrics you’ve already been able to see the high level effects of business changes on your metrics, like what a change in pricing does to ARPU or what impact a new feature has on retention. But, we’ve heard from our customers that not every change is so clear from the high level, what happens at the individual customer level has a huge impact on our ability to effectively pilot our business. > > So today I’m happy to announce customer profiles, the ground level truth on each and every one of your customers, making sure that as you make changes to boost new revenue, create more expansion revenue, and decrease churn that you can track the impact of those changes down to a user level. > > Anecdotally with the additional information gained from customer profiles we were able to troubleshoot why a specific type of customer left Baremetrics, improving our churn by .5% which will add up to a six figure impact by the end of the year. And it’s just month one!” Something like that. I understand that it’s about 250% larger than the original text, but it’s sort of my move to increase Baremetrics’ things by 250%. The point is that we start with a business problem, we discuss quickly how we solved it, then we finish with outcomes. We should use as much **“you” language** as possible in order to help current and potential customers visualize what giving us a few bucks will yield to them in return. As an extra bonus, let’s take a look at the most popular blog post Baremetrics had during my tenure: [I Sold Baremetrics](https://baremetrics.com/blog/i-sold-baremetrics). ![Image 31](/images/blog/the-art-of-the-update/baremetrics-sold.png) Since this isn’t a traditional product focused customer update I’ll keep it short here (says the dude writing 10k words on customer updates.) A few highlights: - This post is an example of a great way to provide a major customer update, quickly, in a way that they’ll understand. - He’s very clear on the specifics, including the information that everyone wants to know (eg, how much??) - For a potential bombshell he provides the bottom line up front: I’ve been building this thing for 7 years, I’m selling the business. Also… the title is “I sold Baremetrics.” - The post tells the story in a very honest way (eg “this rollercoaster reminded me of all the things I don’t love about running a company.”) - He also includes “the future of Baremetrics”, which in keeping with the theme of this article is the “you” language people will most want to hear (after the acquisition number) ### Reference companies without complete research I used (quite a few) more companies in my research, here’s a short list of a few of the other companies referenced. If there’s interest and requests I’ll happily release another round of research with best practices. Here’s that list: - WP Engine, see “ [WP Engine eCommerce Hosting—Now With Stripe Connect!](https://wpengine.com/blog/stripe-connect-integration/)” - [Signwell](https://www.signwell.com/) - [Dingboard](https://dingboard.com/) (great example of updates integrated into the product) - [Intercom](https://www.intercom.com/) - [Transistor](https://transistor.fm/) - [SendSpark](https://www.sendspark.com/) - [Notion](https://www.notion.so/releases) - [Sprout Social](https://support.sproutsocial.com/hc/en-us/articles/360049505551-Release-Notes) - [OpenAI](https://platform.openai.com/docs/changelog) - [CleanShot](https://cleanshot.com/) ## Act 3, The Science of great updates By the way—if you’re overwhelmed by trying to write these frequent, churn reducing, upsell inducing customer updates while also running your business… Changebot can do this for you automatically. Through matrix multiplication of our research set we can generalize a set of rules for our customer updates. There are two sets of lessons to learn. First, **how can we create more customer updates?** The goal is to fill the changelog with useful, interesting updates, thus reminding our customers of our hard work and fostering dialogue. Second, **how can we improve the quality of these updates?** We want to identify the characteristics that the best updates use to _efficiently_ communicate product improvements. The goal is to increase the frequency of updates without spending more time on them than the product improvements themselves. As a reminder, achieving these two goals helps our business by: - Preventing churn - Increasing new customers - Boosting expansion revenue - Setting up for a price increase - Building trust - Earning referrals and testimonials (If you need more convincing on that, re-read the “Why should we?” section.) In order to get all these benefits for our business, we need to frequently ship great customer updates. Here’s how: The principles of more updates: 1. Being on schedule 2. Being public 3. Being concise 4. Including the “boring” stuff 5. Including the “bad” news 6. Being relevant The principles of better updates: 1. Using “you” language 2. Being multimedia 3. Including customer quotes 4. Being clear 5. Including the benefit _(+ a few bonus tips)_ ### The principles of more updates Put simply, most companies do not update their customers enough. The 40th-percentile company doesn’t update their customers at all. Providing any form of regular customer updates places you in the top half of companies, akin to the way any return on investment positions a VC in the upper echelons. Consider our earlier tweet about investor updates: ![Image 32](/images/blog/the-art-of-the-update/twitter-investor-update.png) To directly apply it to our domain - Updates only when there’s a big issue = mediocre business - No updates = 90% chance of death - Short updates w/ customer benefits = business will succeed With this in mind our research identified several techniques used by companies successful in maintaining a high velocity of updates. #### Being on Schedule In a high-velocity update environment every decision to publish an update can feel like hitting the brakes. Figuring out the perfect timing for sharing news is a double-edged sword. On one hand, you’re caught up thinking about the best time to drop an update, which eats into the actual time you could be polishing the announcement. On the other hand, you’re chasing down all the dependencies, like the details of the new feature that’s shipping, customer testimonials, or the perfect screenshot. Scrambling for these details last-minute when you’re supposed to go live is not ideal. Here’s where a little planning goes a long way. Sketching out a timeline in your head – or a mental Gantt chart, if you will – helps ensure you’ve got everything ready for launch day. . Plus, sticking to a schedule can actually sharpen your updates, making them tighter and more focused. Think of it as borrowing a page from the agile playbook: we tailor our updates to fit the time we’ve got. Finally, having a schedule gets you into a rhythm. I swear to you as the person who’s writing thousands of words about customer updates, I would have PROMISED you that I was doing updates every two to three weeks for a product I was building. I would have made an oath to you that was the case. I would have bet a significant amount of my net worth that I was sticking to that timeline. But here’s how it actually went down: ![Image 33](/images/blog/the-art-of-the-update/twitter-updates.png) The timeline was: - Aug 24th, Initial intro video - Aug 28th, got my blue belt (unrelated, but pretty cool) - Sept 18th, update one - Oct 25th, update two - Jan 2nd, update three Since my schedule was “when I felt like it” I sent four updates over six months. This turned out to be almost one update a month, with updates coming almost at the end of every month. Which, in hindsight, sounds like a reasonable plan! But the reality was more hit or miss, with updates being published inconsistently throughout the month, or, sometimes not at all. Now that I’ve researched customer update best practices I’d handle the scheduling of these updates much differently. The main change I would make is setting a schedule to publish an update every two weeks. This is how frequently I thought I was publishing updates before I checked, and the difference in frequency is stark. Sprout Social is another great example. They include a [monthly view of their product updates](https://support.sproutsocial.com/hc/en-us/categories/360003280092-Latest-Updates), and a [day by day drill down view](https://support.sproutsocial.com/hc/en-us/articles/21868530419085-December-2023). I love the commitment to show updates on a monthly cadence, but also keep track of the daily view. This shows a huge internal focus on customer communication – and on shipping! You can’t document thirteen updates in the month of December without product updates being a priority. #### Being public An interesting finding from my research was that many companies didn’t do any sort of regular updates. Some were in the habit of weaving product updates into their main blog (totally fine,) but others ONLY published product updates to internal customers, either through in app banners, embedded widgets, or just via a customer only email list. There’s two reasons this happens. First, they make the assumption that only current customers care. Rationally, if they’re announcing a certain feature is faster, or some bug is fixed, if you’re not currently using the product why would you care? The potential customer has no basis for comparison, and probably doesn’t even know why it’s important that something is fast or that that bug is fixed. “Why tell someone that something is better or fixed when they have no basis of comparison?” they ask. Second, there’s a self esteem issue. Companies, especially early stage companies, can be embarrassed they had the issue in the first place. For example, if they improved the performance of some key feature, they think “that means it was too slow in the first place.” A fixed bug promotes the fact that they had the bug in the first place. This is of course true. These companies are not dumb, announcing that a bug is fixed may alert people unaware that the bug existed. This doesn’t mean the company is not completely irrational. They’re just a bit socially awkward :). To address this directly: every product has bugs. Every team ships software that needs to be improved. Most products are more wrong than right at launch. The difference between you and the rest of these losers is that your team is putting the hard work in to flip the ratio from mostly wrong to mostly right. A customer who is a normal functioning member of society will be glad to see that the product is faster. They’ll be happy to see that bugs are being fixed, especially if they were affected by it. We’re also hyperfocusing on the updates that potentially could be seen as bad things. We also ship improvements! New features! Super powers! There’s an art to sharing updates with customers that might not be immediately seen as positive, especially by including the benefit (read more below, I promise there’s examples of how to turn what seem like bugs into updates customers will love to read.) You also need to accept that some dissatisfied customers will respond negatively to any update. If you build a feature other than the one they want, they will complain. If you fix a bug that’s not their main bug, they will complain. If you fix an issue that was their biggest concern… they will complain that you didn’t do it sooner! These are the loudest voices, and I can see why if you’re not committed to customer updates why this immediate negative interaction would scare you off. Keeping the long term view and understanding the benefits of having your updates be public will help you weather the storm. To summarize, one of the key reasons to do frequent, well written customer updates is to increase the number of new customers you get. If you don’t share these updates publicly, you’re not getting credit for the hard work your team is putting into the product, and you’re not even getting credit for the hard work you’re doing on writing the customer updates. To be totally binary, if you aren’t sharing customer updates publicly there’s no way to get marketing and sales lift out of customer updates, meaning you get zero new customers from these efforts. Great examples of being public include… literally every company researched in this article. Sorry, it’s really a very good principle, if your updates aren’t public I’d sort of recommend you do so. Just for form I’ll give a shout out to Github for the publicness of their updates because they also include internal engineer quotes in their updates, giving further insight into their thought process, and to OpenAI for including both a weekly view into their platform changes AND a look into their internal politics (remember that one time that Sam Altman got kicked out of the company? That was crazy.) #### Being concise The strongest weapon in the “more updates” arsenal is being concise. I fully appreciate the irony of this advice in this delivery mechanism. As people who are focused on their craft we feel the urge to create lasting structures. This often means providing context through related information, teaching through other examples, and the creation of a meta narrative—making our updates into episodes of the series that is our company. I CLEARLY get that. And, if you can do all of the above while sending customer updates on a weekly basis, go for it. But if you can’t do both, we’ve seen the best of the best strip out the pretense and send simple updates on a regular basis. Here’s why that extra context might be fluff. First off, only a small percent of people will fully read an update. A potential customer might not read the updates AT ALL, but instead just look for the number of updates to answer “is this product maintained?” Second, the people who do read it probably don’t need context. See “keep it relevant” below for more on this. For now just trust me. There is some value in reminding people about benefits, we’ll talk about that in including the benefit, but do an internal audit and ask “is this fluff?” If the answer is yes, congrats, you found an opportunity for efficiency. Look at the updates from HubSpot, Sprout Social, and Open AI. HubSpot: ![Image 34](/images/blog/the-art-of-the-update/hubspot-changelog.png) ‍ Sprout Social: ![Image 35](/images/blog/the-art-of-the-update/sprout-social-updates.png) ‍ OpenAI: ![Image 36](/images/blog/the-art-of-the-update/openai-changelog.png) ‍ Simple ships. #### Including the “boring” stuff The leading reason that companies don’t frequently update their customers is the idea that they didn’t do anything interesting. This is a similar mentality of not **being public**. It’s lacking that touch of confidence that if you decided to work on it, it’s important enough to talk about. If you introspect and realize that truly no one cares and no one benefits from the things you’re working on then it’s truly a remarkable result of forcing customer updates that you make better use of your time! In reality it’s hard for an improvement that customers experience to be too small to write about. Perhaps bumping your ruby version from 3.1.0 up to 3.2.2 might not be noteworthy\*, but even the small bug fixes and minor improvements are noteworthy. The goal is to show a constant pulse, the heartbeat of our product. **We should take credit for all our work.** (\* however, updating to this version of ruby fixed a few security issues, closed dozens of bugs, improved performance, and provided new language features for the team to use… sounds pretty material to me! So if a Ruby version bump feels noteworthy, whatever small improvement you made is too.) Then the question is, how can we make these boring updates newsworthy? First, I just told you they’re not actually boring. Stop that. When Slack wrote in their update “Admins can delete private channels”, do you think they were thinking “oh, this is too boring to include.” Wrong. This stuff matters to our customers, and even if the user reading the update isn’t specifically impacted they will take note that things are getting fixed, and that’s a good thing. Second, we strip down some of the boredom by choosing our words correctly. This requires us to move past step one and believe internally that this is an interesting update, and in that case “Fixed crappy slow code” becomes “Improved speed for customers, you should find (activity X) to be much quicker, getting you to (benefit) faster than ever before.” **BORING\*\***❌\* **\*Good update ✅** Channel switch feature works correctly The Quick Switcher got a makeover. It’s quicker and sleeker. And now it helps you switch between channels in other workspaces. Fixed filter persistence Improved reliability when switching between views. We’ll no longer forget your filtered settings as you travel from page to page, making it faster to get from idea to insight. Apple integration works We know how important it is to get accurate reporting from Apple. We’ve added several layers of checks and have rolled out a new data collection method in order to make sure that when you view your Apple data it’s MORE correct than what you’d get directly from them. I’ve had this conversation many times. Teams don’t want to announce bug fixes, especially if the bug has been around for a while, because you feel like you’re drawing attention to the bug. First off, not looking at the bug does not make the bug go away. Secondly, your customers know about the bug, they reported it. Lastly, they’ll be happy to see it gone! A great example of boring done right are the updates included from our Slack research, followed by HubSpot. You will be amazed what impact a positive attitude, a bit of copywriting, and a deadline will do for your ability to ship tons and tons of customer updates. #### Including the bad news Similar to not including “boring” updates, many companies will shy away from what they think will be received as bad news. A great example of this from the research is Slack dropping support for IRC and XMPP: ![Image 37](/images/blog/the-art-of-the-update/slack-bad-news.png) You might not remember this happening, but at the time it was a BIG deal. People were pretty upset! Slack had the option to put this update outside of the normal stream, or, not say anything at all. But instead they looked at the issue, evaluated their options, made a decision, and then faced it head on. Not only did they make the decision, but the language in their update is unequivocal: the gateways are now closed. There’s no way to read that and not know that it’s GG for IRC. Including this bad news in their standard updates allowed them to get ahead of the conversation by explaining their reasoning (can’t support our features), and allowed them to head off the biggest area of real concern: accessibility. A lot of time we think of our product as a collection of lines of code, collected in a repository and deployed to a server. However our product is much more than that. It’s our goals, it’s the way that we think the world should be, it’s the research we collect, it’s the taste of the people making the product, and as a result it’s the collection of decisions we make as a team. We agonize over these decisions internally, these choices ARE the work, and you should get credit for your work. Here’s a bit from Jason Fried to increase confidence in your judgment: ![Image 38](/images/blog/the-art-of-the-update/jason-fried-judgment.png) ‍ Keep it relevant Writing fewer things is faster than writing more things. Irrelevant information is a thing that requires writing. Therefore, Socrates is a dog. Generally it’s not the goal of the writer to provide irrelevant information (and yet we do.) Generally this is packaged in the format of wanting to provide more context or additional examples. There was some class we all took that taught us that we need to provide three examples for everything, and that’s generally what we tend to do in a business context. However, the strongest updates are just the distilled essence of what benefit the customer is getting, including some AMAZING one line customer updates. As an example, the Trello update for the “advanced checklists” feature set has a quote from The Checklist Manifesto on why checklists are important. This is a great book that I recommend reading, but do we really think that the people who are likely to be interested in “advanced checklists” don’t already know why they’re important? Quantity has its own quality. If you’re writing updates frequently you don’t have to fluff by adding quotes, referencing books, or even adding too many memes. As an aside: I’ve heard teams say they have “no time to write updates” a hundred times. I’ve never once heard “we don’t have time to meme.” Having the pulse of relevant updates can be a starting point, there’s always the chance to create rollup updates (more below) or to add some additional media. Hubspot and Github do a great job including videos with their updates. Great examples include the Hubspot monthly updates where they comfortably provide many one line updates in their monthly recaps. It’s OK to stay focused. ### The principles of better updates #### Using “you” language You’ve seen me refer to “you” language a lot in this piece. I thought I made this phrase up, but as I started to dig into the entomology, evidently there’s the concept of “I” vs “You” language in the field of couples counseling… whoops. It still makes a ton of sense here, I’m going to roll with it and I’ll talk about the ramifications with my therapist. All of the best updates included this “you” language. The features, benefits, and even motivation to build the thing in the first place is based on YOU, the customer, and not “I”, the company / team / developer / marketer that did the work. Remember: the goal is to remind our current customers why they’re paying us and to get new customers to sign up. The gold standard is “YOU will now be able to do thing X,” or even better “YOU will make more money because you’re getting benefit Y.” Here’s some quick examples to drive the point home. **Great “you” language:** Transistor.fm: ![Image 39](/images/blog/the-art-of-the-update/transistor-subscriber-content.png) ‍ Sendspark: ![Image 40](/images/blog/the-art-of-the-update/sendspark-copy-paste.png) ‍ Intercom: ![Image 41](/images/blog/the-art-of-the-update/intercom-reusable-workflows.png) ‍ Even in this article, see how I’ll say stuff like “my research, my experience, my companies…” isn’t that annoying? Don’t you just care about how you can improve your business and solve your problems to make more money? This is exactly the spirit of “you” language. #### Being multimedia If you skip this tip because you think it’ll be too time consuming: understandable, have a great day. For those of us interested in going maximum effort mode on updates, going beyond text is a great way to catch a wider audience for your updates, go into greater detail, and frankly to show off. Most of the big tech companies provide a video update alongside their text updates, so if we want to look a bit bigger than we are we can copy off of them. I’m personally a fan of video since you can get across a ton of information, control the flow (ie, people not skipping around), and you can get across some of your personality too. I generally record a video for each launch and update, you can find all of them on my [twitter highlights](https://twitter.com/bsierakowski/highlights). Whenever I launch something you’ll see this goofball face staring back at you: ![Image 42](/images/blog/the-art-of-the-update/goofball-face.png) ‍ Everyone has their own style, but I like to include some sort of upbeat background music, a slideshow to keep me on script, and a live demo of whatever I’m showing. Some people go even further, recording podcast episodes on their updates, creating infographics and charts (which are also nice for the sales / marketing team to share), and the biggest companies throw full on events for product announcements. This is definitely more work and if you’re having troubles getting updates out the door frequently I’d skip this step in a heartbeat. However, if you’ve got a great update that makes customers want to buy, it’s not a bad idea to go multimedia and squeeze the maximum juice out of it. #### Include customer language It’s one thing for you to say how great an improvement is, but it’s such a larger statement when you have a customer quote in a product update. It says two things, first that the thing you did actually helped at least one customer, AND that the customer cared enough to provide a quote. If you’re already doing a good job getting updates out the door, getting these customer quotes might be easier than you think. When a feature is requested or a bug is reported, capture the specific words that customer (or lead) says. When you fix it you let that customer know (you do let them know, right?), generally they’ll respond and let you know if it actually worked or if you still have problems to fix. If it’s fixed they might have already gone above and beyond with their language, saying “this is going to make my daily process 5 times faster!!” Your job is easy at that point, you say “Awesome—do you mind if we add that quote to the product update?” Conversely if they just respond “great, fixed” you can ask them to elaborate with a quote if they don’t mind. You can provide a tshirt or some other token of appreciation… but that’s a topic for another day. \* If you don’t have that open dialog going with customers another great standin is providing quotes from people on your team. Generally this is used by companies like Github, where they frequently quote senior members of their development team. I think this might work with other roles, but for whatever reason developers tend to be regarded as being fairly anti sales and marketing, so promoting a quote from a developer might seem apt where a quote from the CEO may seem disingenuous. I have no data to back that up other than seeing press releases from fast food companies that feature quotes from their CMO. The vibe is like “yeah VP of Marketing of Dunkin Donuts… of course you think the Salted Caramel Creamer is great and ‘wanted to bring that same excitement to the at-home coffee experience’”. Feel free to experiment. Getting language from a real customer is the best case, but even a stand-in quote from a persona might help frame the update from the perspective of a customer. An internal quote can also provide needed context and trust in the process. Ultimately our goal is to show that what we’re building matters to a customer and solves enough of a problem that they’re willing to take time out of their day to write about it. - This is getting a bit off topic but you can even get customer quotes when something breaks. Stripe did this with me when they accidentally took too much money from me way back in 2013. They explained what happened, said sorry, and asked if I wanted a shirt! Happy ending for all. #### Being Clear ![Image 43](/images/blog/the-art-of-the-update/dr-gurner-clarity.png) This is a similar mentality of not **being public** Clarity is the gift we give our customer negative words at a time. Being clear helps us, because fewer specific words are less things for us to type, speeding up the process. Being clear helps your customers because they are not interacting with our updates in a sensory deprivation tank. Everyone is in their own world with their own goals, dreams, and hurdles to overcome. Being clear helps your customer quickly scan your update and move forward with their day empowered. Being clear generally requires two things, **picking a set of words** to use and **simplifying concepts**. While “picking a set of words to use” literally describes the act of writing, what I mean here is that there should be a few key phrases which and unambiguous and that your customers will understand. I’ll give an example from my history, my first real business was called TeamPassword, it’s a password manager for teams. So far so good at picking a limited set of words. One of the hardest naming challenges we had was “what do you call the things stored inside the password manager?” I just used the obvious option, it’s a password manager, they’re “passwords.” The hold up on that reasoning was that each record included a title, url, username, password, and notes. Does it make sense to call the whole thing a password when it contains a password? Would that cause confusion when they put in a support ticket with a password issue? And since passwords are shared on teams, would that cause internal confusion? “I need the login info for that account, I don’t have answers to the security questions.” “Yes, I just shared the password with you” “… bro.” There’s usually tradeoffs in what words you pick, the important thing is to pick a specific set of phrases and stick with them. A side note for the curious: We decided to use the phrase “logins” in TeamPassword to refer to that combination of fields. There were shared logins and private logins, and logins could be categorized by a group. This still caused a lot of confusion and I wish we would have just called it the technically incorrect yet intuitive “password!” For clarity through simplifying concepts we can rely on a few of our other principles. Including the benefit (directly below) is a fantastic way to bring about clarity, not much mental energy is required when you’re saying a few words about how you’re helping them. Including the benefit lets you cut a lot of the fluff, too. If you’re completely focused on communicating the benefit of a feature to your customers you can skip the story about how this feature came to you on a hike, how you struggled to choose the right database, and how your lucky yellow socks really brought this thing together. There’s a joke that I tried to find to illustrate this… it’s basically someone being really long winded and providing irrelevant information to the listener, and the punchline is as they go to walk away they’re like “Oh, right, by the way your house is on fire.” If anyone can point me in the direction of what joke I’m thinking of I think that’ll really bring this piece together. Actually, I’m talking so much about including the benefit, let’s just get into it. #### Including the Benefit I saved this one for last because basically no one does this. Taking this last step to customer benefit is the secret jutsu / forbidden spell / limit break / ultimate ability of customer updates (depending on what type of nerd you are.) When I say “Including the Benefit” I mean spelling out how exactly the change that you made will make your customer’s business better. If you’re not sure where to start, the closest resource I’ve made in the past is the “five pillars of growth” published through Baremetrics. This is focused on saas businesses, and the TL;DR are that the five pillars are: 1. New customer revenue 2. Expansion revenue 3. Reduce churn 4. Reduce downgrades 5. Increase reactivations This isn’t the worst place to start when thinking of the benefits you can pass on to your customers. Through using your product, are your customers going to get more customers? Can they increase expansion revenue? Are you protecting against the downside of churn and downgrades? Or can you help them get their customers back? This can take a bit of creativity, which is ok! For example, one creative interpretation is that saving a marketing team time on a routine reporting task gives them more time to focus on marketing, scoring more new customers for their business. Similarly, improving some aspect of marketing reporting may help the marketing team identify which channels are converting, decreasing cost of conversion and acquiring customers more effectively, which either means more customers for the same budget, or the same number of customers for cheaper. There are lots of reasons customers churn, but goofs, gaffs, and f-ups is a sure fire way to burn customer loyalty. Any feature you deploy that prevents customer facing mistakes can be targeted at keeping customers happy. The goal here is to “take the final step” and tell your customer exactly how using your product is making them more money than not using your product. (One funny note, you might also try to include the benefit and realize… the updates we’re making will have no impact on our customer’s bottom line. That’s not good, and by focusing on this question perhaps we can do a bit of a better job with our roadmap.) Remember the different audiences reading your updates. Too many people assume the only audience for updates are the power users and oldest, most entrenched customers. Brand new customers who have ZERO context read the updates. Prospects and trial customers read the updates to see if this product gets improved. Anyone you’ve increased pricing on will scour the updates to see if it’s justified. Don’t make them work for it, tell them right up front how using your product makes their business better. Examples are in limited supply, but this update from Transistor FM does a great job: ![Image 44](/images/blog/the-art-of-the-update/transistor-subscriber-content.png) Why aren’t all updates this clear? “Add another income stream” ! Aka “you will make more money” which is what all of our customers want to hear. #### Bonus tips and tricks These are our hail marys (hail maries?), the tools we can pull out of our back pocket when we’re in a bind. Often we need to have the team “go long” when we’re **sticking to our schedule** but we legitimately have nothing to talk about. Sometimes you need a “touchdown” but haven’t… done the yards? Sorry, they haven’t made an NFL anime yet so I don’t really know the rules that well. So we’re on our schedule for an update and have nothing in the hopper, what can we do? Our first option is to feature some “popular updates” in addition to our chronological updates. You can see these callouts on the customer updates pages from both Trello and Hubspot. I think this is generally a good idea even if you have something to talk about, but featuring a previously popular update on the week that you don’t have anything else to say might just be a convenient solution to our lack of update problem. Another option is to do a round up over a longer timeline. Basecamp’s “new” page is a great example, showing how they highlight all the new features of the latest version of their product. The “new” features are all the features included in the latest version, which I’m sure they must have worked on for many months (or years) to build. A smaller option would be a “best of” for this month, quarter, half year, year… and if you burn through all of these and still have nothing to say go for “best of all time.” Another option is to roll up groups of features into one post (like our “advanced checklists” post by Trello.) One of our guiding principles is getting credit for every single line of code you write, but by doing these feature roll up posts this is actually like double credit, which feels like cheating. If you have time to focus on making an update but no update to write about, another option is to feature a customer’s usage pattern or specific use case. The contents will be different but the approach is the same—figure out a usage pattern in the product and highlight it sort of like it’s a feature. For example if you found out a customer is using the dashboards in your product to make important and lucrative decisions, that could be its own product update (“Become a millionaire with you dashboards.”) I’ve had superusers on every product that have shocked me in the way that they use the product, it’s always fun to show how engaged some customers are and share their pro skills with other customers. The same is true for a specific use case as well. For example, if you have a cross section of customers who own marketing agencies, thinking about the “Driving new customer acquisition as a marketing agency” update is a solid way to fill the space. You could also just generally get a customer shout out. I can’t take credit because this was done after I sold the business but this is [an amazing video for a customer of my last company TeamPassword](https://www.youtube.com/watch?v=KvfqBYSMFUE&list=TLGGpgmV2rsQFnQxNzAxMjAyNA): ![Image 45](/images/blog/the-art-of-the-update/teampassword-adhere.png) Beyond that… you just gotta vamp. It’s jazz baby! Do what you need to do to stick on schedule, and let this chilling time inspire you to get those customer updates planned in advance. ## The Templates By the way—if you’re overwhelmed by trying to write these frequent, churn reducing, upsell inducing customer updates while also running your business… Changebot can do this for you automatically. This guide includes a pretty wide array of tips, tricks, rules, mantras, schemas, and blueprints. Trying to smash all of those into one simple template that’s short and concise but also includes benefits, and boring stuff, and bad stuff… You can see that it can become a mess. As they say: there is no perfect tomato sauce, only perfect tomato sauces. Here’s a few quick updates you can use mad libs style to spend zero time thinking about structure and 100% of your time writing awesome customer updates. So existing customers stay longer and new customers sign up. You get it. Update Templates: - Big Feature Update Template - Customer Request Update - Bug Fix Update - Whoopsie Update - Rollup Update ### Big Feature Update Template We’re thrilled to announce \[feature name \]. \[Feature name \] will enable you to \[specific benefit, e.g., make more money, retain customers, get new customers, save time \] by \[the core of the feature. \] \[If a user reported / requested\] We started building \[feature name \] from customer feedback around \[quick anecdote about the feature request / feedback that started development. \] \[end\] Check out \[feature name \] here \[link to where they can try the feature \] to see how \[feature name \] can \[reiterate specific benefit above\]. As always, we value your feedback, so please let us know your thoughts! ### Customer Request Update Based on our conversations we’ve introduced \[feature name \]. This update focuses on \[specific benefit, e.g., make more money, retain customers, get new customers, save time \]. We know this update will help with \[benefit above \] based on our conversations with you, specifically \[quick anecdote about the feature request / feedback that started development \]. Your input makes our product better – keep those ideas coming! \[Or a similar combination of platitude + request for more feedback \]. ### Bug Fix Update In our latest update we’ve made a number of improvements to make your life better, including \[nature of bug fix(es) \]. These improvements mean a smoother, more reliable experience for you, resulting in \[specific benefit, e.g., make more money, retain customers, get new customers, save time \]. We’re thrilled to constantly improve the product for you. If you encounter any issues, our support team is just a message away. \[Or a similar combination of platitude + request for more feedback. \] ### Whoopsie Update Recently, we encountered \[issue\] and we want to openly address this. Here’s what happened, why it happened, and the steps we’ve taken to ensure it doesn’t recur. \[what happened\] \[why it happened\] \[mitigating steps\] We appreciate your understanding and continued trust in us, we’re totally focused on providing \[specific benefit, e.g., make more money, retain customers, get new customers, save time\] to all our customers and will continue doing that in the future. ### Rollup Update As \[month / quarter / whatever term\] comes to a close, here’s a roundup of all the new features and improvements we’ve made. From \[list major updates\] to \[list smaller enhancements\], we’re always making sure you can \[specific benefit, e.g., make more money, retain customers, get new customers, save time\]. Check out our comprehensive summary and let us know what you think! ## Closing We’ve been through a journey together. The original idea for this piece was a short, SEO focused article that would transfer a bit of knowledge and build a bit of awareness for the work we’re doing around automating customer updates. As I started writing I realized that: 1. I have a lot to say about customer updates, and 2. SEO focused short term content kinda sucks. We’ve all searched for things, landed on the top result, only to realize that the article just restates the question 10 times and maybe answers the question. This drains the world of time since every reader is paying the 5 minutes of time reading an article that took them like 30 minutes to write. The balance flips after 6 people read the article, which sucks. I realized in creating this that we severely lack “maximum effort” content, where I want to drop 200+ hours reading, researching, writing, and rewriting. I want to deliver that in a format that a reader can skim through and have them leave with a careers worth of ideas and context. Hopefully you feel that way. If you don’t please let me know. To close out the key concepts of this article, here’s a mega TL;DR: 1. We should get credit for every line of code we write 2. Companies, especially early stage tech companies, are roasted for spending all their time on product and no time on marketing. Not updating your customers is what this looks like in practice. 3. Most companies don’t update their customers frequently enough. 4. Most companies are not explicit about the business benefits they’ll get from using your product. 5. Of the companies that do publish updates, too few of them realize that it’s marketing to all audiences, beyond just our current customers to prospects and leads as well. My mission in the proceeding ~70 pages is addressing these points so you’re in the top 1% of customer updaters. If you’ve made it this far I’d love to hear from you, specifically on: 1. Did any part of this document stand out as particularly good? 2. Did any part of this document stand out as particularly bad? 3. What do you think is missing? 4. Do you have any great examples that I’ve missed? 5. Any other feedback that springs to mind as you read the document. ### Acknowledgements This beast of a document started as a short, SEO focused article. It would not be in it’s final, completed form without ~200 hours of research and 10,000 more hours of distilled career advice from the following people: - Jason Cohen: < [https://twitter.com/asmartbear](https://twitter.com/asmartbear)\> - Paige Harriman: < [https://twitter.com/climatepaige](https://twitter.com/climatepaige)\> - Walter Chen. Check out his company: < [https://sacra.com/](https://sacra.com/)\> - Jason Gilmore: < [https://twitter.com/wjgilmore](https://twitter.com/wjgilmore)\> - Alexandru Golovatenco: < [https://twitter.com/AlexandruGlv](https://twitter.com/AlexandruGlv)\> - Josh Pigford: < [https://twitter.com/Shpigford](https://twitter.com/Shpigford)\> - Clay Collins: < [https://twitter.com/ClayCollins](https://twitter.com/ClayCollins)\> - Ryan Kulp: < [https://www.ryanckulp.com/](https://www.ryanckulp.com/)\> Please thank them over the internet as I could not have done this alone! ## Table of Contents - [Why don’t we send customer updates?](#why-dont-we-send-customer-updates) - [Why should we send customer updates?](#why-should-we-send-customer-updates) - [Preventing churn](#preventing-churn) - [Increasing new customers](#increasing-new-customers) - [Boosting expansion revenue](#boosting-expansion-revenue) - [Setting up for a price increase](#setting-up-for-a-price-increase) - [Building Trust](#building-trust) - [Earning referrals and testimonials](#earning-referrals-and-testimonials) - [The Research: Examples in the wild](#the-research-examples-in-the-wild) - [Slack](#slack) - [Trello](#trello) - [Github](#github) - [Basecamp](#basecamp) - [Mailchimp](#mailchimp) - [HubSpot](#hubspot) - [Baremetrics](#baremetrics) - [Reference companies without complete research](#reference-companies-without-complete-research) - [Act 3, The Science of great updates](#act-3-the-science-of-great-updates) - [The principles of more updates](#the-principles-of-more-updates) - [The principles of better updates](#the-principles-of-better-updates) - [The Templates](#the-templates) - [Big Feature Update Template](#big-feature-update-template) - [Customer Request Update](#customer-request-update) - [Bug Fix Update](#bug-fix-update) - [Whoopsie Update](#whoopsie-update) - [Rollup Update](#rollup-update) - [Closing](#closing) - [Acknowledgements](#acknowledgements) Stop writing the changelog by hand The Changebot Agent drafts customer-ready updates from your GitHub history. Publishing is free. [Get Started for Free →](https://app.changebot.ai/signup) [← Back to Blog](/blog) # The changelog is always the last thing you update URL: https://www.changebot.ai/blog/the-changelog-is-always-the-last-thing-you-update/ Description: Ship the code. Update the docs. Update the marketing page. Then, if there's time, update the changelog. Here's why 'afterthought' is the default and how to fix it. Last updated: 2026-02-16 Best Practices # The changelog is always the last thing you update [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder February 16, 2026 4 min read ![Illustration of a priority stack with changelog at the bottom collecting dust](/_astro/featured.pnGxyg_q_Z1Yu70o.webp) A founder described his release workflow to us recently. Ship the code in one repo. Update the docs and marketing site in another repo. Then open a third system — his changelog tool — and write up what changed for customers. “It’s always an afterthought,” he said. Not because he doesn’t care about the changelog. Because by the time he gets to it, the work is already done and his brain has moved on. ## The priority stack When you ship a feature, there’s an implicit priority order. The code has to work, the docs need to be accurate, and the marketing page needs to reflect the current product. Customers need to be able to use the new thing. The changelog? It’ll still be there tomorrow. And tomorrow, there’s a new bug to fix. A new feature to scope. A support thread to respond to. The changelog slides. It slides again. A week later, you’ve shipped three more things and the backlog of unannounced changes is growing. This is a priority problem, not a discipline problem. Changelogs don’t have deadlines. They don’t break if you skip them. No alert fires when a feature ships without a changelog entry. The only signal is silence — customers who don’t hear about improvements, prospects who can’t see your velocity, support teams who learn about changes from customer tickets. ## The three-system problem The founder’s workflow exposed something we see in many teams: the changelog lives in a separate system from the work it describes. His code lives in one repository. His docs and marketing site live in another. And his changelog tool is a third, disconnected system entirely. Shipping a feature means three context switches: write the code, update the docs, then open the changelog tool and summarize what you did. Each hop drains motivation. By the time you’ve pushed code and updated docs, you’ve already done the hard part twice. Doing it a third time in a different tool (different interface, different formatting, different mental mode) is where most people give up. Not permanently — just for today, and then tomorrow. The founder’s proposed fix was to bring the changelog into his marketing site’s codebase so updates could live alongside docs and marketing pages in the same pull request. That way, shipping a feature and announcing it happen in the same workflow instead of requiring a separate tool. His instinct was right: the closer the changelog is to where the work happens, the more likely it gets done. ## The quality cost of afterthoughts Even when changelog entries eventually get written, afterthought entries are worse than timely ones. By the time you sit down to write the entry, the details are fuzzy. You remember the feature but not the specific pain point it addressed. You remember the bug fix but not which customers it touched. The result is generic entries: “Improved performance,” “Fixed a billing issue,” “Added new filtering options.” Technically accurate but practically useless. They don’t tell the customer why they should care, don’t give support the context to answer questions, and don’t help marketing position the improvement. Good changelog entries require context that’s freshest at shipping time. The team built the feature to solve a specific problem for a specific customer segment. Three different accounts reported the bug in the same week. The improvement reduces page load time by 40%. That context exists in the team’s heads right after shipping. Two weeks later, it’s gone. ## The collaboration gap The founder also pointed out a collaboration problem. His changelog tool doesn’t support easy draft sharing. When he wants feedback on a changelog entry before publishing, his team shares screenshots in their project management tool and comments on the image. Screenshots. Of text. To get feedback on writing. It’s the kind of workaround that tells you the tool doesn’t fit the workflow. Teams that care about quality (and this team does) will invent elaborate processes to maintain standards. But each workaround adds friction, and friction makes the changelog feel even more like an afterthought. ## Making it the first thing, not the last The fix isn’t willpower. “Just remember to update the changelog” doesn’t work for the same reason “just remember to floss” doesn’t work. The behavior needs to be part of the existing workflow, not a separate step you need to remember. The teams that keep their changelogs current have one thing in common: the changelog update lives inside the shipping process. It happens as part of the deploy, not after it. It pulls context from the code changes and ticket metadata that already exist. It doesn’t require opening a separate tool or switching mental modes. When the changelog generates from the work itself (commits, PRs, and tickets) it stops being a thing you need to do after shipping and becomes a thing that happens because you shipped. That’s the difference between a changelog that’s always out of date and one that’s always current. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # The customer always comes back URL: https://www.changebot.ai/blog/the-customer-always-comes-back/ Description: SaaS customers are canceling to vibe-code their own tools. They're also coming back a month later. Here's why the build-it-yourself era is a blip, not a trend. Last updated: 2026-02-20 Best Practices # The customer always comes back [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder February 20, 2026 5 min read ![A boomerang arcing through the air, representing SaaS customers who leave and come back](/_astro/featured.xIUcbq20_daQKk.webp) A friend of ours runs a successful SaaS business. She was giving us an update on the latest AI trends she’s seeing, and our recent conversation make me laugh, but then think (which is unusual for me). The boogeyman of AI for every SaaS business right now is the idea that customers will cancel their subscriptions to your tool because they vibe-coded their own version of the product. Dashboard, charts, the whole thing, built it in a weekend with Cursor or Claude. And this is happening to day, they build a demo in a weekend and it looks awesome. This has happened to our friend over a dozen times already, the team panicked… but then 2-3 months later, the customers started coming back, and this happened for each of the dozen customers. ## The demo is not the product We’re living through an incredible moment for building software. A non-technical person can sit down with an AI coding tool and produce something that genuinely looks like a real product. This wasn’t possible a year ago, and we shouldn’t downplay it. As you might imagine, I’m about as far as you can get from “this AI stuff doesn’t work.” Still, there’s a gap between “looks like it works” and “actually works.” Our friend experienced this firsthand looking to deploy features to her product using AI. It connected to real APIs, pulled real data, had a clean UI. The problem? Some months, the math was just wrong. The app made numbers up. She was up at 2 a.m. screaming in all caps at Cursor before she gave up and decided that maybe the time had come to consider the AI effort the demo and proof of concept and actually build the feature from the ground up “the right way.” I’m not knocking her or the tools, it’s just the reality of software. The last 20% of the work is 80% of the effort. Getting data to display is easy, getting it to display _correctly_, across edge cases, over time, with real users, well, that’s the real value a product provides. ## The $1,000 problem There’s a meme going around about someone complaining that $1,000 a month for HubSpot is too expensive. The punchline: they replace it with a full-time hire at $100,000 a year to build a worse version. The math on building your own tools almost never works out. Our friend’s AI feature prototype took about 10 hours to build something that sort of worked. If they actually wanted to deploy that feature, meaning that we’re taking into consideration reliable data, period-over-period accuracy, maintainability, etc, we’re still days if not weeks out. For this specific feature she estimated a 15 month break even on the time investment compared to literally just doing the task manually. Your mileage will vary depending on the feature you’re building, how frequent and time-consuming the task is, and how close you get to a “one shot”, but everyone I’ve spoken to starts to think that maybe they should just keep doing the task “by hand” after three months of using their vibe coded tooling. I get the annoyance around subscriptions, but in my (ultimately biased perspective) it’s still an absurdly good deal compared to every alternative. A software product is hundreds or thousands of engineering hours amortized across a customer base. When you build your own, you’re paying full price for all those hours yourself. You get infinite customization and flexibility, and there are situations where it’s too painful to bend the existing product around your org, but just under the surface are all those implementation details, lying in wait. ## The “hold the line” moment I had a call with the folks at another OG SaaS company and they mentioned something interesting: their bigger customers all want to do “agent” stuff in-house right now. Instead of paying the company that’s building the product to do the “agent layer”, they want to take the data returned by the product and build it themselves. This is happening everywhere, Enterprise teams feel empowered by AI tooling (and motivated by the relentless enterprise sales teams at all these companies) and want to try. That’s healthy, but it’s also a phase. Right now the momentum is on the side of stories like “I vibe-coded Salesforce in a weekend.” That narrative is exciting and new and gets engagement on LinkedIn. My prediction is that soon the momentum will shift to “the customer came back.” Teams will (and should) do their limit testing. They’ll discover that connecting to an API is the easy part, and maintaining accuracy, handling edge cases, and iterating on UX over months is the actual job. And then they’ll be ready to work with purpose-built tools again, with a much better appreciation for what those tools actually do. Ever since “fours steps to the epiphany” we’ve all known that the best customer recognizes they have a problem, has spent time and money to try and solve the problem, has failed at solving the problem, and now they know exactly the solution they need (and how hard the problem actually was.) AI speedruns potential customers through this process at lightspeed, we just need to hold the line as the limit testing occurs. ## What SaaS companies should do right now If you’re a SaaS company watching customers churn to build their own: don’t panic. And definitely don’t slash your prices or start bolting on AI features just to have a story to tell. Instead do the work that AI-generated tools can’t replicate: deepen your domain expertise, tighten your feedback loops with customers, and make your product the thing that’s not worth rebuilding. A non-technical person summed it up better than any analyst could: “I could make something that looks ok but there is zero chance I could get it across the finish line. I need help.” That gap between “looks ok” and “finish line” is where your product lives. It’s where your years of iteration, customer feedback, and domain knowledge compound into something that a weekend project can’t touch. If ever there was a time to triple down on product, now is the time. The joke is that when your customers look up from their experimentation replacing internal tools they’ll have the same revelation: hey, maybe we should be using these AI tools to make OUR PRODUCT better for customers too? * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # The Development Hell Death Spiral (and how to escape it) URL: https://www.changebot.ai/blog/the-development-hell-death-spiral-and-how-to-escape/ Description: When big dev projects stall your roadmap, the real danger is the communication death spiral that follows. Last updated: 2025-05-19 Best Practices # The Development Hell Death Spiral (and how to escape it) [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder May 19, 2025 8 min read ![The Development Hell Death Spiral (and how to escape)](/_astro/featured.DvQdHFZo_1Pt8Pv.webp) The Development Hell Death Spiral is one of the most frustrating, difficult-to-solve, and demoralizing experiences in SaaS. Nearly everyone who’s built product has been there. It goes something like this: 1. The product needs a “big” change to support future work. Think: brand new frontend, big dependency update, major integration 2. Since this change is so large and important, the team does no other work at the same time (or perhaps can’t do any) 3. And, because it’s so large and important, it’s harder than you expect. What should take 1 week turns into 2, then 4. The dev process is now single-threaded and jammed. You’re fully in Development Hell. 4. Then, the Death Spiral starts: because of the gridlock, you’re hesitant to talk to new customers. Even worse, you don’t know what to say to your existing ones. Sound familiar? If not, you’re either new to SaaS, have never made a big software change, or are just really, really good at computers. ![Great Job Reaction GIF](/_astro/great-job.BfeXYYWf_Z1o6CWL.webp) Guy who's never experienced the Death Spiral. For everyone else, let’s tease apart what’s going on here. We’re going to disassemble the monolith that is the Development Hell Death Spiral so we can solve it incrementally and get unstuck. ## “You done goofed” Getting stuck in Development Hell is embarrassing. A successful entrepreneur acquaintance once told me: > It’s extraordinary how wrong we are, and how frequently wrong, considering how long we’ve been doing this. Here’s my take: if you’re truly building something new, there’s no way to predict exactly what your product will need to become to be successful. At the intersection of - “do important things,” - “make significant progress,” and - “move quickly” is running full-speed into significant technical challenges. It’s human nature to think you could’ve avoided Development Hell with just a little more planning, research, or foresight. A large number of people have full-time jobs creating project plans with charts and graphs to avoid these “blockers.” Here’s the truth: > Rock and roll has no Gantt charts, baby. If you’re in the situation where you need to make large changes to your product, that means you’re working with your customers and building around real problems experienced by real people. Entering Development Hell is a rite of passage. It might even mean you’re on the right track. ## An (abridged) tale I’ve gone through Development Hell recently due to my fundamental misunderstanding of how people would use our product. I’ll share the short story here, and include the full details (and specific, somewhat unrelated learnings.) When we started Changebot we assumed that the product would be primarily a churn reduction tool, sharing changelog updates with existing customers. We said: why not get credit for the work you’re already doing? Having gotten owned many times in the past by customers assuming we were DOA, this felt like a great idea. The problem, of course, was our customers. The first (and only) feedback was “these updates suck.” We continued to get that feedback until, well, we made the updates not suck. Then the feedback exploded into a million different things and it became clear that people did not just want Changebot to generate updates for their current customers, they also wanted Changebot to engage and convert leads. Quickly we learned that “changelog” is a word that nerds use, and normal people either don’t know what that means, or think it’s a word for nerds. ![Revenge of the Nerds 80s GIF](/_astro/nerds.jdmv3FLo_2jzf4f.webp) POV you tried to sell a 'changelog' tool to a non technical founder. Our customers wanted a tool to create updates, remix them, and distribute them. Anything to get their message in front of their customers AND leads. The bad news? Everything we had built so far assumed that our frontend only needed to report on work that teams had already completed. We attempted to build around it, but we realized we were actively avoiding building features because we knew there would eventually be a new frontend needed and couldn’t bear doing the work twice. Then the front-end rebuild started. That was when I felt the Death Spiral creep up: - I hesitated just a moment longer doing cold outbound. - Social posts started getting shipped a bit more slowly. - Trial signup outreach started to become more superficial and less specific. - Existing customer check-ins started slowing. All for the classic reason: if they needed a product improvement I didn’t know when we could deliver, so why get their hopes up? I was standing on the edge of the cliff with the Death Spiral beckoning me to take a step further into its inky depths. Here’s what I did instead. ## Disassembling the Spiral Development Hell serves as the inciting incident that triggers the Death Spiral. Development Hell turns into a Death Spiral when our fear of failure freezes the funnel. (DH becomes DS when FFFF.) You stop cold outbound. You slow down social posts. You avoid trial follow-ups. You pause check-ins with customers. Because you’re worried the product isn’t ready. That it’ll disappoint. That someone will say “no,” or ask for something you can’t deliver on. You start playing the conversations out in your head: > You: Hello prospect, interested in some software? Them: Yes of course, but we need it exactly now and with the following modifications. You: Ah yes, of course, but could we perhaps show you what we have so far? Them: UNSUBSCRIBE. (Marked as spam. Reported to the SEC.) Or… > You: Hi Customer! Enjoying the product? Them: Yes, but I need one small thing. You: We can totally do that but it will take a bit… Them: CANCEL. (Chargeback issued. Lawsuit filed.) Silly, right? Well you’re the one doing it, Goofus. This is all to make the point: **Radio silence is the actual cause of the death spiral.** When things get hard communication needs to go UP, not DOWN. Practically: what can we do? Like, specifically? How can we Escape the Loop of Doom? Funny you should ask. ## Introducing the HELD Method How to Escape the Loop of Doom _Development Hell HELD you… now you’re breaking free._ ### Hype Build up your hype backlog. Document (or create) a stockpile of all improvements, wins, points of interest, and anything worth sharing that’s not blocked by your current dev efforts. Think: **Non-product improvements:** Think about what, outside the currently blocked product, you’ve improved or can improve and share with customers. Consider: - 3rd Party Plugins like leveraging your existing API / webhook emissions to build a Zapier add on, or even more fun a TRMNL plugin. - Process improvements like “better security” (which often just means writing things down), faster support, or any other internal upgrade. - Even taking the time to clean up your documentation can be worth talking about. **Work In Progress Updates:** While we typically avoid sharing updates before teams ship a feature, if you’re going to be in Development Hell for a bit it’s worth sharing a quick update to explain what’s going on, why it’s taking time, and why it MATTERS. You can also write a blog post about the process and publish it all over the internet… not that I know anything about that. **Retrospectives:** Who says you can’t go back in time? This is getting published in the beginning of Q2… congrats, time for a Q1 recap! While this might feel like the ultimate cop-out, I promise people love a recap. And, for the record, this might be most valuable for you and your team as a reminder that when you zoom out this current patch of Development Hell is just a temporary state. **Momentum Starters:** Thought about starting a newsletter? A podcast? A book club? Haven’t done that because you don’t have the time? Well, guess what, now you do! Starting a newsletter is the perfect reason to reach out to your customers and share all the cool content you’ll be getting to them, and it also creates a marketing asset that will exist and return dividends long after you’ve conquered Development Hell. **If you’re blocked on shipping, shift focus to sharing.** ### Establish Establish your comms plan. With the above achievements in hand, pick where you want to engage with customers. Many choices exist which is why it’s important to plan with channels we want to engage on. My suggestions are the usual suspects, but consider the following for your list: - Social (a la X, LinkedIn, etc) - In-app - Email - Forums (a la Reddit) - Your marketing site - Your blog - Podcasts - YouTube You don’t (and shouldn’t) pick all these, but if you’re already active on social media it probably makes sense to add another channel, at least for the short term. ### Light up Double your output. Whatever communication you’re doing on these channels historically, double it. Doing nothing? Start with one post per week as your floor. Already posting monthly? Bump it to weekly. Again, we’re trying to force MORE communication and set a floor for how infrequently communication can happen. Lean on the Hype backlog. Share work in progress, backstory, interviews, improvements, anything that’s potentially interesting, shows movement in the right direction, and definitively says “we’re alive.” ### Go Direct Finally, go direct. Everything we’ve done above sets the stage for our piece de resistance. Book calls with as many customers as you can. Get on chat. Find as many ways to interact with your customers as you can. A 15 min conversation with a customer does more lifting than 30 tweets a month. Here’s the hack: you don’t need to spend the whole time talking about yourself, the product, or whatever has got you stuck in Development Hell. Use this as a time to get new inputs. Ask how their business is going, what they’re working on, what they’re excited and or worried about. Ask how their cat is. Run some tattoo ideas by them. By creating this framework of communication in steps 1-3 we’ve created a conversational environment to take advantage of. The secret silver lining is that since your hands are tied from talking too much about your product, now is the perfect time to step back, learn, and bring new info in. ## In Closing Getting into Development Hell is inevitable, but the Death Spiral is avoidable. Remember that when product updates slow down, communication needs to go up. Use the HELD method to get out of the Death Spiral, but here’s my final secret: don’t stop the communication cadence after you ship. We can exit the Development Hell Death Spiral much stronger than we started, provided you catch the spiral early, put great systems in place, and stick to it. [← Back to Blog](/blog) # The Draft-to-Publish Workflow That Actually Works URL: https://www.changebot.ai/blog/the-draft-to-publish-workflow-that-actually-works/ Description: PMs draft. Marketing refines. Here's how to automate the drafting without losing the positioning control that makes release notes effective. Last updated: 2025-12-31 Best Practices # The Draft-to-Publish Workflow That Actually Works [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder December 31, 2025 6 min read ![Three-stage workflow showing automation generating a draft, a human refining it with editing marks, and the polished document flowing to multiple distribution channels](/_astro/featured.D20IvKdv_ZdCK6e.webp) “Marketing owns messaging and positions release notes. PMs write drafts, but marketing finalizes it. We need final positioning control.” A Head of Product Operations laid this out during a recent conversation. Her company had a defined workflow: product managers create drafts, marketing refines and approves, then the content goes out. Any automation had to fit into this process, not replace it. This is a more common pattern than you might think. And it’s exactly the right way to think about automating release communication. ## The Handoff Pattern At most companies of reasonable scale, release notes involve at least two roles: **The drafters:** Product managers or engineers. They know what shipped and have technical context. They write the first version. **The finishers:** Product marketing or communications. They know brand voice, positioning, and audience. They polish and approve. This division exists for good reasons. PMs are closest to the work. PMMs are closest to how customers should hear about the work. Neither can do both jobs perfectly. ## Why Automation Often Fails Here When teams try to automate release notes, they make one of two mistakes: **Mistake 1: Bypassing the workflow entirely.** The automation generates content and publishes it directly. Marketing never sees it. The result is technically accurate but poorly positioned, off-brand, and sometimes embarrassing. **Mistake 2: Creating more work.** The automation generates drafts that are so rough they need complete rewrites. Marketing now has two jobs: writing from scratch AND managing the automation output. Net time savings: negative. Both failures share a root cause: the automation wasn’t designed to fit the existing workflow. ## What “Draft-to-Publish” Actually Means A workflow-aware approach works differently: **Step 1: Automated draft generation.** The system creates a first draft based on code changes, commits, PRs, and any available context. This draft is not published. It goes into a review queue. **Step 2: Human review and refinement.** Marketing reviews the draft. They adjust positioning, refine language, add context, and fix any inaccuracies. The automation makes this step faster, not unnecessary. **Step 3: Approval and publishing.** Once marketing approves, the content publishes to configured destinations: changelog, Slack, email, help center, wherever. The automation handles the tedious part (gathering changes, creating initial language). Humans handle the judgment part (positioning, tone, what to feature). ## Where the Time Actually Goes Most people assume writing is the time sink. It’s not. Consider what creating a monthly release recap actually involves: **Discovery (40% of time):** What actually shipped? Checking Jira, GitHub, Slack, asking engineers… reconstructing three weeks of context. **First draft (20% of time):** Actually writing the initial version. **Review and refinement (25% of time):** Getting feedback, making edits, agreeing on positioning. **Distribution (15% of time):** Copying to different channels, formatting for different destinations. If you automate only the first draft, you save maybe 20% of the total effort. If you automate discovery AND first draft AND distribution, you save 75%. The draft-to-publish workflow focuses on automating everything except the 25% where human judgment matters most. ## Marketing Control Here’s what marketing needs to maintain control: **Nothing publishes without approval.** This is non-negotiable. Automated systems make mistakes. Brand-sensitive content requires human sign-off. **Edits are easy.** The automation should produce output that’s easy to change, not locked in a format that requires starting over. **Tone adapts.** Over time, the system should learn from edits. If marketing always changes certain phrases, the automation should adapt. **Context is available.** When reviewing a draft, marketing should see the underlying changes, not just the generated text. This helps them refine accurately. **Distribution is controllable.** Marketing should decide which channels get which content. A Slack update might be appropriate immediately; a blog post might need more polish. ## What Automation Should Handle Given these constraints, here’s what makes sense to automate: **Change aggregation.** Pulling together commits, PRs, deployments, and tickets into a coherent list. This is tedious and error-prone for humans. **Initial categorization.** Bug fix, new feature, improvement, security update. Automated systems can do this accurately. **First-pass writing.** A draft that captures the essential information in readable language. Not perfect, but a starting point. **Technical-to-customer translation.** Converting engineering language to customer language. This is where AI shines: it doesn’t get attached to technical jargon. **Multi-channel formatting.** The Slack version, the blog version, the email version. Same content, different formats. **Distribution mechanics.** Actually pushing content to destinations once approved. ## What Humans Should Handle And here’s what should stay with humans: **Strategic positioning.** How does this release fit into the broader product narrative? What story are we telling? **Priority decisions.** Which changes deserve headlines? Which are footnotes? Which get omitted entirely? **Brand voice nuance.** The automation can approximate tone, but the final voice check needs a human ear. **Accuracy verification.** Did the automation misunderstand something? Is there context it doesn’t have? **Timing decisions.** Should this go out now or wait? Is there a better moment for this announcement? ## The Learning Loop The best draft-to-publish systems get better over time: **Edits become training data.** When marketing simplifies jargon or adjusts phrasing, the system learns the preference. **Rejected drafts inform future drafts.** If certain types of changes consistently need heavy rewrites, the system adjusts. **Company context accumulates.** Product positioning, customer segments, competitive framing: the system should incorporate this over time. **Individual preferences matter.** Different editors have different styles. The system can adapt to who’s reviewing. This learning loop is what separates a useful automation from a novelty. Without it, you’re manually training the system forever. ## Making the Handoff Smooth The handoff between automated draft and human review needs to be frictionless: **Clear status indicators.** What’s awaiting review? What’s approved? What’s published? **Easy editing interface.** Marketing shouldn’t need to learn a complex tool. The editing experience should feel like editing a document. **Change tracking.** What did the human change from the automated draft? This feeds the learning loop. **Preview capability.** Before publishing, see exactly how the content will appear in each destination. **Rollback options.** If something goes wrong, quick recovery matters. ## What changes when the agent is the interface The draft-to-publish workflow gets stronger when the first draft starts in an agent conversation instead of a separate editor. You can ask for a recap, review the result, request a less technical version, and generate a support summary without copying content between tools. The agent keeps the context alive while the review step keeps humans in control. The important product boundary is still the same: the agent can draft and revise, but publishing should be an explicit approval step. Changebot’s job is to connect the conversation to the changelog destination so the final update becomes a durable record, not another AI response lost in chat history. ## The Realistic Expectation Here’s what a well-implemented draft-to-publish workflow delivers: **First month:** Drafts need significant editing. Marketing is learning what the system produces. Time savings are modest. **Third month:** Drafts are usable with minor edits. Marketing is making positioning tweaks and corrections, not rewrites. Time savings are real. **Sixth month:** The system has learned enough that most drafts need light editing only. Marketing focuses on strategy instead of mechanics. This system improves with use. Teams that expect perfection on day one will find themselves underwhelmed. Teams that invest in the learning loop will see compounding returns. ## The Bottom Line Marketing should own final positioning. That’s the whole point of having a marketing function. Automation doesn’t change this. What automation changes is how much effort it takes to get to the point where marketing can do their job. Instead of PMs spending days assembling context and writing first drafts, they spend minutes reviewing what the system produces. The draft-to-publish workflow respects organizational roles while eliminating busywork. Marketing keeps control. Everyone saves time. * * * If your PM-to-marketing handoff is a bottleneck, [start free](https://app.changebot.ai/signup) and try the draft-to-publish loop with a hosted changelog. To see how the agent workflow works, read the [Changebot MCP example](/blog/publish-your-changelog-from-claude-code). [← Back to Blog](/blog) # The fifteen-minute illusion URL: https://www.changebot.ai/blog/the-fifteen-minute-illusion/ Description: Your changelog process only takes fifteen minutes. But that number is hiding the real cost of how your team communicates what shipped. Last updated: 2026-02-19 Best Practices # The fifteen-minute illusion [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder February 19, 2026 3 min read ![Illustration of a stopwatch showing fifteen minutes with a hidden iceberg of context-gathering work beneath](/_astro/featured.BpK0x1Io_Z1u2DdI.webp) A product lead at a developer tools company described his changelog process to us recently. “Ten, fifteen minutes,” he said. He meant the writing. He wasn’t wrong. Once he sits down to write the changelog entry, it goes fast. He’s good at it. He knows his product, knows his customers, and can translate a technical change into a clear update without much effort. The writing, though, is the last step. Before he types a single word, he’s already done the real work. ## Everything before the writing His actual process starts much earlier. He scans merged PRs to figure out what shipped. He separates customer-facing changes from internal cleanup. He decides which bug fixes are worth mentioning and which ones aren’t. He figures out how to frame a change that touches three or four systems into something a customer can understand. None of that takes fifteen minutes. But because it happens gradually — in standups, in PR reviews, in mental notes throughout the sprint — it doesn’t feel like “changelog work.” It feels like context he already has. That’s the illusion. The writing is fast because one specific person has spent the entire sprint accumulating the context needed to write well. The process looks efficient because the expensive part is invisible. ## The “good enough” ceiling When a process feels like it only takes fifteen minutes, you never question it. Why would you? Fifteen minutes every two weeks is nothing. It works. It’s fine. “Fine” has a ceiling, though. The PM we talked to admitted he skips changes that are hard to explain. Bug fixes that affect a small number of customers get left out because the effort-to-impact ratio doesn’t seem worth it. Internal improvements that would reassure customers (performance gains, reliability work) don’t make the cut because they’re hard to translate into customer language quickly. The fifteen-minute process only captures what’s easy to communicate — not everything worth communicating. That’s a different thing. ## The single point of context There’s a deeper problem. When one person holds all the context needed to write the changelog, that person becomes the system. If they’re out sick, the changelog doesn’t happen. If they leave the company, nobody knows how the process works because the process was them. We hear this on almost every call we take. The person writing the changelog is almost always the person who cares the most about customer communication. They’re also almost always the person who should be spending their time on something more strategic. A VP of Product at another company told us she does the same thing — goes through tickets one by one, rewrites them for different audiences. Her version takes far longer than fifteen minutes, but the underlying problem is identical. A manual process that depends on one person’s context doesn’t scale, even when that person is fast. ## What fifteen minutes actually costs The cost isn’t the time. Fifteen minutes is genuinely not a lot. The cost is what you don’t do because the process feels efficient enough. You don’t announce the bug fix that three customers reported because it’s not “big enough.” You don’t update the changelog for the performance improvement because it’s hard to quantify. You don’t tell support about the edge case fix because it only affected a handful of accounts. Each of those decisions makes sense individually. Collectively, they create a gap between what you shipped and what people know about. Customers think you’re shipping less than you are. Support doesn’t know about fixes that would save them time. Marketing has nothing to work with because the “small stuff” never makes it out of the PM’s head. ## The real question isn’t speed The question isn’t whether your changelog process is fast enough. It’s whether it’s capturing enough. If one person can write a solid changelog in fifteen minutes, that’s a sign they’re good at their job. It’s also a sign the process depends entirely on them — their context, their judgment, their availability. The upgrade goes beyond making the writing faster. It means automating the context-gathering and prioritization that happen before the writing starts. It’s making sure every customer-facing change gets captured, not just the ones that are easy to explain. It’s removing the dependency on one person’s mental model of what matters. Fifteen minutes of writing is fast. But you have to wonder what you’re leaving on the table. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # The five rewrites problem URL: https://www.changebot.ai/blog/the-five-rewrites-problem/ Description: Every release cycle, the same update gets rewritten five times for five audiences. Here's why that's killing your product team's bandwidth. Last updated: 2026-02-22 Best Practices # The five rewrites problem [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder February 22, 2026 4 min read ![Illustration of a single document splitting into five paths for different audiences](/_astro/featured.DJaXBpwi_2bAx0a.webp) A VP of Product described her release process to us recently. Every two weeks, her team ships a release. Then the real work starts. First, she goes through Jira ticket by ticket, copying and pasting items into internal release notes. Then she rewrites those notes for the support team, stripping out the technical jargon and adding the context they need to answer customer questions. Then she rewrites them again for the customer-facing help hub. Then again in marketing language for the product marketing lead. Then one more time as a summary for the weekly leadership deck. Five rewrites of the same information. Every two weeks. With a team of two and a half people. ## Crossing the border Every time information passes between teams, it needs translation. Engineering speaks in pull requests and ticket IDs. Support needs to know which customers feel the impact and what to tell them. Marketing wants benefit-driven language. Leadership wants a summary of what matters strategically. It’s like crossing borders in the EU — every border crossing means switching languages, even though the underlying information is the same. Only the packaging has to change. Most teams treat this as a writing problem, but it’s not — it’s a throughput problem. The VP we spoke with isn’t slow at writing. She’s fast. The issue is that the same piece of information requires five separate passes, each with different context, different vocabulary, and different assumptions about what the reader already knows. ## The compounding cost If you ship once a quarter, five rewrites is annoying but manageable. If you ship every two weeks, it’s a recurring tax that never goes away. The VP put it plainly: “It does happen every two weeks, so it’s repeat pain.” And the cost compounds in ways that aren’t obvious. When the support team doesn’t get their version fast enough, they ask publicly in Slack what shipped. Everyone sees it, the product team feels bad, and the support team looks uninformed. New hires on support are especially exposed because they don’t have the institutional context to figure it out themselves. When marketing doesn’t get their version, product updates don’t make it into customer-facing channels. Customers don’t hear about fixes. Renewals get harder because there’s no visible proof of progress. When leadership doesn’t get their version, they start scheduling more meetings to get caught up. Which takes time away from the person who’s already stretched thin doing all the rewrites. ## Why internal tools don’t solve it The teams we talk to have tried building their way out of this. The VP we spoke with has a Jira integration that pulls ticket data automatically. It saves time on step one. It doesn’t help with steps two through five. The data extraction is the easy part. The context translation is the hard part. An MCP that pulls from Jira gives you the raw material, but it doesn’t know that “fixed null pointer exception in billing module” should become “resolved an issue where some invoices displayed incorrectly” for customers and “we fixed the billing display bug, you can notify customers who reported this” for support. That translation requires product context, audience awareness, and judgment about what matters. It’s the thing that takes the most time and the thing that’s hardest to automate with general-purpose tools. ## Where an agent-first changelog fits The answer is not another place to copy the Jira export. It is a workflow where the agent can do the translation work and the changelog system can publish the approved result. That is the distinction between a raw MCP and Changebot’s MCP. A raw MCP can retrieve source material. Changebot turns the source material into audience-specific updates, gives you a review step, and publishes the final version to a hosted changelog, widget, Slack channel, or custom domain. You can ask for the customer version, the support version, and the leadership version in the same conversation. Then the canonical update still lands somewhere durable instead of staying trapped in a chat transcript. ## The real cost isn’t the writing The VP told us something that stuck: “We want to do more, but we can’t get to it because we’re stretched so thin.” The five rewrites problem doesn’t just cost time. It costs opportunity. Every hour spent translating the same information for different audiences is an hour not spent talking to customers, planning the next release, or doing the strategic work that a VP of Product should be doing. The cruelest part is that the person doing all this work is almost always the person who cares the most about communication. They’re the ones who championed release notes in the first place. They’re the ones who insisted the support team should know what shipped. And now they’re the bottleneck for every bit of it. At some point, working harder or writing faster stops being the answer. The real shift is recognizing that translating one piece of information into five outputs is a systems problem, not a writing problem. And systems problems need systems solutions. * * * If your team is rewriting the same updates for five different audiences every release cycle, [start free](https://app.changebot.ai/signup) and publish the first version to a hosted changelog. If you want to see the agent workflow, start with the [Changebot MCP example](/blog/publish-your-changelog-from-claude-code). [← Back to Blog](/blog) # Many Repositories, Many Products: The Holistic View Nobody Has URL: https://www.changebot.ai/blog/the-holistic-view-nobody-has/ Description: When your product spans five repositories, three teams, and two technology stacks, no single person can see the full picture of what shipped. Here's why that's a communication crisis. Last updated: 2026-01-13 Best Practices # Many Repositories, Many Products: The Holistic View Nobody Has [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder January 13, 2026 5 min read ![Illustration showing multiple repository sources converging from fragmented views into one unified holistic dashboard](/_astro/featured.Bvanj-gv_2j9J3g.webp) A Product Marketing Manager described her company’s product setup to me: a hardware product with a software dashboard, a separate software-only product with a larger engineering team, and a firmware team working on both — five repositories, three release cadences, and four teams. Her challenge? Combining updates across these systems into a coherent picture of what shipped. “Seeing that holistic view would be valuable,” she said. “Patterns across them in a way that only AI could see, because nobody at the business has the depth across every stream.” This is the multi-repo, multi-product problem. And it’s more common than you’d think. ## The fragmented reality Modern products are rarely monolithic. A typical mid-market software company might have: - A frontend repository for the web application - A backend repository for the API - A mobile repository (or two, for iOS and Android) - An infrastructure repository for deployment and tooling - Maybe a data pipeline or ML repository - Integration repositories for third-party connections Each repository has its own commit history, its own release cycle, its own team. Each one tells part of the story. None tells the whole story. A VP of Product at a financial analytics platform described this exact challenge. They have a data repo, a backend, a frontend, and a mobile app. When they tried to communicate what shipped, they’d announce a backend change without mentioning the frontend work that made it visible to users. Or they’d talk about the mobile app without connecting it to the backend capabilities that enabled it. The customer experience crosses all these boundaries. The communication about it shouldn’t stop at repository lines. ## The aggregation problem When a customer asks “what’s new,” they don’t care about your repository structure. They care about their experience. Internally, though, the people who know what shipped organize around those repositories. The frontend team knows what they built, and the backend team knows what they built, but nobody has the combined view. A Head of Engineering at one company admitted during our conversation: “To be honest, I know enough to feel like I’m giving good advice, but I would love to have a much more holistic understanding.” She was going into planning season and wanted to see patterns across engineering streams. It wasn’t possible without manually aggregating from six different sources. The math gets worse as you scale. A company with 15 repositories feeding into their product offering can’t reasonably expect any single person to track what’s happening across all 15. The cognitive load is too high. The context-switching is too expensive. “If I could just get a report of what happened across all 15 of these areas,” one product leader told me, “even that would be useful.” ## Multi-product complexity Repositories are one dimension. Products are another. A product marketer at a large enterprise company told me she’s responsible for approximately 20 significant products. Not features. Products. Each with its own engineering team, roadmap, and customers. She described needing to join calls just to understand what different teams were working on. There was no other way to gather the information. The alternative was flying blind. At a three-sided platform (serving shoppers, brands, and creators), the challenge was similar. Engineering ships constantly, but the product team doesn’t have visibility into most of it. “New features are just the tip of it,” a PM told me. “Our engineering team does way more than that.” When you multiply repositories by products by teams, the number of information sources becomes unmanageable. Nobody has the holistic view because having it would require being everywhere at once. ## Why this matters for communication The fragmentation isn’t just an internal inconvenience. It shows up in customer communication. When product updates come together piecemeal from different sources, they reflect that fragmentation: **Incomplete coverage.** The monthly recap mentions the frontend improvements but misses the backend performance work that made them possible. **Inconsistent framing.** The dashboard team describes their work one way. The mobile team describes theirs another way. The customer sees disconnected announcements instead of a coherent product evolution. **Delayed delivery.** Assembling updates from five or six sources takes time. By the time you’ve gathered everything, reviewed it, and published, you’re already behind on the next cycle. **Missed connections.** A firmware update enables a new hardware capability, which unlocks a new software feature. The customer sees three separate announcements instead of one story about expanded functionality. ## The net customer impact The real question isn’t “what did the backend team ship?” It’s “what’s the net customer impact across this work?” A product leader at a financial analytics company framed it well: instead of telling customers about backend changes they’ll never see, or limiting communication to just the frontend, they wanted to grab everything together and express the full experience. “Here’s how we process data now. Here’s how we display it in these charts. Here’s how it’s available in the frontend and the mobile app.” That’s a much richer story than any single repository could tell. Telling that story requires aggregation. It requires connecting work that happened in different places, by different teams, at different times, into a unified narrative about customer value. ## Building the holistic view The teams that solve this problem share a common approach: they aggregate at the source. Instead of asking each team to contribute their updates to a shared document (which creates coordination overhead and inconsistent quality), they pull from the places where work actually happens: code changes, merged PRs, and deployed releases — the artifacts that prove something shipped. Then they combine those signals across repositories and products. A change in the backend repository plus a change in the frontend repository plus a change in the mobile repository equals one customer-facing capability, expressed once, coherently. This isn’t about replacing human judgment. Someone still needs to decide which stories matter most, how to frame them for different audiences, what level of detail is appropriate. The raw material, though (the comprehensive view of what shipped across engineering streams), doesn’t require manual excavation from 15 different sources. ## The head of engineering’s wish The Head of Engineering who wanted a more holistic understanding had the right instinct. The patterns across streams are often more interesting than any single stream. Which areas are seeing the most activity? Where is engineering effort concentrated? How do changes in one system ripple into others? These questions matter for planning, for prioritization, for understanding where the product is actually going versus where leadership thinks it’s going. The same view that helps engineering leadership understand their organization also helps product marketing communicate with customers. It’s the same underlying data, just filtered and framed for different audiences. When nobody has the holistic view, everyone is working with partial information. Engineering makes decisions without understanding downstream impact. Product marketing communicates incomplete stories. Customers receive fragmented updates that don’t connect. The holistic view is the foundation for coherent communication at scale. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # The Hybrid Workplace's Hidden Product Challenge: Keeping Distributed Teams in Sync on What's Shipping URL: https://www.changebot.ai/blog/the-hybrid-workplaces-hidden-product-challenge/ Description: Remote and hybrid work solved the location problem, but created a new one: how do you keep distributed teams informed about what's actually getting built? Last updated: 2025-12-10 Best Practices # The Hybrid Workplace's Hidden Product Challenge: Keeping Distributed Teams in Sync on What's Shipping [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder December 10, 2025 5 min read ![Globe with location pins connected by information streams, showing fragmented communication flowing into unified channels](/_astro/featured.DPkoJhbE_f6375.webp) I recently spoke with a Director of Product at a company that builds workplace management software about the difficulty in maintaining high development velocity while keeping everyone internally in the loop. The irony wasn’t lost on either of us: a company that helps other organizations manage hybrid work was struggling with its own internal communication challenges. “Keeping people informed at the virtual watercooler” was how she described the core problem. In a distributed environment, the casual hallway conversations that used to spread information organically just don’t happen. ## The Office Used to Solve This In co-located teams, information traveled through proximity. You’d overhear a conversation about the feature engineering was building. You’d bump into a PM at the coffee machine and ask about the roadmap. You’d walk by a whiteboard covered in sprint planning artifacts. None of this was intentional knowledge sharing. Call it ambient awareness. It worked well enough that most companies never built explicit systems to replace it. Then everyone went home. ## The Async Communication Trap Hybrid and remote work promised flexibility, and it delivered. Yet it also created a communication vacuum that most companies filled with the wrong solution: more Slack messages, more emails, more meetings. A VP of Product Marketing at an analytics company told me she doesn’t want another tool or another destination. She wants context to appear inside the systems she’s already using. The problem with async work goes beyond lack of communication. People are communicating everywhere, and nothing connects. Your roadmap is in one tool. Your tickets are in another. Your code is in a third. Your announcements are in Slack, scattered across channels that people may or may not be in. Your documentation is somewhere, probably out of date. In a physical office, you could get away with this fragmentation because proximity created redundancy. You’d learn about that feature through three or four channels, even if none of them were the “official” one. In a distributed team, if you miss the Slack thread, you miss the information. ## Time Zones Make It Worse Add time zone spread, and the problem compounds. A PM in New York ships a feature at 5 p.m. Eastern. The announcement goes out in Slack. By the time the Singapore team wakes up, it’s buried under 200 other messages. The London team is in meetings all morning and doesn’t check until lunch. By then, the thread has gone cold. The information existed. Someone even shared it. The problem: it didn’t reach the people who needed it. This is why distributed teams end up with so many meetings. It’s the only way to guarantee that information reaches everyone. Synchronous time is scarce in a global team, so it gets packed with updates that would have happened organically in an office. Those meetings are expensive though. The cost shows up in time, and also in the flexibility that remote work promised to provide. ## The Documentation Burden Shifts In co-located teams, documentation was important but not critical. If the docs were stale, you could just ask someone. In distributed teams, documentation is infrastructure. If it’s not written down, it doesn’t exist for team members who can’t tap you on the shoulder. This creates an unfair burden on the teams doing the building. Not only do they have to ship the feature, they have to communicate it in a way that’s discoverable by colleagues across time zones who may not even know to look for it. A Head of Developer Relations at a startup described this perfectly: his docs and tutorials lag behind engineering velocity. The team is shipping faster than he can write about it. And he’s one person wearing many hats. ## What Distributed-First Companies Do Differently The companies that crack this treat information sharing as a first-class product problem, not an afterthought. **They automate the capture.** Instead of relying on humans to remember to announce things, they instrument the development process. When code ships, the context about what it does and why it matters gets captured automatically. **They push to where people are.** Instead of creating new destinations that people have to remember to check, they deliver information into existing workflows. If engineering lives in GitHub, the updates start there. If marketing lives in Slack, the updates flow there. If CS lives in a CRM, that’s where the information appears. **They create async-first artifacts.** Instead of defaulting to meetings, they default to written summaries that people can consume on their own schedule. Meetings happen for decisions and debate, while information transfer stays async. **They optimize for discoverability, beyond announcement.** Sending an update is only half the job. Making it findable later is the other half. A feature announcement that disappears into a Slack thread is noise, not documentation. ## The Irony Index I’ve started noticing something in my conversations with product leaders: the companies that are most thoughtful about workplace experience for their customers often struggle with the same problems internally. It makes sense. When you’re building a product, you’re focused on customer problems, not your own. Your internal tools and processes get less attention because they’re not the thing generating revenue. Your internal communication system directly affects your ability to ship though. If your distributed team can’t stay in sync on what’s getting built, you’re paying a tax on every feature: slower time to market, more rework, and more meetings to compensate. The companies that win in a distributed world will be the ones that treat internal product communication with the same rigor they apply to their customer-facing product. ## The New Normal We’re not going back to fully co-located teams. Hybrid is the default now, and that means the ambient awareness that offices used to provide must give way to something intentional. The question isn’t whether to invest in internal communication systems. It’s whether you build something intentional or accept the tax of constant catch-up meetings, stale documentation, and information silos. Your distributed team is already paying the cost of fragmented communication. The only question is whether you see it. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # The Meeting You Shouldn't Have to Attend URL: https://www.changebot.ai/blog/the-meeting-you-shouldnt-have-to-attend/ Description: There's a difference between meetings where you contribute and meetings where you're just extracting information. Product marketers shouldn't have to join calls just to learn what shipped. Last updated: 2026-01-07 Best Practices # The Meeting You Shouldn't Have to Attend [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder January 7, 2026 5 min read ![Calendar with meeting blocks contrasted with automatic notification feed](/_astro/featured.DB1UC68X_Z1mHNa7.webp) Not all meetings serve the same purpose. Some meetings are collaborative. You’re there to make decisions, debate trade-offs, coordinate on strategy. Your presence matters. Your input shapes the outcome. Other meetings are extractive. You’re there to absorb information that should have been available some other way. You’re not contributing. You’re downloading. That second kind of meeting? You shouldn’t have to attend it. ## “Sometimes I need to join the call to actually know what’s going on” A product marketer at a large enterprise company said this to me recently. She’s responsible for updates across 20 different products. To know what’s shipping, she has to join engineering syncs, sprint reviews, and cross-functional standups. She’s not there to give input on technical decisions. She’s there because it’s the only reliable way to learn what happened. This is shockingly common. In conversation after conversation, I hear variations of the same theme: - “I sit in on the dev standup so I don’t miss anything important.” - “I need to be in the room when they demo to leadership, otherwise I won’t know what to write about.” - “The only way I find out about bug fixes is if I happen to be on the call when someone mentions it.” These are smart, capable people spending hours per week in meetings where their primary function is listening. ## The calendar cost Let’s do some math. Say you’re a product marketer covering three products. Each product has a weekly sync where shipping decisions get discussed. That’s three hours a week, at least. You also need context from the engineering side, so you join the bi-weekly sprint review for each. Add another three hours. And there’s the monthly leadership update where new features get demoed. Another hour. That’s seven hours a week, nearly a full workday, just to stay informed about what shipped. Now imagine you’re covering 10 products. Or 20. The calendar fills up. The strategic work gets squeezed into the margins. And the meetings you actually need to contribute to? You show up exhausted and underprepared because you’ve been in back-to-back information extraction sessions all day. ## Why this happens The root cause is a visibility gap. In most organizations, there’s no single source of truth for “what shipped.” Engineering tracks their work in Jira or Linear. Some of that makes it to Slack. Some gets mentioned in standups. Some just… happens, and nobody outside the team ever hears about it. People cope. They build informal networks. They get invited to meetings where decisions happen. They develop relationships with engineers who give them a heads-up. It works, sort of. Until the organization grows and the informal networks can’t scale. Until the PMM covering three products becomes the PMM covering ten. Until the time spent extracting information crowds out the time needed to do something with it. ## The collaboration trap Here’s the insidious part: these meetings often feel collaborative. You’re in the room, people ask your opinion, and you contribute a comment here and there. It feels like you’re participating. Ask yourself: if you had perfect visibility into what shipped, would you need to be in this meeting? For most “stay informed” meetings, the answer is no. You’re there because of an information gap, not because the team needs your expertise. Real collaboration meetings are different: you’re debating positioning, syncing on launch timing, or working through customer objections. The meeting exists because different perspectives need to converge on a decision. The test is simple: are you there to give, or are you there to get? ## What changes when visibility improves Teams that solve the visibility problem describe a transformation in their meetings. Instead of spending 45 minutes scrolling through what shipped, everyone shows up already informed. They’ve seen the automated updates. They know what’s new. The meeting immediately jumps to: “Here are the two things we actually need to discuss.” A product marketer told me her meetings used to be “lengthy calls to debate product value forever.” People were processing information in real-time, so every item became a discussion. Give people the information in advance, and suddenly they come prepared with focused questions instead of exploratory ones. Another described the shift this way: “Before, I was a human router, sitting in meetings so I could carry information to other meetings. Now I actually have time to think about what the information means.” ## Declining with confidence There’s a psychological barrier to declining meetings, especially for product marketers who need to maintain relationships across the org. When you have reliable visibility into what shipped, you can decline with confidence. “I saw the update on the dashboard. Looks like the new API endpoints shipped. I’ll reach out if I have questions about the customer messaging.” “I reviewed the recap before the meeting. I’m good on everything except the pricing change. Can we do a quick 15 minutes on that specifically?” You’re not out of the loop. You’re not missing context. You’re just choosing to consume information asynchronously and reserve synchronous time for actual collaboration. That’s not being a bad team player. That’s being efficient. ## The meeting audit Here’s an exercise: look at your calendar for the past two weeks. For each meeting, ask: 1. Did I contribute something that changed the outcome? 2. Or was I primarily absorbing information? For the information-absorption meetings, ask: could I have gotten this information another way? If the answer is “yes, if someone had just written it down” or “yes, if there was a reliable update feed,” then you’ve identified a meeting that shouldn’t need to exist. The goal is to attend the right meetings, the ones where you’re genuinely collaborating, and get the information from other meetings through more efficient channels. ## Freeing up the calendar The time you get back from unnecessary meetings is significant. But even more significant is the mental energy. Context-switching between back-to-back meetings is exhausting. Every meeting has its own frame, its own participants, its own emotional register. By the fifth meeting of the day, you’re barely absorbing anything. Free up the extraction meetings, and you have time for deep work. Time to actually think about positioning. Time to craft messaging that resonates. Time to do the strategic work that product marketing exists to do. You shouldn’t have to attend a meeting to learn what your own company shipped. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # The Missing Knowledge Graph: Why No One Knows What Shipped URL: https://www.changebot.ai/blog/the-missing-knowledge-graph/ Description: Organizations have rich data in GitHub, Jira, Docs, and Slack. But none of it connects. Here's why the missing knowledge graph is your biggest communication problem. Last updated: 2025-12-01 Best Practices # The Missing Knowledge Graph: Why No One Knows What Shipped [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder December 1, 2025 6 min read ![Disconnected tool icons unified by a central code node forming a knowledge graph](/_astro/featured.WuaH5QsV_zWm7f.webp) “There’s no such thing as a common knowledge graph within any organization today.” A Product Ops lead said this to me during a recent conversation, and it crystallized something I’ve been noticing across dozens of customer calls. Every organization has rich data about what they’re building. GitHub contains commits, PRs, and code reviews. Jira or Linear contains tickets and epics. Docs contain specs and requirements. Slack contains decisions and context. Yet none of it connects. The graph exists in fragments, and the connections between fragments live only in people’s heads. ## The Fragmentation Problem Consider what happens when a VP of Product Marketing needs to know what shipped last month: 1. Check the releases Slack channel for announcements 2. Scan Jira for completed tickets 3. Ask a PM what the commits actually mean 4. Look at the changelog (if one exists) 5. Schedule a meeting to fill in the gaps A VP of Product Marketing at an observability company described this exact experience: “We have a releases Slack channel, a love channel, a changelog page — and we still have to hunt across all these sources for meaningful updates.” Each source contains part of the truth. None contains the whole truth. And critically, none of them links to the others in a way that’s discoverable. ## Rich Data, Poor Annotation The frustrating part is that the data exists. The GitHub graph alone contains enormous amounts of information: - Every commit shows what changed - Every PR shows why it changed - Every review shows what the team debated - Every merge shows what the team decided As one Product Operations leader put it: “The GitHub graph has a lot of information. It lacks good annotation. It also lacks good linking.” A commit message might say “Fix login bug.” But it doesn’t say: - Which customers this bug affected - Which support tickets this addresses - What the business impact was - How this relates to the broader initiative The technical record is complete. The business context is missing. ## The Meeting Tax When graphs don’t connect, meetings become the bridge. Organizations compensate for missing knowledge graphs by scheduling sync meetings. A Director of Product described her release process as involving three or four meetings per week — not to make decisions, but to share status updates that a connected system should provide automatically. The meetings exist because there’s no other way to answer basic questions: - What’s shipping this sprint? - Why did we pick this? - Who needs to know about this change? A Head of Developer Relations at a startup told me his goal was to “reduce reliance on lengthy cross-team meetings to learn what shipped.” He wears many hats, and every meeting is time not spent on documentation, content, or community building. The meeting tax is real: a 12-person weekly sync costs 450+ hours annually. And it exists primarily because the knowledge graph is missing. ## The Downstream Cascade Missing knowledge graphs don’t just slow things down. They cause cascading failures across the organization. **Customer Success scrambles.** When a customer asks about recent improvements, CS has to hunt for information. They Slack the PM. The PM checks with engineering. Engineering points to a Jira ticket. The ticket says “build feature X.” Nobody can explain the customer benefit. **Marketing works blind.** Product marketers try to create campaigns about features that shipped weeks ago. They’re guessing at the value proposition because nobody documented the “why.” **Support gets surprised.** Features ship without support knowing. The first time they hear about a change is when a customer submits a ticket about it. **Investors get vague updates.** Leadership can’t show concrete progress because they can’t easily aggregate what shipped across teams. A CEO at a fintech company told me: “We built a truckload of work and the business side didn’t communicate it well internally or externally.” The information was there — it just wasn’t connected. ## Why Integration Isn’t the Answer The obvious solution is to integrate everything. Connect GitHub to Jira to Slack to Docs. Build the missing links between systems. Integration creates its own problems: 1. **Security constraints.** Enterprise organizations have strict vendor policies. A Product Operations leader at a large company described how security stance and vendor budgets make it hard to onboard tools with broad access. 2. **Budget silos.** Different teams have different software budgets. The revenue team might have Gong and Salesforce. The product team has different tools entirely. Connecting everything requires cross-team buy-in that rarely happens. 3. **Maintenance burden.** Every integration is another thing to maintain. When Jira changes its API or Slack introduces new features, someone has to update the connections. 4. **Lowest common denominator.** Integration tools tend to move data around, not understand it. They can push a Jira ticket ID into a Slack message, but they can’t explain what the ticket means for customers. Integration connects graphs. It doesn’t create understanding. ## The Code as Foundation Here’s a different approach: start with the one source that’s always accurate and always complete — the code. The code tells you what actually happened. Not what you planned (that’s the spec). Not what you discussed (that’s Slack). Not what you tracked (that’s Jira). What actually shipped. Every commit is a decision. Every PR is a choice. Every merge is a reality. When you start from code and work outward, four things change: **You have a ground truth.** The code doesn’t lie. It might be messy, but it represents what actually exists. **You can infer context.** Code changes don’t exist in isolation. They relate to previous changes, to patterns in the codebase, to the evolution of the product over time. **You don’t need perfect data entry.** You’re not depending on humans to remember to update a ticket or announce in Slack. The code captures the change automatically. **You can annotate after the fact.** Once you have the foundation, you can layer context on top. “This commit relates to the Q3 initiative” is easier to add when you already have the commit captured. ## Building the Graph Bottom-Up Traditional approaches try to build knowledge graphs top-down: define the schema, create the integrations, mandate adoption. The alternative is bottom-up: start with what exists, extract meaning, and build connections from there. This means: - Reading every commit to understand what changed - Connecting changes to each other over time - Inferring customer value from technical changes - Building a model of the product as it actually exists One surprising finding: you can get further than expected with just code-level data. The customer value, the strategic fit, the cross-functional impact — you can infer much of this by understanding the codebase deeply enough. A company doesn’t need to integrate ten tools. It might just need to understand one deeply. ## What a Connected Graph Enables When the knowledge graph exists, questions become answerable: - “What did we ship for enterprise customers last quarter?” - “How does this release address the feedback from the advisory board?” - “What’s the velocity trend across our platform team?” - “Which improvements relate to our Q3 objectives?” These questions currently require meetings or archeology. With a connected graph, they become searches. More importantly, updates become automatic. Instead of hunting across Slack and Jira and asking PMs, the system knows what shipped and can tell stakeholders proactively. The graph doesn’t remove the need for human judgment. It removes the need for human memory. ## The Path Forward Building a knowledge graph sounds like a massive undertaking. But it doesn’t have to be. Start with the foundation: understand what ships, at the code level. That’s the one piece that’s guaranteed to be accurate. Then add context incrementally: connect code changes to customer value, features to initiatives, and initiatives to strategy. You don’t need perfect integration across every tool. You need a foundation that’s trustworthy, plus the ability to layer context as it becomes available. The organizations that figure this out first will have a significant advantage. While competitors are still scheduling meetings to learn what shipped, they’ll have answers on demand. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # The Non-Technical Founder's Update Problem URL: https://www.changebot.ai/blog/the-non-technical-founders-update-problem/ Description: You know your product is shipping. You just can't see it. When every customer update requires interrupting your engineering cofounder, most updates don't happen. Last updated: 2026-01-23 Best Practices # The Non-Technical Founder's Update Problem [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder January 23, 2026 4 min read ![Split illustration showing engineering artifacts on one side and a polished newsletter on the other, with a figure bridging the gap](/_astro/featured.EnJOzac9_ZxUHyI.webp) I’m in a seat a lot of founders know well. I’m not the one writing the code. My cofounder builds. I do everything else. Marketing, sales, customer conversations, positioning, strategy. And somewhere amid that, I’m supposed to tell customers what we shipped. The problem is… I don’t always know what we shipped! Not because my cofounder isn’t doing the work. He’s shipping constantly. But translating “what changed in the codebase” into “what customers should know” requires a conversation. Every time. And every conversation is an interrupt. ## The interrupt tax Here’s the workflow when a non-technical founder wants to communicate a product update: 1. Notice that something shipped (maybe from a Slack notification, maybe from a passing comment) 2. Ask the engineer to explain what changed 3. Wait for the engineer to context-switch out of whatever they’re building 4. Listen to a technical explanation 5. Ask clarifying questions (“But what does that mean for the user?”) 6. Translate the explanation into customer-friendly language 7. Write the update 8. Distribute it Each step is a friction point. Steps 2-5 are an interrupt that the engineer resents, even if they don’t say so. And this process repeats for every single change worth communicating. The rational response? Skip it. Ship silently… and tell yourself you’ll batch the updates later. (We all know how “later” works in a startup.) ## The knowledge asymmetry A founder recently described this gap perfectly. He’s watched other founders send weekly updates about everything, even bugs, and seen customers love it. He’s the marketing half of the founding team. Every piece of product communication requires pulling information out of engineering, and that “pull” has a cost. This is what someone fancy might call a “structural asymmetry,” the person with the context (what changed and why) isn’t the person in front of the audience (customers, prospects, investors). And, the bridge between them is a conversation that both sides find inconvenient. At one startup I spoke with the CEO told me he didn’t have a clear view of everything engineering was building. Features would ship and he’d learn about them later. His team tracked things in Notion and Slack, but there was no structured way for the non-technical team to see what went out the door. At another, a non-technical cofounder needed to communicate progress to investors and customers but couldn’t parse engineering’s release notes. The work went uncredited because the translation step never happened. ## The marketing founder’s dilemma If you’re a non-technical founder with marketing skills, you’re in an odd position. You know exactly how to position updates. You know the voice, the audience, and you can write compelling copy. You just don’t have the raw material. The information lives in pull requests, commit messages, and Jira tickets that engineers wrote for other engineers. Reading them requires technical context you may not have. And asking your cofounder to translate every PR description into plain English is a tax neither of you can afford to pay consistently. One founder told me he could probably never need to hire a product marketing person if he could just get structured, understandable summaries of what engineering shipped. He has the marketing acumen, the distribution channels, and the voice. He’s just missing the input. The irony is that the information exists. It’s in the code changes, the ticket descriptions, the branch names. It’s just locked in a format that only engineers can read. ## The compounding silence This problem doesn’t stay small. In the early days of a startup, the founders sit next to each other (literally or on Slack). Communication is ambient; you absorb what’s happening and updates flow naturally. As the team grows, even slightly, that ambient awareness breaks down. The non-technical founder starts needing formal mechanisms to learn what shipped. Meetings. standups. “What did you work on this week?” conversations. Each mechanism adds overhead. Each overhead makes communication feel harder. And the gap between what ships and what customers learn about grows wider. At one company, the business side described shipping a “truckload” of work that was never communicated externally. The engineering team built it, but the business team didn’t know how to talk about it, and customers had no idea. ## Closing the gap without more interrupts The answer isn’t “schedule more syncs between engineering and marketing.” That adds more of the thing that’s already too expensive. The answer is removing the human translation layer from the critical path. The information about what changed and why exists in the tools engineering already uses. Pull requests describe changes, tickets describe intent, and commits describe implementation. If that information can be automatically summarized in language a non-technical founder can read, review, and publish, the interrupt disappears. Engineering keeps building. The founder keeps communicating. Neither has to stop what they’re doing to serve the other’s workflow. The best version of this looks like opening a dashboard and seeing: “Here’s what your team shipped this week, in plain English, ready for you to review and send to customers.” No meetings. No interrupts. No decoding commit messages. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # The PM Accountability Gap: Why Documentation Falls Through the Cracks URL: https://www.changebot.ai/blog/the-pm-accountability-gap/ Description: Product managers hate documentation. They know it's important, but it's never urgent enough to rank highly. Here's why this gap exists and what to do about it. Last updated: 2025-12-16 Best Practices # The PM Accountability Gap: Why Documentation Falls Through the Cracks [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder December 16, 2025 3 min read ![A visual gap showing code and shipped features on one side, empty documents and waiting stakeholders on the other](/_astro/featured.DCbRX0f0_Z2oXN2c.webp) “PMs hate creating product documentation and frequently forget.” A Director of Product told me this during a recent discovery call, and the bluntness was refreshing. She wasn’t being critical of her team. She was describing reality. ## The Universal Truth Nobody Wants to Admit Every product leader I talk to eventually confesses some version of this. The words change, but the sentiment is consistent: - “Documentation is always the last priority.” - “We have to chase PMs to update the changelog.” - “By the time we document something, we’ve already shipped three more features.” A Head of Developer Relations at a startup put it this way: their docs and tutorials “lag behind engineering velocity.” The team is shipping faster than anyone can write about it. At an enterprise data management company, the documentation burden is so significant that it’s actively blocking them on the path to continuous delivery. They know CI/CD would help them ship faster, but they can’t figure out how to keep up with the release notes. ## Why This Happens PMs aren’t lazy. They’re rational. When you’re juggling roadmap planning, stakeholder coordination, customer calls, and sprint syncs, documentation feels like overhead. It doesn’t move the needle on the metrics you’re measured against. It doesn’t unblock engineers. It doesn’t close deals. It waits. And waits. And then you’re three releases behind and the task of catching up feels insurmountable. You do a half-hearted summary, promise yourself you’ll be more disciplined next time, and repeat the cycle. ## The Compounding Cost Here’s what documentation debt actually costs you: **Customer Success scrambles.** When a customer asks “what changed in the last release?” your CS team has to go hunting. They Slack the PM. The PM checks with engineering. Engineering points to a Jira ticket. The ticket says “build feature X.” Nobody knows how to explain it to the customer. **Marketing works from stale information.** Your product marketers are trying to create campaigns about features that shipped weeks ago. They’re guessing at the value prop because nobody documented the “why.” **Sales loses deals.** Prospects ask “what have you shipped recently?” and your team fumbles. Meanwhile, your competitor has a changelog that shows weekly updates. They look more active, more invested, more alive. **Onboarding new team members takes longer.** Every new PM has to learn the product through archaeology, piecing together context from scattered tickets and tribal knowledge. ## The Meeting Tax Most companies try to solve this with meetings. Weekly syncs. Release readiness reviews. Cross-functional standups. The theory is that if you bring everyone together often enough, information will flow. A Director of Product described their release process as “absurdly cumbersome” with three or four sync meetings just to track what’s shipping. The irony: the meetings exist because documentation is lacking, but the meetings consume time that could go toward documentation. It’s a tax that compounds. More features mean more meetings, which mean less time, which means worse documentation — which means even more meetings. ## Breaking the Cycle The answer isn’t “be more disciplined about documentation.” That’s like telling someone to “just eat healthier.” True, but not actionable. The answer is removing documentation from the critical path entirely. What if the act of building the feature was the documentation? What if merging a PR automatically captured the context, the intent, the customer value? This is already possible. The information exists in the code changes, the commit messages, the PR descriptions, the context of what came before. The problem isn’t that PMs won’t document. The problem is that documentation is a separate task that requires context-switching, memory, and time. Remove those barriers, and the gap closes itself. ## What Actually Works Teams that solve this problem share a few traits: 1. **They automate the capture.** They don’t ask humans to remember what they shipped. They instrument the development process to capture it automatically. 2. **They separate “what happened” from “what to say.”** The raw facts of what changed get captured automatically. Humans with time can then refine the narrative and positioning. 3. **They make updates visible by default.** Instead of documentation being something you have to seek out, it shows up where people already work: Slack, email, the product itself. 4. **They stop pretending meetings will fix it.** Meetings are for decisions and coordination, not information transfer. If you’re using meetings to learn what shipped, you’ve already lost. The PM accountability gap is a systems problem, not a character flaw. Fix the system, and the gap disappears. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # The PM as Automation: Why Product Managers Build Systems That Break URL: https://www.changebot.ai/blog/the-pm-as-automation/ Description: PMs create bespoke spreadsheets and processes to track what's shipping. Then they become the automation themselves. Here's why that doesn't scale. Last updated: 2025-12-03 Best Practices # The PM as Automation: Why Product Managers Build Systems That Break [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder December 3, 2025 5 min read ![Silhouette trapped in gears versus silhouette overseeing automated machinery](/_astro/featured.MRbH_XSJ_1AN4CC.webp) A Product Operations lead at a large developer tools company recently described a pattern I’ve seen at every organization I’ve worked with: “PMs kind of create their own systems. They tend to think, I need to solve this problem with generic tools — like spreadsheets. And then they are the automation.” Read that last part again. They are the automation. The PM builds a spreadsheet to track releases. The PM builds a process to gather updates from engineering. The PM builds a workflow to notify stakeholders. And then the PM becomes the single point of failure for it all. ## The Spreadsheet Trap Here’s how it typically starts: 1. A PM needs to know what’s shipping this sprint 2. There’s no good system for this, so they create a spreadsheet 3. The spreadsheet works great — for that PM, for that sprint 4. Other people start asking for access 5. The PM becomes responsible for keeping it updated 6. The PM leaves or gets busy, and the spreadsheet rots I’ve seen this pattern play out dozens of times. A Director of Product at a workplace software company told me their PMs “hate creating product documentation and frequently forget.” The bespoke systems they build are no different — maintained only as long as someone has bandwidth. PMs aren’t bad at building systems — building systems simply isn’t their job. Every hour spent maintaining a release tracking spreadsheet is an hour not spent talking to customers or shipping product. ## Why Every PM Does This Differently Walk into any mid-sized company and ask three PMs how they track releases. You’ll get three different answers: - PM 1 uses a Notion database - PM 2 uses a Google Sheet with custom scripts - PM 3 just reads Slack and remembers None of these systems talk to each other. None of them survive that PM moving to another team. And none of them scale beyond a single person’s cognitive load. A VP of Product Marketing at an observability company described the downstream effect: “We have a releases Slack channel, a love channel, a changelog page — and we still have to hunt across all these sources for meaningful updates.” The information exists, fragmented across every PM’s personal system. This fragmentation happens because there’s no standard way to answer a simple question: what shipped? ## The Meeting Tax When personal systems fail, organizations compensate with meetings. A Director of Product described her company’s release process as “absurdly cumbersome” — three or four sync meetings per week just to track what’s shipping. The meetings exist because no system reliably captures the information. This is the hidden cost of the PM-as-automation model. When the PM is the system, the only way to extract information is to talk to the PM. Scale that across ten PMs and twenty stakeholders, and you’ve built a company that runs on status meetings. One Head of Developer Relations at a startup put it simply: his goal was to “reduce reliance on lengthy cross-team meetings to learn what shipped.” He wears many hats, and every hour in a meeting is an hour not spent on docs, content, or community. ## The Unmaintained System Problem Bespoke PM systems have a half-life measured in months. Consider what happens when: - The PM who built the system leaves the company - The PM gets promoted and no longer has time to maintain it - The scope grows beyond what one person can track - Someone asks a question the system wasn’t designed to answer In each case, the system becomes technical debt. It’s too useful to delete, but too outdated to trust. Teams start working around it, building their own parallel systems, and the fragmentation compounds. At an enterprise data management company, the documentation burden is significant enough that it’s actively blocking their path to continuous delivery. They know CI/CD would help them ship faster, but they can’t figure out how to keep up with the release notes. Their PM systems weren’t built for that velocity. ## The Standardization Paradox Here’s the uncomfortable truth: you can’t standardize PM systems by asking PMs to use the same tools. Every PM has different needs, different team structures, different communication preferences. The spreadsheet that works for a platform team doesn’t work for a growth team. The Notion database that works for a startup doesn’t scale to an enterprise. And yet, without standardization, you can’t get reliable, organization-wide answers to basic questions: - What shipped last month? - What’s coming in the next release? - Which features address the feedback customers gave us? A Product Operations lead described the challenge: “How do you standardize outputs so different PMs don’t get wildly different summaries from the same data?” You can’t solve this by buying another tool and asking PMs to use it. They’ll customize it into another bespoke system within weeks. ## The Alternative: Systems That Don’t Need PMs The answer isn’t better spreadsheets or more disciplined PMs. It’s removing PMs from the automation loop entirely. What if the system that tracks releases doesn’t require anyone to update it? What if it captures what ships automatically, directly from the source — the code? This shifts the PM’s role away from data entry and toward quality control. Instead of building and maintaining tracking systems, they review and refine outputs. Instead of answering “what shipped?” they answer “why does it matter?” Teams that make this shift share a few patterns: 1. **They instrument the development process.** The act of shipping something automatically captures context about what it does. 2. **They separate capture from curation.** Raw data about what changed gets captured automatically. Humans with context refine the narrative. 3. **They make outputs consistent by default.** Different PMs get similar summaries because the system (not the individual) defines the format. 4. **They accept imperfection.** An 80% accurate automated summary is better than a 100% accurate manual summary that never gets written. ## Shifting the PM’s Role The PM-as-automation model assumes PMs should build communication systems. But building systems is hard, and maintaining them is harder. PMs are better at understanding customers and making decisions than they are at data engineering. The alternative model treats PMs as editors, not authors. The system drafts and the PM refines; the system captures and the PM curates; the system distributes and the PM decides what’s important. The goal here is applying PM judgment to the right problems. PMs waste their insight about customer value when they’re copying text from Jira tickets into a spreadsheet. ## Breaking the Cycle If you recognize your organization in this post, here’s the pattern to break: 1. **Audit your bespoke systems.** How many spreadsheets, Notion databases, and custom workflows exist? Who maintains them? 2. **Count the meetings.** How many recurring meetings exist primarily to share status updates that systems should provide? 3. **Find the single points of failure.** Which PMs would cause chaos if they went on vacation for two weeks? 4. **Identify what’s actually needed.** Strip away the custom systems and ask: what questions do stakeholders actually need answered? The PM who builds the perfect release tracking system is solving the wrong problem. The right problem is making release tracking automatic. Your PMs are too valuable to be spreadsheets. Stop asking them to be. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # The Release Communication Death Spiral: More Meetings Won't Fix It URL: https://www.changebot.ai/blog/the-release-communication-death-spiral/ Description: When teams don't know what's shipping, they add meetings, which leaves less time to document, which means even more meetings. Here's how to break the cycle. Last updated: 2025-12-21 Best Practices # The Release Communication Death Spiral: More Meetings Won't Fix It [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder December 21, 2025 4 min read ![A spiral vortex with calendar and meeting icons multiplying, representing the destructive cycle of meeting overload](/_astro/featured.B-yMVFGy_Ziwp4x.webp) A Director of Product recently described her company’s release process as “absurdly cumbersome.” Three or four sync meetings per week. Status updates on status updates. A whole infrastructure of communication about what’s getting built. She wasn’t complaining about the complexity of their product. She was describing the overhead of just keeping people informed about it. ## The Spiral Here’s how it starts: 1. Marketing needs to know what’s shipping so they can prepare campaigns. 2. Nobody documents what’s shipping consistently. 3. Marketing schedules a weekly sync to ask engineering directly. 4. Engineering finds these meetings disruptive, so they send a PM instead. 5. The PM doesn’t have all the details, so engineering joins anyway. 6. Customer Success hears about the meeting and asks to join. 7. Sales has questions too, so they get added. 8. Now it’s a 12-person meeting that runs 45 minutes every week. 9. Half the attendees are there “just in case” something relevant comes up. 10. The other half are multitasking because most of the content isn’t relevant to them. Sound familiar? A Head of Developer Relations at a startup told me one of his goals was to “reduce reliance on lengthy cross-team meetings to learn what shipped.” He wears many hats, and every hour in a meeting is an hour not spent on docs, content, or community. At an enterprise software company planning a move to CI/CD, the documentation burden is the primary blocker. They know they can ship faster technically. They can’t figure out how to communicate faster. ## The Math Doesn’t Work Let’s do the math on that 12-person weekly meeting: - 12 people × 45 minutes = 9 hours of collective time - 9 hours × 50 weeks = 450 hours per year - At a blended rate of $100/hour, that’s $45,000 annually For one meeting. About one topic. Now multiply that by every cross-functional sync, every release readiness review, every “quick check-in” that runs long. And here’s the thing: these meetings exist because the information isn’t flowing any other way. They’re a symptom, not a solution. Adding more meetings to fix an information problem is like adding more gas to fix a leaky tank. ## Why Meetings Feel Necessary Meetings persist because they solve an immediate problem: someone needs information and can’t get it elsewhere. When a product marketer asks “what’s shipping in the next release?” and there’s no reliable answer, a meeting gets scheduled. When a CS lead needs to prep for a QBR and doesn’t know what shipped, a meeting gets scheduled. When the CEO wants a board update on product velocity and no one has the numbers, a meeting gets scheduled. Each meeting makes sense in isolation. In aggregate, they’re a tax on everyone’s productivity. A VP of Product Marketing at an analytics company put it bluntly during a conversation: she doesn’t want another tool or destination. She wants context to show up inside the systems she’s already using, at the moment she needs it. The meeting exists because the information doesn’t flow to where she needs it. ## The CI/CD Amplifier This problem gets exponentially worse as you ship faster. On a quarterly release cycle, you can survive with a few sync meetings. Painful, but manageable. Move to monthly releases, and the meeting load doubles. Move to weekly, and it becomes untenable. Move to continuous delivery, and you’ve either solved the information problem or you’ve drowned in update meetings. An engineering director at an enterprise company said this explicitly: the documentation overhead is what’s preventing them from adopting CI/CD. They can deploy faster. They can’t communicate faster. This is the hidden cost of shipping velocity. The faster you build, the faster you need to communicate. If your communication is meeting-dependent, you hit a wall. ## What Actually Works Teams that escape the spiral share a few patterns: **They make information pull, not push.** Instead of scheduling meetings so people can ask questions, they create systems where the answers are already available. Stakeholders can find what they need without waiting for a calendar slot. **They instrument the development process.** The act of shipping something captures the context about what it does and why it matters. Documentation becomes part of the build, not a separate step that teams can skip. **They deliver information where people work.** If marketing lives in Slack, updates go to Slack. If CS lives in Salesforce, updates surface there. The information comes to the person, not the other way around. **They reserve meetings for decisions.** Meetings are expensive. Use them for things that require real-time collaboration: decisions, coordination, problem-solving. Information transfer should happen asynchronously. ## The Test Here’s a simple test for whether you have a meeting problem: Count how many meetings on your calendar exist primarily to share status updates or learn what’s happening in another part of the organization. If the answer is more than zero, you have a systems problem masquerading as a coordination need. The information those meetings convey already exists somewhere. It’s in tickets, in PRs, in roadmaps, in someone’s head. The meeting exists because that information isn’t flowing to where it needs to go. Fix the flow, and the meetings disappear. Keep scheduling meetings, and the spiral tightens. Your team’s time is finite. Every hour spent in an update meeting is an hour not spent building, selling, or supporting. The math only works if you break the cycle. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # The Soul of Your Company URL: https://www.changebot.ai/blog/the-soul-of-your-company/ Description: Your product announcements reveal the soul of your company—are you a slow turtle or a cool rabbit with sunglasses? Last updated: 2025-05-15 Best Practices # The Soul of Your Company [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder May 15, 2025 2 min read ![The Soul of Your Company](/_astro/featured.DEptH9Vf_1UbRzh.webp) [Play](https://youtube.com/watch?v=rK1TsDW6R5M) Your product announcements are a glimpse into the soul of your company. Some product announcements say “our soul’s like a turtle. Well-meaning, but slow and ineffective.” ![A realistic turtle representing a slow, well-meaning but ineffective company approach to product announcements](/_astro/turtle.k040LXS4_Z1yucLR.webp) What you want your product announcement to say is that we’re a rabbit, like a cool rabbit with sunglasses on. ![A cool rabbit wearing sunglasses representing a fast, effective company approach to product announcements](/_astro/rabbit.D_7lmuyH_Z23I8fg.webp) Before today, Changebot already helped your product announcements feel like a cool rabbit by connecting to your GitHub account and looking for any interesting change that your customers might be interested in. When Changebot sees something that your customers and leads will care about, we’ll write a product update for you. If it looks great, (which we know it will), we’ll also help you share it with the world. Because what’s the point of building the feature if you’re not gonna write an update? And what’s the point of writing an update if you’re not gonna share it with the world? But wait, you might have noticed, I’ve just talked about how Changebot turns your turtle company into a super cool rabbit, but where’s the sunglasses? Well, today I’m excited to announce two new product update styles directly in Changebot. You can continue to use our default design, which we’ve creatively named default. However you might find that our two new designs have even more sunglasses, power. This next design called Kitty allows you to add an icon and a brand color to better match your company’s brand. Wow. Look at those containers. Our third design called headwind also allows you to add a color and icon, but features more of a vertical vibe perfect for teams with tons of updates. Ready to be a cool rabbit with sunglasses? Here’s my offer to you: **For $1,200 a year Changebot will generate over 200 pieces of high-converting, revenue-boosting, churn-destroying, trust-building content that your customers will love to turn your product momentum into revenue growth**. [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # The Support Team's Secret Channel: When Your Own Team Doesn't Know What Shipped URL: https://www.changebot.ai/blog/the-support-teams-secret-channel/ Description: Support teams often create workarounds just to learn about small releases. This signals a systemic communication failure that affects everyone. Last updated: 2025-12-17 Best Practices # The Support Team's Secret Channel: When Your Own Team Doesn't Know What Shipped [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder December 17, 2025 5 min read ![Support agent desk showing contrast between sparse official inbox and overflowing secret channel sidebar with sticky notes and chat messages about small fixes](/_astro/featured.BIG96wNS_hwOOd.webp) During a recent product demo, a VP of Engineering mentioned something that stopped me cold. “We actually created a whole channel just for small stuff that support doesn’t know about,” he said. “Because we would only publish the big stuff.” Let that sink in — a team had to create a separate communication channel just to learn about changes their own company made. Not external changes or third-party integrations, but their own product updates. This isn’t unusual. I hear variations of this story at almost every company I talk to. ## The Pattern Here’s how it typically unfolds: 1. Engineering ships a small bug fix or minor improvement 2. It’s not “big enough” for the official release notes 3. No one tells support 4. A customer contacts support about it 5. Support has no idea what they’re talking about 6. Support scrambles to find someone who knows 7. The customer waits while support investigates their own product 8. Eventually someone figures it out 9. Repeat dozens of times per month After enough cycles, someone in support gets frustrated enough to create a workaround: a Slack channel, a shared doc, a weekly email, something to capture the “small stuff” that falls through the cracks. The workaround helps. But it shouldn’t be necessary. ## Why Small Releases Matter to Support Big releases get attention. They have launch dates, documentation, training sessions. Everyone knows about them. Small releases are different. They ship quietly. A bug fix here, a UX tweak there, a performance improvement that makes something 20% faster. Individually, none of them seems worth announcing. From support’s perspective, though, these small releases matter enormously: **They close open tickets.** A customer reported a bug. Engineering fixed it. But support doesn’t know, so they keep working around the issue instead of closing the ticket. **They prevent unnecessary escalations.** Without knowing a fix shipped, support escalates issues that are already resolved, wasting everyone’s time. **They affect troubleshooting.** When support doesn’t know what changed, they can’t distinguish between “this is a new bug” and “this behavior comes from the recent update.” **They impact customer perception.** Telling a customer “I’ll check with engineering” five times in a week makes the company look disorganized. Support should know. ## The Downstream Cascade A CEO at a fintech company described how support learns about fixes late, slowing triage. The problem isn’t just support’s, it cascades everywhere: **Customers wait longer.** Resolution times increase when support has to investigate internally before helping. **Ticket volume increases.** The same issue gets reported again and again because support isn’t proactively closing related tickets. **Trust erodes.** Customers start to wonder: if your own support team doesn’t know your product, how good can it be? **Knowledge silos deepen.** Workaround channels create yet another place information might live, making it harder to find later. ## Why This Keeps Happening The root cause is a mismatch between what seems worth announcing and what support actually needs to know. Product and engineering make announcements based on significance: Is this a major feature? A breaking change? Something marketing should know about? Support needs information based on relevance: Will customers ask about this? Does this affect open tickets? Could this cause confusion? These are different filters. A database index improvement (high significance, low relevance) might get announced. A small bug fix (low significance, high relevance) might not. ## The Communication Tax Organizations that recognize this problem often try to solve it with process: - “Before you close a ticket, check the release notes” - “Engineering should tag support-relevant PRs” - “Product should review every fix with support” Each of these adds overhead. Each creates friction. Each depends on someone remembering to do something. A Product Operations lead at a major tech company described it: “There’s no relationship with what was actually put into a PR and documentation.” The system for shipping code and the system for communicating about code operate independently. Process bridges can’t fully close that gap. They require constant maintenance and perfect execution. Something always slips through. ## What Support Actually Needs When I ask support leaders what would help, the answers are consistent: **Timely.** They need to know within hours, not days. By the time a weekly summary arrives, they’ve already handled tickets without the information. **Complete.** They need all changes, not just the “significant” ones. Support doesn’t get to choose which issues customers will ask about. **Contextual.** They need to understand impact, not implementation. “Fixed null pointer in auth handler” doesn’t help. “Login issues for users with special characters in passwords are now resolved” does. **Searchable.** When a customer describes a symptom, support should be able to search and find if a relevant change shipped. **Automatic.** It shouldn’t depend on someone remembering to notify them. The information should flow as a byproduct of shipping. ## The Real Problem: Internal Communication First Here’s the uncomfortable truth: if your support team doesn’t know what shipped, your customers definitely don’t. Support is the canary in the coal mine. When internal communication fails, external communication fails too. Fix internal first, and external gets easier. This is why I recommend starting any product communication effort by asking: Does your own team know what you’re shipping? If the answer is no (or “only the big stuff”), start there. ## Building the Flow Teams that solve this share a few characteristics: **They treat internal updates as important.** Not a nice-to-have, but a shipping prerequisite. **They automate what they can.** The information comes from the source (the code, the PR, the deployment) rather than manual entry. **They push, don’t pull.** Information goes to support automatically, rather than support having to hunt for it. **They right-size the detail.** Support gets what support needs, not a copy of the engineering changelog. **They close the loop.** When something ships that affects tickets, there’s a path from “we deployed the fix” to “close these tickets.” ## The Secret Channel Test Here’s a diagnostic: Does your support team have a secret channel, shadow doc, or informal system for tracking “stuff engineering shipped that we didn’t hear about”? If yes, you have an internal communication problem. The workaround is a symptom, not a solution. The goal is a world where support never has to say “let me check with engineering” about whether something shipped. They should know before the customer asks. That’s not a technology problem. It’s a flow problem. And it’s solvable. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # The Vendor Security Dance: How Both Sides Can Move Faster URL: https://www.changebot.ai/blog/the-vendor-security-dance/ Description: Security reviews don't have to stall deals for weeks. Here's how vendors and buyers can structure evaluations that work for security teams without killing momentum. Last updated: 2025-12-25 Best Practices # The Vendor Security Dance: How Both Sides Can Move Faster [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder December 25, 2025 6 min read ![Two figures meeting on a bridge representing vendor and buyer collaboration in security reviews, with documentation and checkpoints leading to a handshake](/_astro/featured.D2Gpveqm_Z2gacfK.webp) “I’d have to engage with our security guys. It’s our IP.” An engineering lead said this to me recently during a call about setting up a product demo. He wasn’t being obstructive. He wanted to move forward. But he knew the conversation couldn’t progress until his security team signed off. Twenty minutes later, he’d already reached out to them. This is how security reviews should work: not as adversarial standoffs, but as structured conversations where both sides move toward the same goal. The reality is that most security reviews stall not because of fundamental incompatibility, but because of friction in the process itself. Here’s how to make them faster, whether you’re the vendor or the buyer. ## The Usual Breakdown Security evaluations fail in predictable ways. **From the vendor side:** You send a sales engineer who doesn’t know the security architecture. Questions go unanswered for days. Someone buried the access-control notes in a legal folder somewhere. Every security question feels like an accusation. **From the buyer side:** You send a checklist of 200 questions, half of which don’t apply. Security gets looped in at the last minute. Nobody has authority to make tradeoffs. The evaluation drags on while the business team gets frustrated. **The result:** A deal that should close in two weeks takes two months. Or dies entirely because someone got tired of waiting. ## What the Best Evaluations Have in Common The fastest security reviews I’ve been part of share a few patterns. ### 1\. Security Gets Involved Early A technical contact at an enterprise software company told me his approach: within twenty minutes of our call, he’d already pinged his security team to start the review. He didn’t wait until the deal was “ready.” He started the security conversation in parallel with the technical evaluation. This matters because security teams have their own backlogs. If you wait until you’ve made the business decision before involving them, you’re adding their queue time on top of everything else. For vendors: ask in the first call who the security stakeholders are. Offer to send documentation proactively. For buyers: brief your security team on what you’re evaluating before you need their approval. Give them a heads up, not a surprise. ### 2\. Both Sides Come Prepared with Documentation The worst security reviews are discovery exercises disguised as evaluations. Neither side has documentation ready, so every question requires research. For vendors, this means having ready: - A clear summary of the security controls you actually operate - Data flow diagrams showing what goes where - Clear explanations of LLM/AI data handling if applicable - Architecture documentation for self-service review - Access-control, audit logging, and data retention practices - Incident response procedures For buyers, this means having ready: - Your actual requirements, not a generic checklist - Authority to make tradeoffs (or access to someone who does) - Clarity on what’s blocking versus nice-to-have - Timeline expectations A founder told me during a recent call that his main security question was about LLM data handling: what code snippets get transmitted to external providers. That’s a fair question. A vendor who can’t answer it in detail shouldn’t have code access. ### 3\. There’s a Clear Path to “Yes” (or “No”) The most frustrating evaluations are the ones where security keeps finding new concerns without ever articulating what “done” looks like. For buyers: before starting the review, define what approval looks like. Is it checking boxes on a compliance framework? Is it a specific person’s sign-off? Is it a risk assessment with documented mitigations? For vendors: ask explicitly what the approval criteria are. “What would need to be true for your security team to be comfortable with this?” is a better question than “Do you have any security concerns?” ### 4\. Alternative Approaches Get Discussed During a recent evaluation, an engineering lead had concerns about granting our GitHub integration full repo access. His first instinct was to decline. But we talked through alternatives. What if we used a point-in-time snapshot instead of live access? What if they created a private repo, pushed a clone, and controlled permissions on their side? What if the connection happened through their account, with their credentials, so nothing touched our systems directly? The final approach satisfied his security concerns while still letting us show the product. Neither side got exactly what they initially wanted, but both sides got what they needed. The best security conversations involve tradeoffs, not ultimatums. ## The Vendor’s Playbook If you’re a vendor trying to move security reviews faster: **Lead with transparency.** Don’t wait for questions. Proactively share your architecture docs, access model, audit logging approach, and data handling practices. The companies most worried about security are also the most impressed when you’re open about it. **Know your architecture.** Nothing kills trust faster than a salesperson who can’t explain how data flows through the system. Have someone technical available for security calls. **Offer graduated access.** Not every evaluation needs full integration. Can you demo with a snapshot? With a subset of repos? With a sandbox environment? The more options you offer, the more likely one fits their constraints. **Respect the process.** Security reviews aren’t personal. The team asking hard questions is doing their job. Answer directly, provide documentation, and don’t get defensive. **Document everything.** After security calls, send a summary of what you discussed and agreed. This becomes the record that the security team can use for internal approvals. ## The Buyer’s Playbook If you’re a buyer trying to get through security reviews without losing momentum: **Involve security early.** As soon as you’re seriously considering a tool that needs access to sensitive systems, loop in your security team. Brief them on what the tool does and why you want it. **Share context.** Security teams make better decisions when they understand the business need. “This tool saves us 10 hours per week on release documentation” is more useful than “we want to try this new thing.” **Own the timeline.** If you need a decision by a certain date, say so. Security teams can often fast-track reviews when there’s a legitimate business deadline. **Be willing to compromise.** Maybe the vendor’s ideal integration doesn’t work for you, but a modified version does. Maybe you start with a pilot on non-sensitive repos and expand later. Rigidity slows everything down. **Get to “no” quickly if needed.** Sometimes the security concerns are real dealbreakers. That’s okay. A fast “no” is better than a slow “maybe” that wastes everyone’s time. ## The Real Goal Security reviews exist to manage risk, not remove it. There’s no zero-risk option when you’re integrating with external tools. The question is whether the risk is acceptable given the benefit. A technical contact explained his team’s approach: “We would need to make sure we do all the changes on our side and flip all the levers to make sure it’s set up the way we want it. But I don’t see any issues of us not being able to reach that goal.” That’s the right mindset. Not “how do we avoid all risk?” but “how do we structure this so the risk is manageable?” The security dance doesn’t have to be slow. When both sides come prepared, communicate well, and focus on finding workable solutions, reviews that used to take months can happen in days. The goal isn’t to skip security. The goal is to do security well, fast. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # The Year-End Review You're Dreading URL: https://www.changebot.ai/blog/the-year-end-review-youre-dreading/ Description: Every January, product teams face the same grueling ritual: sifting through months of work to compile what actually shipped. There's a better way to approach year-end retrospectives. Last updated: 2026-01-19 Best Practices # The Year-End Review You're Dreading [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder January 19, 2026 4 min read ![Illustration contrasting chaotic year-end data excavation with organized curation, showing scattered documents becoming a clean summary report](/_astro/featured.DfA7R9PO_Z1X25K0.webp) It’s January. You know what that means. Somewhere in your organization, someone is staring at a massive spreadsheet, a Notion database with 200 rows, or a Jira board that nobody has touched since Q2. They’re trying to answer a simple question: what did we actually ship last year? A Sr. Product Marketing Manager described this process to me recently as “grueling.” She was sifting through a Notion table of projects and features, trying to figure out which ones deserved a spot in a year-end recap. The table didn’t reliably convey importance. She had to go back to the product team repeatedly, asking: “Is this one important? What about this one?” This is the annual ritual nobody talks about. ## The January scramble Year-end reviews serve real purposes. Stakeholders want to see progress, customers want proof the product is evolving, and investors want evidence of velocity. Sales wants ammunition for renewals. The process of producing that review, though, is brutal: **Discovery takes forever.** What actually shipped in March? April? The work sits buried in old sprint retrospectives, archived Slack threads, and tickets that someone closed nine months ago. Memory fails. Documentation is sparse. **Context evaporates.** You can see that someone marked a feature “done” in June. But why did it matter? What customer problem did it solve? The people who knew have moved on, or simply don’t remember. **Importance is subjective.** A table of completed work doesn’t tell you what matters. Some of those rows are major launches. Some are routine maintenance. Distinguishing between them requires judgment calls that weren’t documented at the time. **The deadline is immovable.** The board meets next Tuesday. The customer newsletter goes out next week. The all-hands is Friday. There’s no time to do this properly, so you do it hurriedly. ## Why this keeps happening The year-end review problem is really a twelve-month communication problem that compounds. Throughout the year, teams ship work. Some of it gets announced. Most of it doesn’t. The work that does get communicated scatters across channels: a Slack post here, a changelog entry there, an email to customers, a mention in a meeting. By December, there’s no single source of truth for what happened. The only way to reconstruct the year is to excavate. One product marketer at an enterprise company told me she has to join calls just to understand what different teams shipped. She’s responsible for 20 products. There’s no other way to gather the information she needs for quarterly updates, let alone annual ones. Another described compiling a 100-page document for major events. “The process is terrible,” she said. “Each time we just manually update it.” These aren’t lazy teams. These are smart people working hard inside systems that don’t support the outcomes they need. ## The hidden costs The obvious cost is time. A senior leader spending a week reconstructing the year is a senior leader not doing strategic work. The subtler costs hurt more: **Incomplete credit.** When you’re racing to compile, you miss things. That performance improvement in August that made the product twice as fast? Forgotten. That accessibility feature that opened up new markets? Buried in the backlog. **Narrative fragmentation.** Different people compiling different sections tell different stories. The year-end review becomes a patchwork, not a coherent narrative. **Repetitive pain.** This isn’t a one-time problem. It happens every quarter. Every year. The same excavation, over and over. **Late communication.** By the time you’ve compiled, reviewed, and published the year-end recap, it’s mid-January. Or February. The moment has passed. ## A different approach What if you didn’t have to reconstruct the year in January because you’d been capturing it all along? The teams that avoid the year-end scramble share a common trait: they’ve automated the capture of what ships. They’re not relying on memory or manual documentation. They have systems that continuously record what’s changing and why it matters. This doesn’t mean more process for engineers. It means less process for everyone else. Instead of asking engineers to fill out forms or maintain changelogs, the information flows from where the work actually happens: the code. When you have a continuous record of customer-impacting changes, the year-end review becomes a summarization exercise instead of an excavation. You’re not reconstructing history. You’re curating it. ## The January after Imagine starting the year with this already done: - A comprehensive record of every meaningful change shipped in the past twelve months - Each change tagged by type (feature, improvement, fix) and audience relevance - Customer-oriented summaries already written, ready to compile - A clear view of themes, patterns, and progress across the entire year The year-end review becomes a strategic exercise: what story do we want to tell? Which wins deserve emphasis? What narrative arc makes sense? That’s a much better use of a product leader’s time than sifting through 200 rows of a Notion table, asking “is this one important?” * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # This to That URL: https://www.changebot.ai/blog/this-to-that/ Description: Watch us transform minimal commit messages into compelling customer updates that actually resonate. Last updated: 2024-09-02 Best Practices # This to That [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder September 2, 2024 3 min read ![This to That](/_astro/featured.BpVLW6Lg_ZPjDg8.webp) One of the most common pieces of feedback we get is: “There’s no way Changebot will work for our product, our commit messages are wack!” While my instinct is to reassure them that their commits are beautiful and worth love, I understand where they’re coming from. From our first set of beta customers we realized that there are many commits in the wild like: - “New feature”, - “Fix”, and - “Working??” These commits make their way into product, revenue generating codebases much more commonly than we expected. What surprises most people is that we can absolutely turn these very limited commits into great updates. When we show our ability to turn a limited commit into a full customer update we always use the phrase of turning “This to That”, so we thought it was only right to publish this post under the same name. We’ll update this page periodically, adding impressive this to thats as we post them. To get started… ## We turned this: Commit: add badges to company and contact index pages Description: (empty) ## Into that: ### Introducing Value Rank Badges for Enhanced Engagement We are excited to announce a new feature that will significantly enhance your user experience: Value Rank Badges, which you can find on the company and contact overview pages. **What’s a Value Rank Badge?** Value Rank Badges indicate the relative value ranks of your companies and contacts. These badges visually represent rankings such as Number 1, Top 10, and Top 75, making it easier to identify your most valuable relationships at a glance. Your biggest customer will show as rank 1, your second to tenth largest customer will show the badge “Top 10,” and so on up to 75. The badges provide a quick and clear visual indicator of the engagement status of your contacts and companies, helping you prioritize interactions and focus on key stakeholders more efficiently. By displaying these value ranks directly on the dashboard and index pages, you can navigate large datasets more efficiently and make better-informed decisions. These enhancements align with our mission to help you prevent customer churn by monitoring engagement levels. The value rank badges will allow you to quickly identify relationships that might be at risk of going stale, enabling you to take proactive measures to maintain strong customer relationships. We believe these changes will not only enhance your decision-making and engagement strategies but also make the platform more engaging and enjoyable to use. We encourage you to explore these new features and see how they can benefit your workflow. If you have any questions or feedback, please don’t hesitate to reach out to our support team. Happy engaging! We love this update for a few reasons. First, turning “add badges to company and contact index pages” into anything interesting is impressive. That’s a pretty limited starting point, and I’m really pleased how this update turned out. The concept of “Value Rank Badges” is genuinely creative and does a great job of actually naming this feature, which is focused on adding badges to your customers based on how big they are (eg, when viewing customers in this system, your largest customer will have a tag that says number one, your top 10 customers will have a tag that say top 10, etc.) This is a perfect example of taking something that makes sense to developers and turning into customer centric language that covers both what the change is, and more importantly: what benefit it’s granting to customers. [← Back to Blog](/blog) # Top-of-Funnel Content Is Dead. Product Updates Are Your New Growth Channel. URL: https://www.changebot.ai/blog/top-of-funnel-is-dead/ Description: Traditional SEO blog posts won't save you. In a world where prospects ask LLMs for recommendations, the companies with the most detailed product content win. Last updated: 2026-02-07 Best Practices # Top-of-Funnel Content Is Dead. Product Updates Are Your New Growth Channel. [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder February 7, 2026 4 min read ![A crumbling marketing funnel contrasted with product update cards flowing into an AI chat bubble that connects to customers](/_astro/featured.cH0vstkd_ZrwjV1.webp) I was trying to figure out how to configure ACH payments in Shopify. I Googled it and landed on one of those classic top-of-funnel blog posts. You know the type: 2,000 words explaining what ACH is, written to rank for “ACH payments explained,” designed to capture anyone vaguely curious about the topic. I didn’t need to know what ACH is. I needed to know if a specific tool could handle my specific setup inside Shopify. I did what everyone does now: I opened ChatGPT, gave it the context of my business, and asked which tool I should use. That SEO blog post? Irrelevant. The tool that won the recommendation had product content detailed enough for the LLM to match it to my situation. ## The old playbook is dying For a decade, SaaS marketing meant writing top-of-funnel content. “What is {concept}?” posts. “Top 10 {category} tools” listicles. “Ultimate guide to {buzzword}” pages. All designed to capture search traffic and funnel it toward your product. That worked when Google was the starting point for every buying decision. It’s not anymore. Buyers are increasingly going to LLMs with highly contextual questions. Not “what is project management software” but “I have a 12-person engineering team using Linear and GitHub, shipping weekly, and we need a way to communicate changes to customers without adding meetings. What should we use?” The LLM doesn’t care about your top-of-funnel blog post, in fact it probably hates them. It only cares about whether it has enough information about your product to recommend it for that specific situation. ## Product marketing is the ascendant discipline A co-founder I spoke with recently put it perfectly: “Product marketing is the ascendant discipline in marketing now. Writing about your product and what it does is how you’re found.” In the old world, you’d never write a blog post about a minor bug fix. There’s no SEO value in “we fixed an edge case in our Slack integration.” No one’s searching Google for that. In the new world, someone absolutely is typing into their LLM: “I use Slack and keep running into this problem with notifications from {tool category}. Which tools handle this well?” If you’ve published detailed content about your Slack integration, including fixes and edge cases, the LLM can recommend you. If you haven’t, the LLM won’t include you in the result. Every feature, every integration, every fix, every comparison — they all matter now because you can’t predict the context someone will ask about. ## The permutation problem Here’s what makes this challenging: LLM queries come with context you can’t predict. A prospect’s LLM knows their entire tech stack. When they ask for a recommendation, the LLM searches for products that integrate with their specific combination of tools. Your product might be perfect for them, but if you haven’t published content about that specific integration or use case, the LLM has nothing to work with. One founder described it this way: “You need content for every different permutation of your product and everything you integrate with. Every problem it might solve, every technical feature, how it connects into every tech stack.” That’s a lot of content. Far more than any marketing team could write manually at the pace needed. ## Why product updates become growth content This is where the shift gets interesting. Your product updates, the changes you’re already shipping, are exactly the kind of content that feeds LLM discovery. Every feature you launch is a potential match for someone’s contextual query. Every integration you add is discoverable. Every bug you fix addresses a pain point someone is asking about. Only if you publish it. In detail. With enough context for an LLM to understand when to recommend you. The companies that win this game are the ones that treat every shipped change as a piece of marketing content. Not because they’re gaming the system, but because detailed product information is genuinely how buyers find products now. ## The compound effect A company that publishes detailed updates about every feature, fix, and integration builds a deep catalog of product content. Month after month, the surface area of what LLMs know about them grows. A company that publishes a quarterly changelog with five bullet points stays invisible for 90% of possible queries. The gap compounds. The first company gets recommended more often, which means more customers and more feedback. More feedback drives better product decisions, which means more updates to publish. The flywheel spins. Meanwhile, the traditional SEO company is still writing “What is {concept}?” posts that LLMs answer without ever sending traffic to anyone’s site. ## The shift is already here This shift is already happening. Buyers are already asking LLMs for product recommendations instead of Googling. The companies that recognized this early and invested in detailed, comprehensive product content are already seeing the results. The question isn’t whether this shift will affect your business. It’s whether you’re building the content catalog that makes your product discoverable in this new world, or whether you’re still writing top-of-funnel blog posts for a search engine that’s losing its monopoly on discovery. Your product updates serve double duty now: they keep existing customers engaged and help new customers find you. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # We are doing stuff. Trust us. URL: https://www.changebot.ai/blog/we-are-doing-stuff-trust-us/ Description: Your team ships features every week. Your customers have no idea. When there's no single place to point people to, trust erodes even when the work is getting done. Last updated: 2026-02-25 Best Practices # We are doing stuff. Trust us. [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder February 25, 2026 4 min read ![Illustration of a building bustling with activity inside but no visible signs of progress to people outside](/_astro/featured.BXBGPQ95_1jEVmG.webp) A product lead at a small CRM company said something on a call that stuck with me: “We’re not letting people know about our updates. It’s like, well, we are doing stuff. Trust us.” His team ships regularly. Bug fixes, feature improvements, new capabilities. The work is happening. But when a customer asks “what have you been working on?” there’s no single place to point them. No changelog. No public update feed. No self-serve way to see what’s changed. The answer to “what’s new?” is always a person. And when the answer is always a person, most of the time the question doesn’t get asked — or answered. ## The invisible work problem Here’s how their current process works. A developer deploys in the morning and posts in Slack: “Released this morning, let me know if there are issues.” Bigger updates sometimes get an email to affected customers. Small bug fixes get communicated one-on-one to the person who reported them. That’s it. There’s no aggregation. No public record. No way for someone who wasn’t in the Slack channel or on the email thread to know what happened. The result: the people who ask the most questions (their telemarketing customers) have no way to self-serve. Every “what’s new?” requires a human to answer, which means the team is spending time on status communication that a tool should handle. And the customers who don’t ask? They just assume nothing has changed. ## Trust requires evidence When you’re a small team shipping fast, it feels obvious that you’re making progress. You see the commits. You see the deploys. You see the Jira board moving. The work is right there in front of you every day. Your customers don’t see any of that. They see the product. If it looks the same as it did last month, their working assumption is that nothing happened. You can tell them you’ve been busy, but telling is not the same as showing. A public changelog is evidence, not a marketing exercise. It’s a simple, always-available answer to the question: “Is this product actively maintained? Is this team building things?” For SaaS companies in particular, that evidence matters more than you’d think. Customers evaluating renewals, prospects doing due diligence, partners assessing stability — they all check for signs of active development. An empty public profile says “abandoned” louder than any sales call can overcome. ## The 1:1 communication trap The CRM company’s support team communicates bug fixes directly to the person who reported them. That makes sense on the surface — the person who reported the bug wants to know it’s fixed, and mission accomplished. What about the other customers who hit the same bug and didn’t report it? What about the support team member who wasn’t on that particular ticket? What about the success manager who’s compiling a monthly update and has no idea what shipped? One-on-one communication handles the immediate need. It doesn’t build institutional knowledge. It doesn’t create a record that other people can reference. And it definitely doesn’t scale when you’re shipping fixes every week. The product lead told us his success manager produces a monthly newsletter for customers. Right now, compiling that newsletter requires asking around — checking Slack, checking with developers, trying to piece together what went out over the past month. With a changelog in place, the newsletter practically writes itself. ## Starting from zero Some teams need to improve their changelog. This team needs to start one. And starting from zero is both easier and harder than it sounds. Easier because there’s no legacy process to untangle, no existing tool to migrate from, and no entrenched workflow to change. You’re just adding something that didn’t exist before. Harder because nobody is asking for it internally. The team knows what shipped because the developer posted in Slack and the PM reviewed the tickets. Everyone on the inside feels informed. The communication gap is only visible from the outside — from the customer’s perspective, from the prospect’s perspective, from anyone who doesn’t have access to your Slack channels. The hardest part of going from zero to a public changelog is recognizing that the work you’re doing deserves visibility. Shipping in silence feels humble, but it’s a missed opportunity to build trust, reduce support load, and prove that your product is alive and improving. ## “Trust us” isn’t a strategy “We are doing stuff. Trust us” works when you’re in the room. It doesn’t work when a customer is evaluating renewal options in a spreadsheet, or when a prospect is comparing your product to a competitor with a detailed changelog, or when a support rep is trying to answer “has anything changed lately?” The fix is simple in concept: make the work visible. Give people a place to look. Update it consistently. The execution is what trips teams up — because writing changelogs manually takes time nobody has, and maintaining consistency is harder than starting. That’s where tools earn their keep. Not by adding complexity, but by turning work you’re already doing into communication you’re not. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # What 15 hackathon apps taught us about the future of customer communication URL: https://www.changebot.ai/blog/what-15-hackathon-apps-taught-us/ Description: When 15 teams at an AI hackathon independently built customer success tools, it confirmed something we've believed for a while: customer communication is the next frontier for AI. Last updated: 2026-02-17 Best Practices # What 15 hackathon apps taught us about the future of customer communication [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder February 17, 2026 4 min read ![A grid of hackathon project demos showing various customer communication tools](/_astro/featured.BlOmFd8H_Z1luqYv.webp) One of my first indications that AI was “happening” inside of real companies was when a customer of ours recently told us her company ran an internal AI hackathon. 48 hours, real prizes, and full participation across the org. When the dust settled, 15 of the projects were tools for customer success and support, which she found funny given the fact that my past many product have all aimed to make the lives of success, support, and operations teams 10x easier. Also… Fifteen! Out of everything people could have built, nearly every team gravitated to the same problem: how do we communicate better with our customers? ## Everyone has the same problem What’s remarkable isn’t that people built customer communication tools. It’s that they built them _independently_. Nobody coordinated. There was no brief saying “build something for support.” These were developers, product managers, and success teams all looking at their day-to-day frustrations and arriving at the same conclusion. One team built a tool that checks incoming support requests against historical tickets to surface similar issues. Another built an app that turns closed bug tickets into customer notifications. And yet another built a tool to identify at risk customers based on recent communication trends. The specifics were different, but the theme was identical: there’s a gap between our teams (engineering, marketing, support) and our customers, and the gap is big enough to be both noticeable and painful. ## The problems were always there After chatting on this for a while I realized: none of these problems are new. Every team at that hackathon has been living with these gaps for years. The developer who built the bug-to-update tool has always known that customers don’t hear about fixes. The support team has been answering the same questions over and over again for the past 10 years. The problem hasn’t changed, but now people empowered to do something about it. The AI tools are a bit irrelevant, they didn’t create a new category of problems, and they really haven’t created a new category of solutions (for example, I built the “identify at risk customers tool over 2 years ago”). What the recent trend in AI tooling has done is lower the floor on what’s worth solving. Small operational inefficiencies that always existed (but weren’t worth spending the time of an expensive engineer) are suddenly accessible, if not solvable. A non-technical person can prototype a solution in a few hours instead of writing a spec that sits in a backlog for six months. The reason that matters is not because the prototypes are production-ready (they’re often not (and the team has no idea how to get them there)), but because they shine a light on the problem that’s always existed. ## Shining the light We talk to SaaS companies every day who know they have customer communication gaps but have never prioritized fixing them. The changelog is stale. Support tickets get resolved but customers never hear about it. New features ship and the only people who know are the ones who read commit messages. These aren’t dramatic problems, nobody’s hair is on fire… but they do compound. Customers churn because they think the product isn’t improving. Prospects don’t convert because there’s no visible proof of momentum. Support handles the same questions because updates never reached the people who reported the issue. When a hackathon team builds a tool to solve one of these problems in 48 hours, it doesn’t mean the problem is easy. It means the problem is _obvious_, or at least clear enough that someone with no engineering background can articulate the problem, prototype a workflow, and demo it to a room full of people who all nod and say “yeah, we get it.” ## The gap between demo and done While the hackathon got everyone experimenting with these AI tools and succeeded in getting the teams rallied, there were a few _small_ implementation issues. For example, the commission checking product it looked great, but there was one small issue… the math wasn’t always correct. The app connected to real APIs and data sources, but struggled with all the things we’ve been wrestling with in software forever, boundaries and edge cases. This is the stock experience of building with AI right now. You can get 80% of the way to something impressive in a few hours. The remaining 20% (accuracy, reliability, edge cases, maintenance) is where years of engineering and domain expertise live. A built an AI tool that posted on their behalf, and in their demo they just shipped an update live… without viewing what it wrote! Works for the demo, looks awesome, but will it work for the 50th update? The 200th? I mean… the 2nd? That’s where purpose-built products earn their keep. ## What this means for SaaS If 15 teams at one company independently identify customer communication as their biggest pain point, that’s a signal. The companies that win in the next few years won’t be the ones with the flashiest AI demos. They’ll be the ones that take these real, obvious, painful gaps in customer communication and solve them reliably. Not as a weekend project, but as a team focused on solving the problem, and completing that “final 20%” that takes 80% of the time. A hackathon participant put it well: the hard part isn’t producing an output. The hard part is making that update _good_. Making it accurate, making it speak to the right audience, making it happen consistently, automatically, every time you ship. That’s the actual work that separates every successful SaaS product from 2026 on. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # What to Ask Before Giving an AI Tool Access to Your Code URL: https://www.changebot.ai/blog/what-to-ask-before-giving-ai-code-access/ Description: A vendor checklist before you grant an AI tool repo access: what they read, what they send to LLMs, secrets handling, retention, and breach response. Last updated: 2025-12-14 Best Practices # What to Ask Before Giving an AI Tool Access to Your Code [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder December 14, 2025 5 min read ![Secure code repository connected by a gated pathway to an AI brain symbol with security checklist](/_astro/featured.CBC49yCi_Z2pLeJo.webp) “There’s hesitancy around giving LLM access to our entire repo.” A founder said this to me recently during a product demo, and he’s not alone. Every week I talk to engineering leaders and CTOs who are evaluating AI-powered tools that need code access. They’re excited about the potential, but worried about the security implications. Those concerns are valid. Your codebase contains business logic, security implementations, proprietary algorithms, and sometimes secrets that shouldn’t leave your infrastructure. Giving an external service read access is a real decision that deserves real scrutiny. Here’s what I’d ask before granting that access to any vendor. ## Question 1: What Exact Access Do You Need? Not all code access is equal. Some tools need: - Read access to repository metadata (commits, PRs, branches) - Read access to diffs and patches - Read access to full file contents - Write access (comments, labels, checks) Understand the least access needed. If a tool only needs to analyze diffs, it shouldn’t require access to your entire file tree. If it only needs commit messages, it shouldn’t need to read source code. Ask: Can you function with a subset of repositories? Can I control which repos you access? What happens if I revoke access to certain repos? The answer should be granular control, not all-or-nothing. ## Question 2: What Gets Sent to LLM Providers? This is the big one. The tool has access to your code, but what actually gets transmitted to external AI providers? Some tools send complete file contents to LLMs. Others send snippets. Some send obfuscated or anonymized fragments. Some process everything locally and only send summaries. The right answer depends on your risk tolerance, but you should know exactly what the data flow looks like. Questions to ask: - Do you send raw source code to LLM APIs? - How do you chunk or fragment code before transmission? - Do you obfuscate variable names, function names, or identifiable patterns? - Is there any pre-processing to remove secrets or sensitive patterns? - What’s the largest context window you send in a single API call? A good vendor should be able to explain their data flow in detail, not just say “we take security seriously.” ## Question 3: Which LLM Providers Do You Use? Different AI providers have different data policies. OpenAI’s API terms are different from Claude’s, which are different from open-source models you might self-host. Key questions: - Which LLM providers power your tool? - What are their data retention policies? - Do they use customer data for model training? (Most enterprise APIs do not, but verify.) - Can you use a specific provider if our security policy requires it? - Do you support self-hosted or on-premise LLM options? For enterprise customers with strict data residency requirements, the ability to use specific providers or self-hosted models can be a dealbreaker. ## Question 4: What Security Controls Do You Actually Run? Compliance frameworks can help systematize these questions, but a badge is not a substitute for understanding how a vendor actually operates. Ask what controls are in place, who owns them, and how they are reviewed over time. Depending on your industry, you may still need formal frameworks or legal commitments: - HIPAA for healthcare data - GDPR compliance for EU data - ISO 27001 for international standards - FedRAMP for government work Ask for the substance, not just badges on a website. Useful answers include access-control summaries, data-flow diagrams, encryption practices, audit logging, incident response process, employee access policies, and how exceptions are handled. ## Question 5: How Do You Handle Secrets? Every codebase has secrets: API keys, database credentials, tokens, internal URLs. Some are properly managed in secret stores. Many are accidentally committed somewhere in git history. A responsible AI tool should: - Not require access to secret management systems - Have scanning to identify and exclude potential secrets before LLM transmission - Document what happens if a secret is accidentally processed Ask specifically: If someone commits an API key to our repo, what stops it from reaching an LLM API? ## Question 6: What’s Your Breach Response Plan? No system is perfectly secure. What matters is what happens when something goes wrong. Questions to ask: - How would you detect if someone accessed our code inappropriately? - What’s your incident notification timeline? - Do you have cyber insurance? - Can you provide references from customers who’ve been through your security review process? The willingness to discuss breach scenarios honestly is itself a signal. Vendors who wave away security questions are often the ones you should worry about most. ## Question 7: Can We Audit Access? Trust but verify. You should be able to see what the tool is actually doing with your code. Ask about: - Access logs showing which repositories and files the tool touched - Audit trails for any data transmitted to external services - Ability to export or review what data the tool processed - Retention policies for logs and processed data If you can’t audit it, you can’t verify the answers to any other question. ## Question 8: What Happens When We Offboard? The relationship won’t last forever. When you stop using the tool: - Is all processed data deleted? - What’s the timeline for deletion? - Can you get a certificate of data destruction? - What persists in their systems after you leave? Document this before you start, not when you’re trying to leave. ## A Framework for Evaluation Different teams have different risk tolerances. A two-person startup building a consumer app has different constraints than a financial services company with regulatory requirements. Here’s a simple framework: **Low sensitivity (public repos, open source):** Clear data policies, reputable LLM providers, and basic access controls. Move fast. **Medium sensitivity (private repos, proprietary but not regulated):** Detailed data-flow documentation, least-privilege access, obfuscation of code before LLM transmission, and audit logging. **High sensitivity (regulated industries, security-critical systems):** Everything above plus formal compliance requirements where needed, on-premise options, specific LLM provider requirements, legal review of contracts, and reference calls with similar customers. ## The Trust Decision Ultimately, giving an AI tool access to your code is a trust decision. You’re trusting that the vendor will handle your data responsibly, that their security controls work, and that the benefit is worth the risk. Vendors earn that trust through transparency, not marketing claims. The vendors who are doing security well will have good answers to these questions. They’ll have the documentation ready. They’ll welcome the scrutiny. The ones who don’t? You probably don’t want them reading your code anyway. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # When Do You Announce a Feature That's Only 10% Rolled Out? URL: https://www.changebot.ai/blog/when-do-you-announce-a-feature-thats-only-10-percent-rolled-out/ Description: Feature flags and staged rollouts create a communication timing problem. Traditional release notes assume binary shipped/not-shipped. CI/CD requires a new mental model. Last updated: 2026-01-02 Best Practices # When Do You Announce a Feature That's Only 10% Rolled Out? [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder January 2, 2026 5 min read ![Staged rollout progress bar with megaphone icons at varying opacity and a question mark over middle stages representing communication timing uncertainty](/_astro/featured.Bbll_nbw_1QIox3.webp) A Head of Product Operations asked me a question I’ve been thinking about ever since: “Our release cadence and rollout percentages complicate when and how to communicate. When a feature is at 10%… 50%… GA… when do we tell customers?” She was running release management at an enterprise integration platform. They’d moved from six-week release cycles toward CI/CD with feature flags. The technical benefits were clear. The communication challenges were not. Traditional release notes assume a binary state: shipped or not shipped. Feature flags break that assumption. And nobody has figured out a clean answer for when to communicate about features that exist for some users but not others. ## We Broke the Old Model In the waterfall era, communication was straightforward: 1. Build the feature 2. Ship the release 3. Announce to everyone The feature was either available or it wasn’t. The announcement went out after the release. Everyone got the same message because everyone got the same product. Feature flags changed everything. Now a feature might be: - Merged but not deployed - Deployed but behind a flag (0%) - Rolled out to internal users only - At 10% of production traffic - At 50% of production traffic - Fully rolled out but not yet announced - Announced to some segments but not others At which of these stages should you tell customers? The answer is “it depends,” which is unsatisfying but accurate. ## The Communication Timing Matrix Here’s how different teams handle this: ### Option 1: Wait for GA The safest approach: don’t announce anything until it’s fully rolled out to everyone. **Pros:** No confusion. No “I don’t see this feature” support tickets. No awkward “sorry, you’re in the control group” conversations. **Cons:** You lose the window to build anticipation, and early adopters who discover features on their own feel ignored. Competitors might announce similar features first, while internal teams don’t know what’s coming. ### Option 2: Announce at First Rollout The aggressive approach: announce as soon as the feature is available to anyone. **Pros:** Most time to build awareness. Shows momentum. Gets feedback earlier. **Cons:** Most customers can’t use what you’re announcing. Support gets flooded with “where is it?” questions. You might roll back a feature you’ve already promoted. ### Option 3: Staged Communication The nuanced approach: different messages at different stages to different audiences. **Pros:** Each audience gets relevant information. Internal teams can prepare. You can notify customers in the rollout directly. Others aren’t confused. **Cons:** Complex to execute. Requires coordination between product, marketing, and engineering. Easy to make mistakes. ## What Smart Teams Do The companies handling this well share common patterns: ### They Separate Internal from External Internal teams (support, sales, marketing) need to know about features before customers do. They need time to prepare documentation, update scripts, and understand the change. This internal enablement should start at first rollout, not GA. A feature at 10% means support might get questions. They need answers. External communication waits longer, often until 50% or higher. ### They Match Audience to Rollout Stage If you’re doing a targeted rollout to enterprise customers, announce to enterprise customers. If you’re testing with a geographic region, communicate to that region. The announcement should reach roughly the same audience as the feature. ### They Use Qualifiers Instead of Absolutes “We’re rolling out a new dashboard” is different from “The new dashboard is now available.” Smart teams use language that reflects the state: - “Starting to roll out…” - “Now available to select customers…” - “Gradually becoming available…” - “Now generally available to all customers…” This sets accurate expectations without waiting for GA. ### They Have Rollback Plans Before announcing anything, they know what happens if the feature gets pulled. Can you un-send the announcement? Update the changelog? Notify customers who got excited? Features at 10% rollout get pulled regularly. That’s the point of staged rollouts: finding problems before they affect everyone. Communication should account for this possibility. ## The Internal vs. External Timeline Here’s a rough timeline that works for many teams: **Feature merged (0%):** - Engineering and product know - No external communication **Internal testing (0-5%):** - QA and dogfooding - Still no external communication **Limited rollout (5-20%):** - Internal enablement begins (support, sales, marketing) - Documentation prepared but not published - No external announcement yet **Expanding rollout (20-50%):** - Documentation published (findable but not promoted) - Notify customers in rollout directly - Consider soft announcement (“rolling out to customers…”) **Approaching GA (50-90%):** - Public announcement if the feature is stable - Full documentation available - Marketing can promote **General availability (100%):** - Final announcement if not done earlier - Remove any “rolling out” qualifiers - Feature included in standard release notes This isn’t a universal formula. Adjust based on your product, your customers, and your risk tolerance. ## The LaunchDarkly Problem Many teams using feature flags have another challenge: their flag management system doesn’t talk to their communication system. LaunchDarkly knows who has access to what. Your changelog doesn’t. Your support team doesn’t. Your marketing team definitely doesn’t. This creates a gap where engineering knows the true state of the rollout, but everyone else is guessing. The announcement goes out at 80% rollout, but nobody knows it’s 80%. The fix is integration: your communication tooling should understand rollout state. When you write release notes, you should know which audiences can see which features. ## What Customers Actually Want Here’s the thing: most customers don’t care about your rollout percentage. They care about two questions: 1. Can I use this? 2. When can I use it if not now? Your communication should answer these questions, not explain your deployment architecture. “We’re rolling out a new reporting dashboard. You’ll see it in your account over the next two weeks” is better than “We’ve deployed the reporting dashboard to 35% of users and will reach GA by end of month.” The former is customer-centric. The latter is engineering-centric. ## The Honest Answer When should you announce a feature that’s only partially rolled out? **Internally:** As early as possible. Your teams need time to prepare. **Externally:** When you’re confident enough in the feature to defend the announcement if something goes wrong. For most teams, that’s somewhere between 50% and GA. **To specific customers:** When they can use it. If you know a customer is in the rollout, tell them. The complexity of modern deployment practices doesn’t have to mean complexity in communication. It just means your communication system needs to be as sophisticated as your deployment system. Most aren’t. That’s the gap. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # Who's responsible for customer updates? URL: https://www.changebot.ai/blog/whos-responsible-for-customer-updates/ Description: Your team isn't updating customers enough—here's how to figure out who should actually own this critical responsibility. Last updated: 2024-07-15 Best Practices # Who's responsible for customer updates? [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder July 15, 2024 20 min read ![Who's responsible for customer updates?](/_astro/featured.BdhqYxGa_YAdge.webp) “We aren’t updating our customers enough” is a common realization for companies of all sizes. Instead of pointing fingers, smart, experienced, and action biased teams will start with the most important question: who’s responsible for customer updates? If you can identify who’s accountable for getting customer updates out the door the actual steps of solving the problem get a lot easier. — To understand who’s responsible for customer updates, we first need to be clear on what we mean. The question is not “who’s responsible for any step in the process,” because we’re looking for who owns the entire process. It’s also not “who’s responsible for doing noteworthy things,” because that’s everyone’s job. To fully expand this simple question into what we actually mean, it’s something like: “Who is responsible for gathering information on changes are happening in our product and throughout the company, batching those changes into logical groups and writing those groups of changes in a customer friendly tone, fact checking that the combined information is true once combined, and finally pushing that update to all the places customers might look, including the blog, email newsletter(s), Twitter, LinkedIn, in app banners, and to relevant people in the sales pipeline?” Phew! Spelling the question out in full terms makes it a bit more clear why we’re not always on top of customer updates. In this post I’ll cover: - The reasons why you’re not writing enough customer updates, - Who could possibly own this responsibility, and - My recommendation of how to handle this on small and medium size teams. ‍ ## Why you aren’t writing enough updates By the way—if you’d rather not worry about who should be writing updates and instead rather have them done for you… we’d be happy to do that… Sign up for Changebot and we’ll knock out more updates than you can shake a stick at. It’s worth a disclaimer: [I wrote ~90 pages on the topic of customer updates](https://www.changebot.ai/blog/the-art-of-the-update), which does include a pitch on why customer updates are important, and why you may have trouble keeping to a frequent, consistent publishing schedule. If you’re reading this article and think “this is great, but I wish it was about 800 times longer” I highly recommend flipping over to that post for a quick skim. To summarize from that article, the common reasons why companies aren’t updating their customers enough are: 1. No process to gather the needed information, combine it, fact check, and publish. 2. Teams are time limited from building the product, they don’t have time to also write updates. 3. Teams don’t have a single person who’s accountable for getting updates published. ‍ ### No Process Not having a process is the main indicator that there’s not a single owner responsible for publishing customer updates. Building a company (especially a startup) is one big coordination issue. Customer updates are a uniquely challenging problem because every team within your company has a hand in the process. No individual person has all the knowledge and background to cover the entire scope of every update. (And if there is a single person who can handle customer updates from beginning to end, I’ll bet they’d identify problem number two, no time, as a big issue.) It requires a village to produce great updates. You need the technical skill to understand how changes and improvements actually work, customer knowledge to know what sort of benefits people rely on your product to provide, you need to be able to write and communicate clearly and with brand voice, and you need to be a distribution and repetition machine to get the updates to where they need to go. Writing great updates does not happen by accident. It takes an organized, company-wide effort to make it happen. ‍ ### No Time The meme is that product teams spend all their time building and no time marketing. Not sending customer updates is the manifestation of this problem, and the front line excuse is “we don’t have time to do this.” ![Meme showing startup founder reactions: enthusiastic about adding features and fixing bugs, but reluctant about doing marketing](/_astro/product-teams-meme.DdeWA8_u_YGecL.webp) Source: [memelogy.co](https://www.memelogy.co/meme/recEy4MnA5s9lMdI2) Without trying to sound like a business coach we need to flip our perception on customer updates. Updates are the reason why we make the changes (or more accurately, communicating with our customers that we’ve fixed bugs and improved the product,) it’s not possible for updates to get in the way of making improvements. Updates are the reason for the season. Consider this: if you make 100 improvements and none of your customers or prospects knew about these changes, is that better than 10 improvements that all of your customers know about? Now, food for thought, how close is your business to the “100 improvements that no one knows about” scenario? Great updates do take time. But it’s worth it. With the right tools, process, and people, you can get way better results than you expect with much less time than you think. ‍ ### No Accountability Accountability drives results in a company. To illustrate, let me share a story of startups’ past. My first real company was a password manager. I’d ask everyone I met “how happy are you with how you store and give access to passwords?” and effectively 100% of people would say “well Brian, not that happy.” This included people who already had a solution in place too! You must be thinking “wow, you elegantly solved a problem that every tech business in the world had, you must have made billions!” Unfortunately while most companies have “better way to share passwords” on their todo list it’s perpetually item number 25, under items like “get enough new customers to pay our bills”, “prevent important employees from quitting”, and “fix bug for our biggest customer so they don’t churn.” I share this to illustrate the point from the outside looking in: every business has dozens of things happening at once. If there’s not a single person on the team who has a goal around publishing more updates it’s just not going to happen. Reality has shown that a million other high priority items are going to come up. Urgent will beat important every time unless you’ve already made room for Important. Sending frequent customer updates has a persistent, long term impact, but without a clear goal (and guidance) accomplishing this goal is too big, too complicated, and too important to leave to chance and whatever time is left over. Just like with everything else: If you don’t set a goal, don’t plan on it happening. If you plan on it happening, you need a happener. ‍ ## Who _could_ own customer updates? Because the whole company is responsible for doing noteworthy things, it’s the case that literally anyone within the company could hold the responsibility for updating customers. Yet another reason why this problem is unsolved at so many companies. I’ll run through each department and provide you with the pros and cons of the update responsibility living there. The organization of each of these departments is too varied for me to make a blanket statement as to which job title should own updates, but, if you tweet your org chart at me I’ll tell you what I think. ‍ ### Product Marketing Do you already have a product marketing team? If so, congrats, you’re done! Customer updates are at the absolute core of product marketing, so that team should already have updates totally covered. However if you’re reading this, that probably means one of two things: 1. You don’t have a product marketing team, or 2. They aren’t doing updates 🙃. If you don’t have a product marketing team, that’s not too surprising. Doing a bit of research I found a wide range of opinions on when to start hiring in a formal “product marketing” team, and moreover what product marketing even is. [This thread](https://sharebird.com/h/product-marketing/q/whats-the-earliest-stage-a-startup-should-consider-hiring-a-pmm) of mostly product marketers all said “hire them (me) at the seed stage! Pre seed! First marketing hire!” And while I agree with them, my experience is that the response further down the page is the most accurate: “The two startups I joined as the first PMM were ~100 employees and both were for technical software products.” - Adam Kerin, Truework SVP of Marketing. [This article](https://www.linkedin.com/pulse/when-should-you-hire-your-first-product-marketing-manager-cohen/) by Jordan Cohen looks at the question of “when” another way, he says: “So, with that in mind, product marketing is always the LAST hire I make when building out a marketing team.” Want to know what he meant by “with that in mind?” You’ll have to read the post. _(reading rainbow gif)_ The final point that’s best made [in this post](https://www.startupdaily.net/advice/business-strategy/when-to-hire-a-product-marketer-for-your-startup-and-what-they-do-is-not-what-you-think/): “It’s very likely that someone in your organisation is already doing product marketing” Keep this in mind as we go through the other departments. “Product marketer” is both a noun and a verb, so even if they aren’t the title of “product marketer”, they may be product marketing as a part of making the company the best it can be. ‍ ### Marketing The next logical thought is “Well, if we don’t have product marketing… what about just… marketing?” All things considered, I tend to agree. The marketing team has a number of benefits that are hard to install into other teams. The marketing team understands your ideal customer profile, is used to talking about benefits, and is used to having a large percent of their work being customer facing. It can be a challenge to teach great writing, and it’s also hard teaching people to be benefits focused, so having a team with these characteristics built in is a huge benefit. The marketing team also understands publishing on a schedule, and **distribution**. Two of the biggest mistakes companies make with updates are not publishing them frequently enough, and not publishing them everywhere. Marketing teams do both of these by default, making them the presumptive champions of customer updates. To be balanced there may be a few downsides to having the marketing team own updates. Please forgive me for potentially engaging in stereotype. First, marketers don’t have a reputation for being deeply technical. This isn’t always a problem, and is often a benefit by not sending needlessly complex updates to customers. However, not being technical means that the complexity of the update needs to be pre-processed, meaning that a marketer might not be able to work from the “raw data” of commit messages and turn them into benefits focused copy they’d like to publish. Second, the marketing team is often measured on metrics like top of funnel traffic, leads, and social mentions. Having great customer updates benefits EVERYONE at the company, but there are other activities that could have a more immediate short term effect on all of these metrics. This is why “number of customer updates” needs to be its own goal, and the company needs to appreciate that this effort makes everyone’s job easier. (If you don’t buy into that I have a 90+ page argument to back it up.) Last, and probably least, the marketing team is busy. Constantly pulled between long term projects strategic planning, making messaging matrixes, and asking if the website needs to be remade, and short term projects like improving SEO on a specific winning blog post, increasing top of funnel traffic with a sponsorship, or asking if the website needs to be remade. I say “and probably least” because this is true of every team, I’ve never met a business that’s said “we have so much extra time on our hands, we don’t know what to do with it!” ‍ ### Product Management If not Product Marketing, and not Marketing, then how about Product Management? Product Management vs Product Marketing is another frequent conversation (and sometimes argument.) From my perspective while Product Marketers are responsible for bringing the product to market, product managers are responsible for the creation of the product. This includes market research, talking to customers, building a product roadmap, turning that roadmap in to backlog for the developers, and then testing and getting those features live. Product managers are also generally involved in the post launch process of getting feedback from customers and making the determination on which feedback to implement. Given this unique positioning, Product Managers are a great choice to own the customer update process. They know what’s being worked on, what’s coming up, what’s ready to ship, what customers are currently using and what they’re asking for in the future. Since Product Managers have vision through the development process they can begin writing customer updates as the feature takes shape, so that the launch and the update can go live at the same time. The main problem with electing a Product Manager to own customer updates is that Product Managers are quite rare, especially at early stage companies, and especially lately. This could be a function of my particular bubble, but I’ve noticed the jack of all trades Product Manager role going away in favor of more domain specialist… most of the time more developers. (Or, unfortunately with the recent trend in tech layoffs, PMs are getting replaced by empty seats.) If you do have a Product Manager in charge of the product that you want more updates for, the only other reason why they might not be the perfect fit would be due to the variance in the role. Some Product Managers may not speak to prospects, some might not be in touch with the sales team at all, some may not interact with marketing, some may not interact with support tickets or angry customers, and some might only talk to a subset of current customers. Depending on the company’s some Product Managers may not talk to customers at all. The Product Manager role is high variance, with a number of extremely strong opinions surrounding it. Undoubtedly there’s someone reading the paragraph above a furiously leaving the comment “If your product manger doesn’t talk to prospects they aren’t a real product manager!!!!!” The reality is that the role needs to conform to the business, this leads to variance and could cause the Product Manager to be a worse customer updates owner. ‍ ### Support Support is the team all ownerless tasks find their way to. Whenever a project or task comes up that no other team default owns, it goes to support. Need to write up documentation? Support team. Need reviews? Support team. Need to update billing? Support team. Need to orchestrate a multi year deal? Support team. Need to build a dashboard to report on sales numbers? Believe it or not: support team. However in the case of customer updates there is a bit of an argument to be made for the support team. Support has direct, 1:1 relationships with customers. They see real, every day usage of the product to know what’s happening in the wild. The support team sees the bugs and rough edges too. One of the things that prevents teams from sharing updates is the thought “well, this is just a bug fix, us talking about it only shows that it was broken in the first place.” I reject that premise and most support teams are with me: if a painful bug is fixed they will shout that from the rooftops, which is exactly the right thing to do. There’s also a few challenges to putting support in charge of updates. Partially because support is the default termination point of all unassigned tasks, the support team is the most likely team to experience time crunches and emergencies. While they might have free time one week to help get updates posted, the next week they might be totally at capacity, and as such aren’t a great fit for having maximum consistency. It’s also possible for the support team to be cursed with knowledge–it’s not always easy to be excited about one issue being fixed when you know there are ten more customers waiting for another bug to be fixed. And the support team, like most others, doesn’t have the full picture of how a new feature went from customer insight to product and might not be able to capture and summarize that process in an update. ‍ ### Engineering Engineering is a popular choice for writing customer updates, or at least delivering an outline to a dedicated writer on the team. It seems like companies can’t help but try and pull software engineers out of their core responsibility of delivering function code, including: - Spending a week a month in support, - Joining sales calls, - Writing a blog post on a regular schedule, - Scoping out potential new features with stakeholders, and - Attending meetings on why the dev team is missing deadlines. I suspect everyone comes to the same conclusion when they ask the development team to write the updates: they know exactly what changes have been made. Generally the hardest part to crafting a great update is translating the research, design, and development work into a short, focused, yet informative story. You cast your customers in the lead heroic role and explain how, through their hard work, they’ve come out the other side stronger. The developers know the exact changes made to the product to introduce these improvements to customers, they also probably have a good insight as to why the feature was even built in the first place, and they know what actually made it into the final product. So, shouldn’t they be the best choice to write updates? Well… so here’s the thing. The first problem is my (sort of) joke in the bullets above. Of everyone likely to say “I can either do everything I need to do, or I can spend half of my time writing updates,” developers are most likely to actually be right. Again, when’s the last time you spoke with a company that’s like yeah, we just have way too many developer hours, our velocity is too high. In my experience the engineering team provides the most leverage shipping high value code, and the company structure should organize around that. Shipping is a skill that should be honed and supported, not derailed. Next, developers generally aren’t the best writers. One suggestion, that I sort of agree with, is that developers should write great commit messages so that especially other developers, but even other people at the company can read these commit messages to know exactly what’s happening. In my experience getting developers to do this is a bit like pulling teeth, and requires constant, constant, constant reminders to write great commit messages. Most of the time it looks like this: ‍ ![XKCD comic showing a git commit history with increasingly uninformative messages like ‘misc bugfixes’, ‘more code’, ‘here have code’, and random keyboard mashing](/_astro/xkcd-commit-messages.B01Jfq_3_Z2uVQjc.webp) _Source:_\[ _XKCD_\]( [http://Source](http://Source): XKCD) Writing is its own skill distinct from software development. Finally, developers see a very specific slice of the business. Generally developers interact more with internal team members than customers or prospects, so a lot of their information is second hand. Great updates take into consideration not just the actual mechanism of the product but the benefit received by the customer. This is why most developers are shocked when they learn the cost of seats for a sales enablement tool. For example: Github, the tool where most company store all the code and workflows needed to run their product is either free, or, $4/user/month. Chili Piper, a tool that makes it a bit easier to book sales meetings, starts at $23/user/month, and goes up from there. To most developers’ shock, companies are willing to pay it! Not existing in the world of “benefits” makes it hard for most developers to write $23/user/month customer updates. ‍ ### Success All of the arguments for and against support also apply to success, with a few caveats. First, success can tend to be a bit more regulated in the amount of work (eg, every week you need to check in with X companies,) but are still susceptible to emergencies. If they check in with your number one customer and they say they might churn, that instantly becomes the top priority. Success usually has great customer relationships, maybe even beyond the scope of what support has. The success team also generally has an upsell goal, so being in charge of updates ensures that they know of all the new features and improvements, arming them to go into renewal calls with all the info that they need. Beyond that, the question of the success team owning customer updates is the exact same analysis as the support team owning it. ‍ ### Sales Hoo boy. To be honest I’ve never seen a company do this, and to the best of my knowledge no one has even suggested that the sales team be responsible for customer updates. However, in the interest of full exploration, I decided to include them in the list. The sales team has a number of strengths in owning customer updates, including: - An extreme benefits focused mindset, - A clear picture of current and future best fits customers, - An understanding of the market and competitors, - Strong communication skills, especially written communication, - Understanding of distribution and generally “getting the word out.” These are all super unique, strong skills that no other team brings. However, there are a few challenges. Just like the point I made about wanting your developers writing code, you also want your sales team selling. If they’re not ringing the bell, hitting the gong, or engaging in whatever brand of celebratory percussion you’ve decided on, they’re not providing the results you need to your company. Unlike developers, the sales team likely has the least insight into the product development process. Any hope that the sales team can paint a word picture of how a feature came to be is pretty misguided. Finally, I’d personally be a bit concerned of let’s say “over emphasizing” some of the finer points of what’s going on. Perhaps an update on a new admin panel may be communicated as “The best, greatest admin tool ever conceived by mankind,” or something along those lines. There’s definitely a fine line between benefits focused language and… well just going crazy town on it. I don’t suspect this article will convince anyone to put their sales team in charge of customer updates, and I don’t think that’s even my intention, but as food for thought I wanted to put this idea out into the world. ‍ ### Leadership I’ve generally seen executive level, CXO style updates either at very early stage companies, for BIG strategically relevant updates, or for recap (like “2023 year in review” style updates.) For very small companies I might recommend this option on the basis of… there’s no one else :). Big strategy updates also make sense to come from leadership, and a yearly recap also makes sense to come from the leadership team. However, unless you’re the only one to do it, I haven’t seen in practice the ability for leadership teams to do anything more than a monthly shareholder update… and frankly most fail at doing that. Having the time, focus, and context to achieve weekly customer updates means not being able to do a whole lot more out of that scope, so almost instantly the leadership team is disqualified from owning customer updates. However, I do think there’s a lot the leadership team can do to help move the needle. Take this tweet for example: ![Tweet from Bobby Pinero about how writing a blog post every week at the beginning helped establish the habit of sharing ideas with the world](/_astro/twitter-screenshot.BjY1tOdQ_2oT1Wn.webp) _Source:_ [_Twitter.com_](https://twitter.com/bobbypinero/status/1737491135424004416) ‍ ## What should we do Brian? Am I allowed to say “it depends?” The answer unfortunately changes on a number of factors, including the size of your company, how complicated / technical your product is, and who in your company is already in touch with customers. I’ll provide some options and you can see which is the best fit for your team. First off, the “easy” way to solve this problem is to simply buy a product to do this work for you. I actually have a recommendation of the product you could use. In fact, this blog is the blog of the product. Without too much of a pitch, Changebot will effectively be your product marketing team for you if you don’t have one, or supercharge your existing team by picking up all the work they don’t really want to do (namely, turning code changes into great customer’s updates.) Click here to create your account and we’ll have a bunch of updates your way ASAP. The second option is a bit of an investment: consider spinning up a product marketing team. Per the list of departments that could own this, product marketing is by far the best choice. Customer updates are the life blood of any great product marketing team. It’s enough work that you’ll find that even for small teams, a full time product marketer will have their hands full, and you should see results relatively quickly. Option three is to elect a single “owner” for the more customer updates goal, and then share the task across all the teams. Your owner is the one who’s responsible for reporting on and hitting the goal. If you do team meetings to review goal progress this owner speaks to the number and talks about ways to improve that speed. This goal owner could be literally anyone, from a marketing lead, COO, support lead, etc. That goal owner probably can’t do everything, so they’d need help from the team to put everything together: Sales and support need to provide the pulse on what current and potential customers are talking about. Engineering speaks to the roadmap, what’s currently in progress, and then when things are being shipped. It’s important to know what’s in progress because the updates should be in the works as the work is being done, so the update can go live when the feature / bug fix goes live. This person will probably also need writing help, which could come from anywhere, but probably comes from marketing. Finally the goal owner will need help distributing the update, marketing can help get the update out on the blog, in app messaging, and social, support and success can get the message out to existing customers, and sales can help spread the word into the pipeline. With everyone’s part time help you can hit your goal without getting massively distracted from other work. And that’s… who’s responsible for customer updates. ![Animated GIF of a person in sunglasses giving a satisfied nod, representing confidence in completing the task](/_astro/meme-ace.CZur_p4d_2coeEU.webp) Source: [Tenor.com](https://tenor.com/view/meme-ace-kpop-wink-glasses-gif-14703118) [← Back to Blog](/blog) # Why Your Bug Fixes Deserve Their Own Announcements URL: https://www.changebot.ai/blog/why-bug-fixes-deserve-announcements/ Description: Most companies only announce new features. But your customers already saw the bug. Here's why you should tell them you fixed it. Last updated: 2025-12-20 Best Practices # Why Your Bug Fixes Deserve Their Own Announcements [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder December 20, 2025 4 min read ![Bug being squashed with checkmark on one side, megaphone broadcasting the fix on the other](/_astro/featured.35EeLAp5_ZSOSqX.webp) There’s a pattern I see in almost every changelog I review: features get announced, bug fixes get hidden. Companies will write detailed announcements for new capabilities. They’ll craft messaging, choose the right words, think about customer impact. Then they’ll ship a critical bug fix that affects hundreds of users and quietly note it as “Bug fixes and improvements” at the bottom of the release notes. This is backwards. ## The Embarrassment Trap The logic seems reasonable: announcing a bug fix means admitting the bug existed. Nobody wants to call attention to their mistakes. Better to fix it quietly and move on. Here’s the problem with that logic: your customers already know the bug exists. They experienced it, filed support tickets about it, and complained in Slack. They maybe even considered switching to a competitor because of it. When you fix the bug silently, you’re not avoiding embarrassment. You’re just failing to get credit for solving a problem your customers already know about. ## The Customer’s Perspective Put yourself in your customer’s shoes. They hit a frustrating bug last month and reported it, but heard nothing back. They assume you’re doing nothing about it. Three weeks later, they try the same workflow and it works. Do they think “Wow, great job fixing that”? No. They think “Huh, I guess it’s working now” and move on. Or worse, they assume the issue was a fluke and continue to work around it. Now imagine a different scenario: they reported the bug, and a week later they get an email saying “We heard your feedback about X. We’ve fixed it. Here’s what changed.” That customer now knows three things: 1. You’re listening 2. You’re responsive 3. You fix things that matter to them These are the things that prevent churn. ## The Support Loop Problem A VP of Product Marketing at an observability company told me one of their biggest challenges: “Churn drivers often relate to customers not knowing capabilities already exist.” This applies double to bug fixes. Support gets tickets about issues. Engineering fixes them. But the information often doesn’t flow back to the customers who reported the problems — or to support teams who are still triaging similar tickets. I’ve seen companies where support was still sending workaround instructions for bugs the team fixed weeks earlier. Nobody told them. The fix shipped silently, so support never updated their playbook. ## What Announcing Bug Fixes Actually Communicates Announcing a bug fix communicates more than “we fixed a bug.” You’re telling customers: **You’re actively maintaining the product.** Bugs happen. What matters is how quickly and reliably they get resolved. Announcing fixes shows you’re on top of things. **You put customer experience first.** You didn’t just ship features and move on. You invested engineering time in making the existing product work better. **You’re paying attention to feedback.** The customer who reported it feels heard. Everyone else sees that reporting issues leads to action. **You’re confident in your product.** Hiding fixes signals shame. Announcing them signals confidence that bugs are normal and you handle them well. ## The Competitive Angle Here’s something I’ve noticed when evaluating products: I check changelogs. I look for signs of life. A changelog that only shows new features every few months looks stagnant. A changelog that shows regular updates, including bug fixes and improvements, looks actively maintained. If I’m choosing between two products and one has a changelog showing weekly attention to detail while the other ships quarterly “big releases,” I know which one is more likely to fix my issues quickly when they arise. Your bug fix announcements are a competitive signal. They show you’re playing the long game, not just chasing new features. ## How to Announce Bug Fixes Well Not every bug fix needs a press release. But there’s a middle ground between silence and fanfare. **Tie it to customer impact.** Don’t say “Fixed null pointer exception in auth handler.” Say “Login is now more reliable for users with special characters in their passwords.” **Credit the feedback.** If a customer reported it, acknowledge that. “Thanks to feedback from users, we’ve fixed an issue where…” This encourages more reporting. **Be specific about what changed.** Vague “assorted fixes” announcements are almost worse than nothing. If you fixed the checkout flow, say you fixed the checkout flow. **Include improvements alongside fixes.** Bug fixes often come with small improvements. “Fixed the slow dashboard load times and added caching that makes it even faster” turns a fix into a positive story. **Route to the right audience.** Support teams need different detail than marketing newsletters. A customer success manager talking to a frustrated account needs to know exactly what you fixed and when. ## The Internal Communication First Here’s the real reason most bug fixes go unannounced: internal communication breaks down first. Support doesn’t know engineering fixed it. Marketing doesn’t know what was in the release. The PM who prioritized the fix moved on to the next sprint. By the time anyone thinks about announcing it, the moment has passed. Better announcement discipline won’t solve this. Better capture of what ships will. When fixing a bug automatically generates a record that routes to the right people, announcements stop falling through cracks. ## A Different Framing Think about it this way: every bug fix is proof that your product is getting better. Your customers want to know their product is improving. They want reassurance that you’re addressing the issues they’ve encountered. They want to see momentum. Feature announcements show you’re building new things. Bug fix announcements show you care about what you’ve already built. Both matter. Both build trust. The next time your team ships a fix, don’t bury it. Your customers saw the problem. Let them see the solution, too. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # Why Every Engineer Hates Jira (And How We Made It Worse) URL: https://www.changebot.ai/blog/why-every-engineer-hates-jira/ Description: Jira became the most hated tool in engineering because every team added their own fields and requirements. Here's how it happened and what to do instead. Last updated: 2025-12-22 Best Practices # Why Every Engineer Hates Jira (And How We Made It Worse) [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder December 22, 2025 5 min read ![Illustration of a developer silhouette overwhelmed by form fields and checkboxes, representing Jira bureaucracy](/_astro/featured.zSOk5WaU_Zuz8Rs.webp) Every engineer I’ve ever met has a complicated relationship with Jira. Some actively despise it. Others have resigned acceptance. Almost none would describe it as a tool that helps them do their best work. How did a project management tool become the most resented piece of software in engineering? The answer isn’t about Jira itself. It’s about what we did to it. ## The Centrifuge Problem Here’s what happened at every company I’ve worked at: 1. Engineering starts using Jira to track work 2. Sales asks: “Can we know when features are shipping?” → Add a field 3. Support asks: “Can we know which tickets relate to customer issues?” → Add a field 4. Marketing asks: “Can we know what’s customer-facing vs. internal?” → Add a field 5. Finance asks: “Can we track time for billing?” → Add a field 6. Legal asks: “Can we flag compliance-related changes?” → Add a field Each request was reasonable. Each field made sense in isolation. And collectively, they transformed Jira from a work-tracking tool into a data-entry burden. A VP of Engineering at a workplace software company described engineers as “burdened by extra Jira/form work to surface what’s shipped.” The form fields exist because other teams need visibility. But the cost falls entirely on engineering. ## The Tax Nobody Calculated When you add a required field to Jira, you’re adding a tax on every piece of work that flows through the system. Let’s say filling out the new field takes 30 seconds. Sounds negligible. But multiply that by: - 50 engineers - 20 tickets per engineer per week - 52 weeks per year That’s 8,667 hours of data entry per year. For one field. Now multiply by the 15 custom fields your organization has added over the years. Suddenly you’re looking at tens of thousands of engineering hours spent not on engineering. And that assumes everyone fills out every field. In reality, engineers skip fields whenever possible. Which means the data is incomplete. Which means whoever requested the field doesn’t get what they need. Which leads to meetings to fill the gap. Which adds more overhead. ## Why Engineers Don’t Fill Out the Fields The fundamental problem is incentive misalignment. The people who need the information (sales, support, marketing, leadership) aren’t the people who have to enter it. The people who have to enter it (engineers) gain nothing from doing so. An engineer finishing a feature is thinking about the next thing to build, not about updating a field for some downstream report they’ll never see. The field is friction between them and their actual work. This behavior is rational, not lazy. Every organization gets the data entry quality it incentivizes, and most organizations incentivize shipping code, not filling out forms. ## The Workarounds That Make It Worse When required fields don’t get filled out properly, teams create workarounds: **More meetings.** “Since we can’t trust the Jira data, let’s have a weekly sync to walk through what’s shipping.” **Shadow tracking.** Product managers create their own spreadsheets to track what’s actually happening because Jira doesn’t tell the full story. **Double data entry.** Someone (often a PM or TPM) manually updates Jira based on what they learned in the meeting or from the spreadsheet. Each workaround adds overhead. None of them solve the underlying problem: engineering’s work output isn’t automatically connected to the information other teams need. ## The Bigger Issue: Wrong Layer of Abstraction Jira captures intent: what we plan to work on. It doesn’t capture reality: what actually shipped. A ticket might say “Build Slack integration.” But that doesn’t tell you: - When did it ship? - What exactly does it do? - Which customers care about it? - How should support talk about it? - What’s the marketing angle? These questions require context that doesn’t live in the ticket. The ticket is a pointer to work, not a description of outcomes. Every field you add to Jira is trying to force that context into a place it doesn’t naturally fit. Engineers aren’t writing detailed release notes in Jira fields because that’s not what Jira is for. It’s a work management tool, not a communication platform. ## What Would Actually Help The solution isn’t better Jira hygiene or more disciplined field population. The solution is removing the need for manual data entry altogether. What if the information other teams need came automatically from the work itself? The code tells you what changed. The commit tells you when. The PR tells you why. The pattern of changes tells you what kind of change this represents (new feature, improvement, bug fix). If you can extract that information programmatically, engineers never have to fill out fields. The data is accurate because it comes from the source of truth: the code. And the information is timely because it updates automatically when code ships. This isn’t hypothetical. The raw material exists in every engineering organization. The question is whether you have a system that can turn it into actionable information for other teams. ## Reducing the Tax If you can’t remove manual data entry entirely, at least reduce it: **Audit your fields.** How many custom fields does your Jira have? How many get used? How many generate reports anyone reads? **Question new requests.** When someone asks for a new field, ask: What decision will this data inform? Is there another way to get that information? **Make fields optional.** Required fields that engineers skip anyway just create bad data. Optional fields with clear purpose get filled out when relevant. **Consider the cost.** Before adding a field, calculate the actual time cost across the organization. Is it worth 1,000 engineering hours to get that data? **Look for automated sources.** Can you get the same information from GitHub, deployment logs, or analytics without asking anyone to enter it manually? ## The Path Forward Jira didn’t become hated because it’s a bad tool. We made it hated by turning it into the universal interface for all cross-team information needs. That’s not what Atlassian built it for. Engineers should be able to focus on building. Other teams should be able to get the visibility they need. These goals don’t have to be in conflict. The answer isn’t asking engineers to be better at data entry. It’s building systems that capture the information automatically, at the source, without human intervention. Your engineers are expensive. Stop making them fill out forms. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # Why You Can't Vibe-Code Your Way to Good Release Communication URL: https://www.changebot.ai/blog/why-you-cant-vibe-code-release-communication/ Description: Teams think they can cobble together ChatGPT + scripts + Slack bots for release updates. Here's why that approach falls apart, and what it's actually worth to solve this problem properly. Last updated: 2025-12-29 Best Practices # Why You Can't Vibe-Code Your Way to Good Release Communication [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder December 29, 2025 5 min read ![Cobbled-together system with tangled wires and broken connections falling apart, contrasted with a clean integrated system](/_astro/featured.DHYFSHki_kV9vM.webp) “Why not just use ChatGPT for this? Or Copilot? Why don’t we build something internally?” A security leader asked me this recently during a product conversation. It’s a fair question. LLMs are everywhere now. Every engineer has access to them. The inputs for release communication (commits, PRs, tickets) are all machine-readable. How hard could it be? Here’s the thing: building something that works once isn’t hard. Building something that works every time, for every team, without constant maintenance? That’s a different problem entirely. ## The Vibe-Code Trap I’ve started calling the internal build approach “vibe-coding.” Someone spends a weekend wiring up a script that pulls commit messages, sends them to an LLM, and posts the output to Slack. It works. Everyone’s impressed. Six months later: - The script broke when GitHub changed their API - Nobody remembers how they structured the prompt - The person who built it left the company - Three different teams have their own versions that produce inconsistent outputs - The Slack channel it posts to is now muted by everyone This isn’t hypothetical. I hear variations of this story constantly. A security leader told me her company has “many teams using different AI tools with no unified operational layer.” The experimentation phase is exciting. The maintenance phase is where things fall apart. ## Why Simple Summarization Isn’t Enough The first version of any internal tool does simple summarization: pull the commit messages, send them to Claude or GPT, get back a paragraph. This works for about a week. Then you discover that commit messages like “fixed the thing” and “WIP” produce useless summaries. You need to look at the actual code changes. Then you discover that code changes without context produce technically accurate but user-meaningless updates. “Refactored authentication middleware” tells customers nothing. Then you discover that different audiences need different framings. Engineering wants technical detail, support wants customer impact, and executives want business metrics. Then you discover that last month’s update referenced a feature that was in development, not shipped. Now you need to track deployment state. Each of these is solvable. But each solution adds complexity. And each complexity layer requires maintenance. ## The Hidden Dependencies Here’s what a real release communication system needs to handle: **Temporal context.** A commit today might complete a feature that started three months ago. Understanding that requires tracking work over time, not just summarizing individual changes. **Product context.** “Added rate limiting” means different things for different products. A consumer app and an API-first B2B platform need different framings of the same technical change. **Audience context.** The Slack update for engineering isn’t the same as the customer changelog entry isn’t the same as the investor update. Same underlying change, different presentations. **Deployment state.** Not everything merged has shipped. Feature flags, staged rollouts, and multi-environment deployments mean “in main” doesn’t equal “live for customers.” **Approval workflows.** Someone needs to review before it goes out. That someone varies by audience and importance. The approval needs to happen in whatever tool they already use. **Distribution infrastructure.** Slack is one channel. Email is another. In-app notifications, hosted changelog pages, documentation sites: each has different formatting requirements and delivery mechanisms. A weekend project can handle one of these well. Handling them reliably is a product. ## The Maintenance Tax Even if you build something comprehensive, you inherit the maintenance burden. Every LLM API has rate limits, cost structures, and capability changes. Every integration (GitHub, Slack, Jira) has API versions that deprecate. Every internal tool depends on institutional knowledge that leaves when people leave. A VP of Product Marketing described her team’s situation: they have a changelog, updates get posted, but there’s a “backlog of unmessaged releases.” The system exists. The system doesn’t run itself. The maintenance tax recurs every month, every quarter, every year. The question isn’t “can we build this?” It’s “do we want to maintain this forever?” ## When Building Makes Sense Internal builds can work in specific situations: **Single audience, single channel.** If you only need engineering updates in one Slack channel, a simple script might be enough. **High internal tooling capacity.** Some companies have dedicated internal tools teams with bandwidth to maintain custom solutions. **Unique requirements.** If your workflow is genuinely different from everyone else’s, off-the-shelf tools might not fit. Most companies don’t fit these profiles. Most companies want release communication to work reliably without thinking about it. That’s not what you get from a weekend project. ## The Real Cost Calculation A security leader told me her monthly updates take four to five days. Let’s say that’s conservative: call it three days per month for most teams. Three days × 12 months = 36 days per year. For a product leader billing at $150/hour, that’s roughly $43,000 in time spent on a repetitive task. The internal build approach doesn’t remove that time. It shifts it. Instead of writing updates, you’re maintaining scripts. Instead of coordinating reviews, you’re debugging integrations. The work changes shape but doesn’t disappear. The question isn’t whether you can build something. The question is whether the build + maintenance cost is lower than buying a solution that already works. ## What Actually Solves This The systems that work, whether built internally or purchased, share common properties: **They aggregate context over time.** They track the full history of what this feature is and why it matters, beyond just today’s commits. **They translate for audiences.** Technical changes become customer benefits. Engineering details become business impact. **They integrate into existing workflows.** Not a new tool to check, but updates appearing where people already work. **They maintain themselves.** When the GitHub API changes, someone else fixes it. When the LLM improves, you get the benefit automatically. The vibe-coded solution works until it doesn’t. The production-grade solution works because someone’s job is maintaining it. ## MCP helps, but it does not remove the product work MCP makes the build path more tempting because it gives agents better access to source systems. That is useful. It also makes the boundary clearer. GitHub MCP plus Jira MCP plus a prompt can retrieve source material. It does not automatically give you a hosted changelog, review workflow, custom domain, widget, Slack routing, audience-specific versions, or a durable update history. Changebot’s MCP is built around the publishing outcome. The agent can draft and revise, but the system also handles review links, destinations, and the canonical changelog record. ## The Honest Assessment You probably can build something that generates release updates from your commits. The question is whether you should. If your team has spare engineering capacity, tolerance for ongoing maintenance, and genuinely unique requirements, building might make sense. If your team has limited bandwidth, wants to focus on your actual product, and has standard release communication needs, the build approach is likely more expensive than it appears. The vibe-code version looks cheap because it hides the costs. The maintenance happens later. The failures happen at inconvenient times. The institutional knowledge requirements aren’t obvious until someone leaves. Building your own release communication system is like building your own CRM: possible, occasionally justified, but often a distraction from what you’re trying to do. * * * If you’ve tried the internal build approach and found yourself maintaining scripts instead of shipping product, [start free](https://app.changebot.ai/signup) and publish through a workflow that is already built for changelogs. To see the MCP path, read the [Claude Code example](/blog/publish-your-changelog-from-claude-code). [← Back to Blog](/blog) # Why Your Release Notes Still Sound Like a Changelog URL: https://www.changebot.ai/blog/why-your-release-notes-still-sound-like-a-changelog/ Description: Most teams list what changed. Few explain why customers should care. Here's how to transform technical changes into customer value. Last updated: 2026-01-04 Best Practices # Why Your Release Notes Still Sound Like a Changelog [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder January 4, 2026 5 min read ![Transformation from dry technical changelog on the left to customer-friendly release notes on the right, connected by an arrow](/_astro/featured.MHF0C3j5_Z1eM9v8.webp) “It’s hard to correlate code-level changes to customer value.” A Head of Product Operations said this during a demo, and she nailed the core problem. Her team shipped constantly. They documented everything. But turning technical work into something customers cared about? That was the gap. Most release notes read like changelogs because that’s what they are: a list of what changed. The challenge is that customers don’t care what changed. They care why it matters to them. ## The Changelog Trap Here’s what a typical changelog entry looks like: > **Updated authentication module** Refactored the auth service to use OAuth 2.0 PKCE flow with improved token refresh handling. This is accurate. It’s also meaningless to most customers. What they want to know: Is logging in different? Is it more secure? Will their saved sessions break? Do they need to do anything? The technical description answers none of these questions. ## What Changed vs. Why It Matters The transformation from changelog to release notes is fundamentally about perspective shift: **Changelog perspective:** What did engineering do? **Release notes perspective:** What does the customer get? Here are some examples of the same changes, written both ways: ### Example 1: API Performance **Changelog:** Implemented connection pooling for database queries. Reduced average query time from 150ms to 45ms. **Release note:** API responses are now 3x faster. Reports that took ten seconds now load instantly. ### Example 2: File Upload **Changelog:** Added chunked upload support for files over 100MB. Implemented resume capability for interrupted uploads. **Release note:** You can now upload files up to 5GB, and if your connection drops, uploads pick up where they left off instead of starting over. ### Example 3: Error Handling **Changelog:** Refactored error handling middleware. Standardized error response format across all endpoints. **Release note:** Error messages now include specific guidance on how to fix the issue, instead of generic error codes. The technical work is the same. The framing is different. ## The Code-to-Value Translation During a recent demo, I showed how a simple code change (updating a robots.txt file) could become customer value. The technical change was “modified robots directives for the marketing pages.” The customer value was “your product pages are now properly indexed by search engines, which means customers can find you more easily.” Same change. Different audience, different framing. This translation requires understanding three things: **What actually changed:** The technical details of the work. **Who it affects:** Which customers, what use cases, what workflows. **Why it matters:** The benefit, improvement, or problem solved. Most teams stop at the first one. Good release notes require all three. ## Why This Is Hard If it were easy, everyone would do it. The translation problem is genuinely difficult: **Engineers know the what, not the why.** The person who wrote the code knows exactly what changed. They may not know how customers use the affected feature or what problems they were experiencing. **Product knows the why, not the what.** Product managers understand customer needs but may not grasp the technical details well enough to connect them. **The connection isn’t obvious.** A database index doesn’t sound customer-facing. But if it makes search 10x faster, that’s a significant user experience improvement. **Volume creates pressure.** When teams ship 50 changes a month, there isn’t time to thoughtfully translate each one. The path of least resistance is technical description. ## The Questions That Drive Translation When converting a technical change to a customer-facing note, ask: **“And that matters because…?”** Keep asking until you hit customer impact. “We upgraded the database.” Why does that matter? “Queries are faster.” Why does that matter? “Reports load in two seconds instead of ten.” There’s your release note. **“Who notices?”** Not every change is visible to every customer – some affect power users, some affect admins, and some affect everyone. The release note should reach the right audience. **“What problem does this solve?”** Customers experience problems, not solutions. Frame the change as a problem that went away. “You asked us to make bulk exports faster. Done.” **“What can they do now?”** Features enable capabilities. “You can now export up to 100,000 records at once” is more useful than “increased export batch size limit.” ## When Technical Detail Matters Not every release note should hide the technical details. Some audiences want them: **API consumers** care about endpoint changes, parameter modifications, and breaking changes. Give them the technical specifics. **Integration partners** need to know about authentication changes, webhook modifications, and data format updates. **Technical buyers** evaluating your platform want to see the infrastructure investments you’re making. The key is matching detail level to audience. Customer-facing release notes should lead with value. Developer changelogs should lead with technical specifics. Both can exist. ## The Packaging Problem A VP of Product Marketing described her team’s challenge: “The changelog exists, but it lacks packaging and positioning.” Packaging means: - **Grouping related changes** instead of listing them chronologically - **Featuring what matters** instead of treating everything equally - **Providing context** for why the team made the changes - **Including visuals** when they help understanding Positioning means: - **Framing changes as benefits** rather than features - **Connecting to customer problems** rather than engineering solutions - **Using language customers use** rather than internal terminology A changelog is raw. Release notes package and position the same content for different value to the reader. ## Making Technical Changes Customer-Friendly Here’s a process for translating technical changes: 1. **Start with the engineering description.** What actually changed? Get the technical details right. 2. **Identify the affected user journey.** Where does this change show up in the customer’s workflow? 3. **Name the before and after.** What was the experience before? What is it now? 4. **Write the benefit.** In one sentence, what improvement does the customer experience? 5. **Cut the jargon.** Remove technical terms that don’t add clarity for the target audience. 6. **Test with someone outside engineering.** If they don’t understand why it matters, rewrite. This takes time. But release notes that nobody reads aren’t worth publishing, no matter how little time they take. ## The Value Hierarchy Not all changes are equally important. A simple hierarchy helps decide what gets detailed coverage: **High value:** New capabilities, significant performance improvements, frequently requested features, security enhancements. These deserve full release note treatment. **Medium value:** Quality of life improvements, bug fixes for common issues, UI refinements. Brief mention with benefit framing. **Low value:** Internal refactors, dependency updates, code cleanup. May not need external mention at all. The mistake teams make is giving everything equal treatment. This buries the important in the mundane. ## The Real Test Pull up your last release notes. Read them as if you’re a customer who doesn’t know your codebase, your architecture, or your internal priorities. Do you understand why each change matters to you? Do you know what’s different about your experience? Do you care? If not, you’re publishing a changelog, not release notes. The work is there. The translation isn’t. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # Writing the Update Is Only Half the Battle URL: https://www.changebot.ai/blog/writing-the-update-is-only-half-the-battle/ Description: Most teams think the hard part is writing product updates. The real challenge? Getting them where they need to go. Last updated: 2025-12-27 Best Practices # Writing the Update Is Only Half the Battle [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder December 27, 2025 4 min read ![Document in center with distribution arrows branching to channel icons, some reaching destinations and others fading or breaking midway](/_astro/featured.BAgALkvy_Z1gLDCJ.webp) A Head of Engineering Processes at an AI consultancy put it bluntly during a recent call: “Distribution is a pain. Writing the update is one thing, getting it to clients in the right channel is another.” He wasn’t wrong. His team had the discipline to document their work, and they understood the value of keeping clients informed. The problem wasn’t creating the content but getting it from his team’s notes to his clients’ inboxes. This is a pattern I see constantly. Teams solve the creation problem and assume they’ve solved communication. They haven’t. ## The Creation Fallacy Here’s what typically happens: 1. Someone writes a solid product update 2. They post it somewhere: Slack, a wiki, maybe a changelog 3. They check the box: “communication done” 4. Half the people who needed that information never see it The update exists. The communication didn’t happen. A VP of Product Marketing at an observability company described her team’s situation: they have a changelog. Updates get posted. Yet there’s a “backlog of unmessaged releases,” features that shipped, got documented somewhere, and never reached the audiences who needed to know. At a consumer fintech company, the CEO told me their weekly product updates and monthly support recaps aren’t consistently read. The team produces the information. Customers just don’t consume it. ## Why Distribution Is Harder Than Writing Writing is a single act. Distribution is a systems problem. Consider what “getting the update out” actually requires: **Different audiences with different needs.** Your engineering team needs technical detail. Your support team needs customer-facing implications. Your marketing team needs positioning angles. Your customers need benefits. One update doesn’t fit all. **Different channels with different formats.** Slack wants short and punchy. Your blog wants longer and richer. Email needs a subject line hook. In-app notifications need to be scannable. Each destination has its own requirements. **Timing considerations.** Does support know before the feature goes live? Does marketing have time to prepare? Are customers learning about it from your announcement or from stumbling into the change? **Consistency over time.** A single well-distributed update is nice. A reliable cadence of well-distributed updates builds trust. Most teams can do the former occasionally. Almost none can do the latter consistently. One engineering leader planning a move to continuous delivery described documentation overhead as the primary blocker. The team can ship faster technically. They can’t communicate faster. ## The Consultancy Problem This gets even harder when your audience is external clients, not just internal teams. A head of an engineering consultancy explained their challenge: “We need to be constantly updating our clients on what we’re doing.” Different clients have different repo setups. Some work happens in client repositories, some in internal ones. The engagement structure fragments communication paths by design. For consultancies and agencies, distribution goes beyond channels to relationships. Each client expects updates tailored to their engagement. A generic “here’s what we shipped” blast doesn’t work when you’re billing hourly and clients want to see exactly what their investment produced. ## The Slack Trap Many teams think they’ve solved distribution because updates go to Slack. Slack is one channel, not distribution — one channel that everyone already uses for everything else. Updates compete with every other message for attention and scroll away within hours. People who aren’t in the right channel never see them, and people who are in the channel might be in a meeting when it posts. A product manager at a creator economy company described their current state: new features get posted in Slack and tracked in Notion. The system technically works. But “engineering does way more than anyone sees.” The visibility problem persists despite the process existing. Slack is fine as one destination among many. As the only destination, it guarantees information loss. ## What Distribution Actually Looks Like Teams that solve distribution treat it as infrastructure, not afterthought. **They push to where people already work.** If marketing lives in one tool and support lives in another, updates flow to both. Information comes to the person, not the other way around. **They match format to channel.** The Slack version is a brief summary with a link. The changelog has more detail. The customer email leads with benefits. Same underlying information, different packaging. **They maintain a canonical source.** Somewhere, the full version exists. Everything else points back to it. When the update needs correction, one edit propagates everywhere. **They automate the repetitive parts.** Manual distribution doesn’t scale. When publishing requires opening six tools and reformatting the same content six times, it won’t happen consistently. ## AI drafts still need a publishing layer This is why a generic AI draft does not solve distribution by itself. Claude can write a good paragraph. Linear can help generate a release note. Slack can contain the context. But unless that update lands somewhere durable, reviewed, and easy for customers to find, the communication still did not happen. An agent-first changelog treats publishing as part of the workflow. Ask for the update, review the draft, approve the customer version, and push it to the hosted changelog, widget, Slack, API, or custom domain from the same system. ## The Real Metric Here’s a useful test: pick a feature that shipped last month. Ask three people from different teams what it does and why it matters. If you get three confident, consistent answers, your distribution is working. If you get confusion, vague recollection, or “I think I saw something about that,” you have a creation problem masquerading as complete. Writing the update is necessary, but not enough. The work isn’t done until the information reaches the people who need it, in a format they can use, through a channel they actually check. * * * If distribution is your bottleneck, [start free](https://app.changebot.ai/signup) and publish your first update to a hosted changelog and widget. To see the agent-native path, read the [Changebot MCP example](/blog/publish-your-changelog-from-claude-code). [← Back to Blog](/blog) # Your Commit Messages Were Never Meant for Customers URL: https://www.changebot.ai/blog/your-commit-messages-were-never-meant-for-customers/ Description: The gap between what developers write in commit messages and what customers need to hear about your product is wider than you think. Here's why that matters. Last updated: 2026-01-28 Best Practices # Your Commit Messages Were Never Meant for Customers [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder January 28, 2026 3 min read ![Terminal with raw commit messages transforming through gears into a polished customer announcement card](/_astro/featured.By65PXk2_1O2PkY.webp) During an onboarding call with a software platform, we connected their GitHub and started processing their repositories. The engineer on the call warned us: “The commit messages are not the best.” That turned out to be an understatement. We’re talking “fix,” “whoops,” and messages that would make HR uncomfortable. And this isn’t unusual. This is normal. Every engineering team we’ve worked with has some version of this problem. Developers write commit messages for themselves, five minutes after the change. They’re breadcrumbs for debugging, and they fall apart as building blocks for customer communication. ## The translation gap is enormous Here’s what a commit message looks like: `fix edge case in notification handler` Here’s what the customer needs to hear: “Notifications now reliably trigger for all account types, including teams using custom notification preferences.” These are describing the same change. But one is useful to the person who wrote it, and the other is useful to the person who pays for the product. Most teams know this gap exists. They just don’t have a good way to bridge it. They either ignore it entirely or assign someone to manually translate engineering work into customer language, a task that requires understanding both the codebase and the customer’s world. ## Stale changelogs are worse than no changelog One CRM company we onboarded had a public changelog page on their website. Nobody had updated it in two or three years. They preferred starting fresh rather than drawing attention to the gap. This happens more often than you’d think. Teams launch a changelog with good intentions, keep it updated for a few months, and then the person responsible gets busy, the process breaks down, and suddenly your most recent update is from 2023. A stale changelog actively hurts you. When a prospect is evaluating your product, they check the changelog to see if you’re actively developing. A two-year gap says “this product is dead” louder than no changelog at all. ## The real cost: invisible features The bigger problem isn’t embarrassing commit messages or stale changelogs. It’s that your customers don’t know what you’ve built for them. A product lead at an enterprise software company told us: “We were always writing more software than any customer was finding out about.” They had customers cancel for missing features that actually existed. The features were there. The communication wasn’t. A documentation strategist at a security tools company put it differently: “No one person has complete cross-functional knowledge” to translate engineering changes into customer-impact messaging. The engineer knows what changed, the product manager knows why the team prioritized it, and the marketer knows how to frame it. But getting all three perspectives into one update? That’s where things fall apart. ## Commit messages are a starting point, not the finish line Better commit messages won’t solve this. Sure, descriptive commits help, but writing marketing copy isn’t an engineer’s job. Their job is to ship good code. Asking them to also be copywriters is adding a tax to the most productive part of your organization. The fix is building a system that takes what developers are already producing, code changes, PRs, ticket context, and translates that into language your customers actually care about. Not “added an index to the database,” but “search results now load faster.” This means understanding context that lives nowhere in a single commit: what the product does, who uses it, what they care about, and how this particular change makes their life better. It’s the kind of translation that requires knowing both the code and the customer. ## Every shipped change is a story worth telling Teams consistently underestimate which changes matter to customers. A “minor” bug fix might be the exact issue a customer has been complaining about for months. A performance improvement might be the reason a prospect picks you over a competitor. When an engineer says “it’s such a small change, is it even worth publishing?” the answer is almost always yes. Not every change needs a blog post. But every change deserves a record, a summary, and discoverability, because you never know which change is the one that tips a buying decision or prevents a cancellation. Your commit messages were never meant for customers. But the work behind those commits? That’s exactly what customers need to hear about. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # Your deploy message in Slack is not a changelog URL: https://www.changebot.ai/blog/your-deploy-message-in-slack-is-not-a-changelog/ Description: Developer posts 'released this morning' in Slack. A week later, nobody can find it. Here's why Slack-as-changelog fails and what to do instead. Last updated: 2026-02-28 Best Practices # Your deploy message in Slack is not a changelog [![](/_astro/brian-sierakowski.CVzujm3w_ZKVXOn.webp)](/blog/authors/brian-sierakowski/) [Brian Sierakowski](/blog/authors/brian-sierakowski/) Founder February 28, 2026 3 min read ![Illustration of ephemeral chat messages fading away contrasted with a solid permanent changelog record](/_astro/featured.B9tC-QeF_2lqndB.webp) Here’s a release communication workflow we hear about constantly. Developer deploys before business hours. Posts in Slack: “Released this morning, let me know if there are issues.” Product lead sees it, mentally notes what went out. Support might catch it, might not. And that’s the entire release communication process. Sound familiar? ## The Slack scroll problem Slack is great for real-time communication but terrible for record-keeping. A deploy message posted at 7 a.m. disappears by 10 a.m., and by Friday it’s gone. By next month, it might as well not exist. A product lead at a CRM company described this exact situation. His developer deploys and posts a Slack message. It’s responsible — the team knows something went live. But a week later, when someone asks “was this deployed?” nobody can find the message. Three weeks later, when a customer reports a bug that was actually fixed in that deploy, there’s no easy way to trace back to what shipped and when. Slack messages are ephemeral by nature. They serve the moment. They don’t serve the future. ## The audience problem Even if you could find every deploy message in Slack, they’d still fail as changelogs. Here’s why: developers write deploy messages for developers. They describe what happened technically. They don’t describe what it means for customers. “Deployed fix for null reference in billing module” is useful for the engineering team. It tells them what changed and where. It’s useless for the support team, who needs to know “some customers may have seen an error when viewing their invoices — this is now fixed.” It’s useless for the customer, who just wants to know the product works. And it’s useless for marketing, who might want to include “billing reliability improvements” in the next product update. Each audience needs different information from the same change. A Slack message serves one audience at best. ## The tribal knowledge trap When release communication lives in Slack, knowledge about what shipped becomes tribal. The people who were online when the message went out know what happened. Everyone else doesn’t. New hires are especially vulnerable. They don’t have the context to know which Slack channels to watch, which messages are important, and which deploys are just routine maintenance. They can’t search for “what changed in the billing module last month” because that information doesn’t exist in a searchable, structured format. The product lead we spoke with said support sometimes gets blindsided by changes they didn’t know about. Not because anyone hid the information — it sat right there in Slack. They just didn’t see it, or it landed in a channel they don’t check, or the wording didn’t signal “this affects customers.” We hear a version of this from almost every company we talk to. A VP of Product at another company told us that when support gets blindsided, it’s visible to the whole company because the questions happen in public Slack channels. The support team looks uninformed, the product team feels bad, and nobody is at fault — the process is. ## What Slack does well This isn’t an argument against posting in Slack. Developers should communicate deploys to the team. Real-time heads-up about what went live is genuinely valuable. The problem is when Slack is the only communication channel. When the deploy message is the entire changelog. When there’s no durable, searchable, audience-appropriate record of what shipped. Slack is a notification. It’s not documentation. Treating it as both means you get a mediocre version of each. ## Making deploy messages stick The goal isn’t to stop posting in Slack. You want a layer on top that captures deploy context and turns it into something persistent and useful. A deploy message in Slack says “this happened.” A changelog entry says “this happened, here’s what it means for you, and here’s where to find it next month when you need to reference it.” That translation (turning a developer notification into a structured, audience-appropriate record) is the gap most teams don’t realize they have until someone asks “what shipped last month?” and nobody can answer confidently. The teams that do this well don’t treat it as extra work. They treat it as the natural end of the deploy process. Code ships, tests pass, deploy goes out, changelog updates. When you automate the last step, it happens every time without adding to anyone’s plate. * * * [Start free](https://app.changebot.ai/signup) with a hosted changelog and agent workflow, or [choose the Changebot path that fits your team](/start). [← Back to Blog](/blog) # Compare Changebot — Changelog Tool Comparison Matrix URL: https://www.changebot.ai/compare/ Description: Compare Changebot to AnnounceKit, Beamer, Canny, Headway, and LaunchNotes: a dated feature and pricing matrix plus feature-by-feature breakdowns. Last updated: 2026-09-18 Comparisons # See How Changebot Stacks Up Feature-by-feature breakdowns against the tools you might be evaluating. In short Changebot is the only tool in this comparison that writes customer-facing updates from your commits. It publishes a hosted changelog, widget, custom domain, Slack, RSS, and MCP for free, then charges $99 per repository per month for the agent. AnnounceKit, Beamer, Canny, Headway, and LaunchNotes all require someone to write each update by hand. ## Changelog Tool Comparison Matrix | Feature | Changebot | AnnounceKit | Beamer | Canny | Headway | LaunchNotes | | --- | --- | --- | --- | --- | --- | --- | | Starting price | Free / $99 per repo/mo | $79/mo | Free / $59/mo Starter | Free / $79/mo Pro yearly | Free / $29/mo Pro | $249/mo | | AI-Generated Updates from Commits | $99/repo/mo | ✗ | ✗ | ✗ | ✗ | ✗ | | GitHub Integration | $99/repo/mo | ✗ | ✗ | Issue sync, Pro | ✗ | ✗ | | Bitbucket Integration | $99/repo/mo | ✗ | ✗ | ✗ | ✗ | ✗ | | Hosted Changelog | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | Embeddable Widgets | 15+ themes | Basic widget | Basic widget | Changelog widget | Basic widget | Basic widget | | Custom Domain | Free | Growth $129/mo | ✗ | Pro $79/mo+ | Pro $29/mo | Growth $249/mo | | Remove Branding | Free | Scale $339/mo | Starter $59/mo | Business add-on | Pro $29/mo | Growth $249/mo | | Multi-Destination Publishing | ✓ | ✗ | ✗ | Page, widget, email | ✗ | ✓ | | Slack Publishing | ✓ | ✓ | ✗ | Feedback alerts | Pro $29/mo | ✓ | | RSS / Atom Feeds | ✓ | ✓ | ✗ | RSS | ✗ | ✓ | | API Access | ✓ | ✓ | Starter $59/mo | ✓ | ✗ | ✓ | | SSO | Coming soon | Growth $129/mo | Scale $299/mo | Business (IdP) | ✗ | Growth $249/mo | Claims verified September 18, 2026 against each vendor's pricing page: [AnnounceKit](https://announcekit.app/pricing), [Beamer](https://www.getbeamer.com/pricing), [Canny](https://canny.io/pricing), [Headway](https://headwayapp.co/#pricing), [LaunchNotes](https://www.launchnotes.com/pricing). [ ## Best Changelog Software in 2026 Widget tools, feedback suites, and agent-first changelogs. Start here if you are still mapping the category. Read the guide →](/best-changelog-software)[ ## Changebot vs AnnounceKit User communication and changelog tool View comparison →](/compare/announcekit)[ ## Changebot vs Beamer User engagement platform with changelog, NPS, and feedback tools View comparison →](/compare/beamer)[ ## Changebot vs Canny Feedback portal with boards, votes, a public roadmap, and a changelog View comparison →](/compare/canny)[ ## Changebot vs Headway Simple changelog tool for SaaS products View comparison →](/compare/headway)[ ## Changebot vs LaunchNotes Enterprise product communications platform with changelog, roadmap, and feedback View comparison →](/compare/launchnotes) # AnnounceKit Alternative: Changebot vs AnnounceKit URL: https://www.changebot.ai/compare/announcekit/ Description: An AnnounceKit alternative for changelog publishing. Compare Changebot vs AnnounceKit on hosted changelogs, widgets, custom domains, Slack, and MCP/API. Free to start. Last updated: 2026-09-18 [Best changelog software](/best-changelog-software) # Changebot vs AnnounceKit An AnnounceKit alternative for changelog publishing AnnounceKit makes you write every update by hand. Changebot starts free with the full publishing layer, then adds $99/repo agent automation when you want drafts from your codebase. In short Changebot and AnnounceKit are both changelog tools. AnnounceKit starts at $79 per month and requires you to write every update by hand. Changebot publishes for free — hosted page, widget, custom domain, Slack, and MCP/API — and charges $99 per repository per month for agent-written updates drafted from GitHub or Bitbucket. ## TL;DR - → Free hosted changelog, widget, custom domain, MCP/API publishing, and Slack distribution - → 15+ embeddable widget themes vs basic widget options - → Free MCP/API publishing from Claude Code, ChatGPT, Slack, or your own agent - → Codebase automation and audience versions for $99 per repo when you want Changebot to write ## Feature-by-Feature Comparison | Feature | Changebot | AnnounceKit | | --- | --- | --- | | Core | | | | Hosted Changelog proof ↗ | ✓ | ✓ | | Custom Domain proof ↗ | Free | Growth $129/mo | | Draft & Publish Workflow proof ↗ | ✓ | ✓ | | Private & Public Feeds proof ↗ | ✓ | ✓ | | Tags & Categorization proof ↗ | ✓ | Labels only | | Import Existing Posts | ✓ | ✗ | | AI & Automation | | | | AI-Generated Updates from Commits proof ↗ | $99/repo/mo | ✗ | | AI Co-Writing / Chat in Editor proof ↗ | $99/repo/mo | ✗ | | Editions (Multi-Channel Variants) proof ↗ | $99/repo/mo | ✗ | | Recaps (Date-Range Summaries) proof ↗ | $99/repo/mo | ✗ | | Spotlight (Single Feature Updates) proof ↗ | $99/repo/mo | ✗ | | Commit Skip Patterns proof ↗ | $99/repo/mo | ✗ | | Branch Selection proof ↗ | $99/repo/mo | ✗ | | Deployment Notifications proof ↗ | $99/repo/mo | ✗ | | Distribution | | | | Embeddable Widgets proof ↗ | 15+ themes | Basic widget | | RSS / Atom Feeds proof ↗ | ✓ | ✓ | | Multi-Destination Publishing proof ↗ | ✓ | ✗ | | Boosters (Popups / Banners) proof ↗ | Via Widgets | Scale $339/mo | | Customization | | | | Multiple Hosted Templates proof ↗ | 3 templates | 1 template | | Widget Preview Tool proof ↗ | ✓ | ✗ | | Dark Mode proof ↗ | ✓ | ✓ | | Custom CSS proof ↗ | ✓ | Scale $339/mo | | Remove Branding proof ↗ | Free | Scale $339/mo | | Multi-Language Support proof ↗ | $99/repo/mo | Scale $339/mo | | Integrations | | | | GitHub Integration proof ↗ | $99/repo/mo | ✗ | | Bitbucket Integration proof ↗ | $99/repo/mo | ✗ | | Jira Integration proof ↗ | $99/repo/mo | Growth $129/mo | | Linear Integration | $99/repo/mo | ✗ | | Slack Publishing proof ↗ | ✓ | ✓ | | Webflow Publishing proof ↗ | ✓ | ✗ | | API Access proof ↗ | ✓ | ✓ | | Security & Admin | | | | Documented Security Controls | All plans | Enterprise only | | Security Vendor Review | All plans | Enterprise only | | SSO | Coming soon | Growth $129/mo | ## Things AnnounceKit Does That We Don't AnnounceKit has a few features we don't offer. If these are must-haves for your team, they might be the better fit. Email Digest to Subscribers Scale $339/mo User Segmentation Growth $129/mo NPS Surveys $42/mo add-on Feature Requests / Voting Growth $129/mo Roadmap Growth $129/mo ## What Only Changebot Does ### AI-Powered from Source Code Changebot reads your commits and generates human-readable updates automatically. Co-write with AI chat to iterate. AnnounceKit requires you to write every word manually. [Draft Together: AI Chat Now in Update Builder ↗](https://updates.changebot.ai/changebot/2026-02-08-draft-together-ai-chat-now-in-update-builder) ### Editions, Recaps & Spotlight Generate channel-specific variants with Editions, summarize sprints with Recaps, or highlight a single feature with Spotlight. AnnounceKit has none of these workflows. [One Update, Many Voices: Meet Editions ↗](https://updates.changebot.ai/changebot/2026-02-12-one-update-many-voices-meet-editions) ### Multi-Source Integrations Pull from GitHub, Bitbucket, Jira, and Linear in one workspace. AnnounceKit only offers Jira — and only on its Growth tier at $129/mo. [Bitbucket Integration Now Available ↗](https://updates.changebot.ai/changebot/2026-02-06-bitbucket-integration-now-available) ### 15+ Widget Themes & Preview Embed your changelog with developer-friendly themes like Catppuccin, Gruvbox, and Dracula. Preview live with generated React, Vue, or HTML code. AnnounceKit offers a basic widget. [Introducing Widget Preview ↗](https://updates.changebot.ai/changebot/2026-02-06-introducing-widget-preview) ### Publish Everywhere at Once Push updates to your changelog, Slack, Webflow, widgets, and RSS simultaneously. AnnounceKit keeps your updates siloed. [Publish Once, Reach Them All ↗](https://updates.changebot.ai/changebot/2025-08-28-publish-once-reach-them-all) ## Start Free, Add Power When Needed AnnounceKit charges for advanced changelog capabilities. Changebot gives away the publishing layer for free, then charges $99 per repo when you want agent-written updates, product-change answers, and automation. Pricing verified September 18, 2026 against [AnnounceKit's pricing page](https://announcekit.app/pricing). Changebot ### Free + Agent $0 publishing - ✓ Free hosted changelog, widget, and custom domain - ✓ Free MCP/API publishing from Claude Code or your own agent - ✓ Free Slack, Webflow, RSS, Atom, API, and webhooks - ✓ $99/repo/mo for Changebot-written updates and answers - ✓ White-label options included for free - ✓ Security controls and review gates AnnounceKit ### Scale $339 /mo - – Unlimited projects - – Manual writing only - – Custom domain & custom CSS - – Basic widget & boosters - – Jira integration - – Multi-language & remove branding ## Changebot vs AnnounceKit: FAQ Is Changebot cheaper than AnnounceKit? For publishing, yes: Changebot's hosted changelog, embeddable widget, custom domain, white-labeling, Slack distribution, and MCP/API publishing are free, while AnnounceKit's paid plans start at $79 per month. Changebot only charges when you want the agent to write updates for you, at $99 per repository per month. What can Changebot do that AnnounceKit cannot? Changebot connects to GitHub and Bitbucket and drafts customer-facing updates from the commits and pull requests that actually shipped, and it accepts updates over MCP from Claude Code, ChatGPT, or your own agent. AnnounceKit has no source-code integration and no MCP interface, so every update starts as a blank editor. What does AnnounceKit do that Changebot does not? AnnounceKit bundles user-engagement features Changebot does not offer: email digests to subscribers, user segmentation, NPS surveys, feature request voting, and a roadmap. Those sit on its Growth and Scale plans. If collecting feedback and running surveys is the primary job, AnnounceKit covers more ground. Can Changebot publish in multiple languages like AnnounceKit? Yes, through Editions, which generate channel-specific and language-specific variants of one update. Editions are part of the $99 per repository per month agent plan. AnnounceKit offers multi-language publishing on its higher tiers. Can I move my existing AnnounceKit changelog to Changebot? Yes. Changebot imports existing posts, so your published history moves with you, and a custom domain is free, so the changelog can keep living at the same address your customers already know. ## Ready to Switch? Import your existing AnnounceKit posts, then start publishing from a free agent-native changelog workflow. Upgrade only when you need Changebot to write from source context. [Get Started for Free →](https://app.changebot.ai/signup) # Beamer Alternative: Changebot vs Beamer URL: https://www.changebot.ai/compare/beamer/ Description: A Beamer alternative for changelog publishing. Compare Changebot vs Beamer on hosted changelogs, widgets, custom domains, Slack, MCP/API, and no MAU billing. Last updated: 2026-09-18 [Best changelog software](/best-changelog-software) # Changebot vs Beamer A Beamer alternative for changelog publishing Beamer is a user engagement platform where you write every update by hand and pay per active user. Changebot gives away the publishing layer for free, then charges per repo for agent-written updates, product-change answers, and automation. In short Changebot and Beamer both publish product updates. Beamer is a user-engagement platform billed by monthly active users, starting at $59 per month. Changebot publishes for free — hosted page, widget, custom domain, Slack, and MCP/API — and charges $99 per repository per month for agent-written updates drafted from your code. ## TL;DR - → Free hosted changelog, widget, custom domain, MCP/API publishing, and Slack distribution - → No MAU billing that punishes growth - → Free MCP/API publishing from Claude Code, ChatGPT, Slack, or your own agent - → Codebase automation for GitHub and Bitbucket when you need Changebot to monitor what shipped ## Feature-by-Feature Comparison | Feature | Changebot | Beamer | | --- | --- | --- | | Core | | | | Hosted Changelog proof ↗ | ✓ | ✓ | | Custom Domain proof ↗ | Free | ✗ | | Draft & Publish Workflow proof ↗ | ✓ | ✓ | | Private & Public Feeds proof ↗ | ✓ | ✓ | | Tags & Categorization proof ↗ | ✓ | ✓ | | Import Existing Posts | ✓ | ✗ | | AI & Automation | | | | AI-Generated Updates from Commits proof ↗ | $99/repo/mo | ✗ | | AI Co-Writing / Chat in Editor proof ↗ | $99/repo/mo | ✗ | | Editions (Multi-Channel Variants) proof ↗ | $99/repo/mo | ✗ | | Recaps (Date-Range Summaries) proof ↗ | $99/repo/mo | ✗ | | Spotlight (Single Feature Updates) proof ↗ | $99/repo/mo | ✗ | | Commit Skip Patterns proof ↗ | $99/repo/mo | ✗ | | Branch Selection proof ↗ | $99/repo/mo | ✗ | | Deployment Notifications proof ↗ | $99/repo/mo | ✗ | | Distribution | | | | Embeddable Widgets proof ↗ | 15+ themes | Basic widget | | RSS / Atom Feeds proof ↗ | ✓ | ✗ | | Multi-Destination Publishing proof ↗ | ✓ | ✗ | | Boosters (Popups / Banners) proof ↗ | Via Widgets | Starter $59/mo | | Push Notifications | ✗ | ✓ | | Customization | | | | Multiple Hosted Templates proof ↗ | 3 templates | 1 template | | Widget Preview Tool proof ↗ | ✓ | ✗ | | Dark Mode proof ↗ | ✓ | ✗ | | Custom CSS proof ↗ | ✓ | ✓ | | Remove Branding proof ↗ | Free | Starter $59/mo | | Multi-Language Support proof ↗ | $99/repo/mo | Starter $59/mo | | Integrations | | | | GitHub Integration proof ↗ | $99/repo/mo | ✗ | | Bitbucket Integration proof ↗ | $99/repo/mo | ✗ | | Jira Integration proof ↗ | $99/repo/mo | ✗ | | Linear Integration | $99/repo/mo | ✗ | | Slack Publishing proof ↗ | ✓ | ✗ | | Webflow Publishing proof ↗ | ✓ | ✗ | | API Access proof ↗ | ✓ | Starter $59/mo | | Zapier Integration | ✗ | Starter $59/mo | | Intercom Integration | ✗ | ✓ | | Security & Admin | | | | Documented Security Controls | All plans | ✗ | | Security Vendor Review | All plans | ✗ | | SSO | Coming soon | Scale $299/mo | | Team Collaboration | ✓ | Starter $59/mo | ## Things Beamer Does That We Don't Beamer is a broader user engagement platform with features beyond changelogs. If these are must-haves, they might be the better fit — but they come at a price. Push Notifications All plans NPS Surveys Paid add-on Feature Requests / Voting Paid add-on Public Roadmap Paid add-on Comments & Reactions Pro $119/mo User Segmentation Pro $119/mo User Onboarding / Product Tours Separate product Intercom Integration All plans ## What Only Changebot Does ### AI-Powered from Source Code Changebot reads your commits and generates human-readable updates automatically. Co-write with AI chat to iterate. Beamer requires you to write every word manually. [Draft Together: AI Chat Now in Update Builder ↗](https://updates.changebot.ai/changebot/2026-02-08-draft-together-ai-chat-now-in-update-builder) ### Free Publishing, Paid Agent Automation Publish from MCP/API workflows for free, then connect GitHub and Bitbucket when you want the $99/repo agent to draft from what shipped. Beamer has no codebase-aware changelog automation. [Bitbucket Integration Now Available ↗](https://updates.changebot.ai/changebot/2026-02-06-bitbucket-integration-now-available) ### Free Publishing, No MAU Limits Changebot starts with free hosted changelog publishing, widgets, custom domains, Slack, and MCP/API publishing. Beamer charges by MAU as your product grows. ### Editions, Recaps & Spotlight Generate channel-specific variants with Editions, summarize sprints with Recaps, or highlight a single feature with Spotlight. Beamer has none of these workflows. [One Update, Many Voices: Meet Editions ↗](https://updates.changebot.ai/changebot/2026-02-12-one-update-many-voices-meet-editions) ### 15+ Widget Themes & Preview Embed your changelog with developer-friendly themes like Catppuccin, Gruvbox, and Dracula. Preview live with generated React, Vue, or HTML code. Beamer offers one basic widget style. [Introducing Widget Preview ↗](https://updates.changebot.ai/changebot/2026-02-06-introducing-widget-preview) ### Publish Everywhere at Once Push updates to your changelog, Slack, Webflow, widgets, and RSS simultaneously. Beamer publishes to its widget and that's it — no Slack, no Webflow, no RSS. [Publish Once, Reach Them All ↗](https://updates.changebot.ai/changebot/2025-08-28-publish-once-reach-them-all) ## Free Publishing vs MAU Billing Beamer charges by monthly active users. Changebot gives away hosted changelogs, widgets, custom domains, Slack, and MCP/API publishing, then charges $99 per repo for agent-written updates, product-change answers, and automation. Pricing verified September 18, 2026 against [Beamer's pricing page](https://www.getbeamer.com/pricing). Changebot ### Free + Agent $0 publishing - ✓ Free hosted changelog, widget, and custom domain - ✓ Free MCP/API publishing from Claude Code or your own agent - ✓ Free Slack, Webflow, RSS, Atom, API, and webhooks - ✓ $99/repo/mo for Changebot-written updates and answers - ✓ Free white-label and security controls - ✓ Security controls and review gates Beamer ### Pro $119 /mo - – 10,000 MAU limit - – Manual writing only - – Basic widget & boosters - – Comments & reactions - – Basic segmentation - – No codebase automation ## Changebot vs Beamer: FAQ How does Changebot pricing compare to Beamer? Beamer bills by monthly active users, so the cost rises as your product grows, with paid plans starting at $59 per month. Changebot never bills by audience size: publishing is free at any traffic level, and the only paid component is the agent at $99 per repository per month. What can Changebot do that Beamer cannot? Changebot reads connected GitHub and Bitbucket repositories and drafts updates from what shipped, and it accepts drafts over MCP from Claude Code, ChatGPT, or your own agent. Beamer has no source-code integration and no MCP interface, so someone on your team writes every announcement manually. What does Beamer do that Changebot does not? Beamer is a broader engagement platform: push notifications, NPS surveys, feature-request voting, a public roadmap, comments and reactions, user segmentation, and product tours. Changebot does none of those. If in-app engagement is the main requirement, Beamer covers more than a changelog tool. Does Changebot have an in-app widget like Beamer? Yes, and it is free. The Changebot widget ships with 15 or more themes, full CSS customization, and a preview tool that generates React, Vue, or HTML embed code. Beamer's widget is part of its paid, user-count-based plans. Should we switch from Beamer to Changebot? Switch if your main job is publishing what shipped and the MAU bill is growing faster than the value. Stay on Beamer if you rely on its surveys, feedback voting, roadmap, or onboarding tours, since Changebot is a changelog tool rather than an engagement suite. ## Ready to Switch? Stop writing every update by hand and paying more as your audience grows. Start free with publishing and add $99/repo agent automation when you need it. [Get Started for Free →](https://app.changebot.ai/signup) # Canny Alternative: Changebot vs Canny URL: https://www.changebot.ai/compare/canny/ Description: A Canny alternative for changelogs. Canny is a feedback portal with a changelog on every plan. Changebot is changelog-first: free publishing, then $99/repo for drafts from what shipped. Last updated: 2026-09-18 [Best changelog software](/best-changelog-software) # Changebot vs Canny A Canny alternative for changelogs, not another feedback board Canny is a feedback portal: boards, votes, a public roadmap, and a changelog on every plan. Changebot is an agent-first changelog. This page is for teams evaluating Canny as a product-update tool, not for teams whose primary need is a feedback board. In short Changebot and Canny solve different jobs. Canny is a feedback portal with boards, votes, a roadmap, and a changelog, billed by tracked users from $79 per month. Changebot is a changelog-first tool: publishing is free, and $99 per repository per month buys agent-written updates drafted from your commits. ## TL;DR - → Canny includes a changelog on every plan. Changebot is built for the changelog first. - → Free hosted changelog, widget, custom domain, SSO, MCP/API publishing, and Slack distribution - → Canny bills by tracked users. Changebot bills $99/repo for the agent that drafts from GitHub and Bitbucket. - → Canny Autopilot captures and triages feedback. It does not read your commits and write customer-facing updates. ## Feature-by-Feature Comparison | Feature | Changebot | Canny | | --- | --- | --- | | Core | | | | Hosted Changelog proof ↗ | ✓ | ✓ | | Custom Domain proof ↗ | Free | Pro $79/mo+ | | Draft & Publish Workflow proof ↗ | ✓ | ✓ | | Scheduled Publishing proof ↗ | ✓ | ✓ | | Private & Public Feeds proof ↗ | ✓ | Pro (privacy) | | Tags & Categorization proof ↗ | ✓ | Labels | | Import Existing Posts | ✓ | ✗ | | AI & Automation | | | | AI-Generated Updates from Commits proof ↗ | $99/repo/mo | ✗ | | AI Co-Writing / Chat in Editor proof ↗ | $99/repo/mo | ✗ | | Canny Autopilot | ✗ | Feedback capture | | Editions (Multi-Channel Variants) proof ↗ | $99/repo/mo | ✗ | | Recaps (Date-Range Summaries) proof ↗ | $99/repo/mo | ✗ | | Spotlight (Single Feature Updates) proof ↗ | $99/repo/mo | ✗ | | Commit Skip Patterns proof ↗ | $99/repo/mo | ✗ | | Branch Selection proof ↗ | $99/repo/mo | ✗ | | Deployment Notifications proof ↗ | $99/repo/mo | ✗ | | Distribution | | | | Embeddable Widgets proof ↗ | 15+ themes | Changelog widget | | RSS / Atom Feeds proof ↗ | ✓ | RSS | | Multi-Destination Publishing proof ↗ | ✓ | Page, widget, email | | Boosters (Popups / Banners) proof ↗ | Via Widgets | Widget badge | | Changelog Emails | ✗ | Pro $79/mo+ | | Customization | | | | Multiple Hosted Templates proof ↗ | 3 templates | 1 template | | Widget Preview Tool proof ↗ | ✓ | ✗ | | Dark Mode proof ↗ | ✓ | Portal theme | | Custom CSS proof ↗ | ✓ | ✗ | | Remove Branding proof ↗ | Free | Business add-on | | Multi-Language Support proof ↗ | $99/repo/mo | Browser auto-translate | | Integrations | | | | GitHub Integration proof ↗ | $99/repo/mo | Issue sync, Pro | | Bitbucket Integration proof ↗ | $99/repo/mo | ✗ | | Jira Integration proof ↗ | $99/repo/mo | Issue sync, Pro | | Linear Integration | $99/repo/mo | Issue sync, Pro | | Slack Publishing proof ↗ | ✓ | Feedback alerts | | Webflow Publishing proof ↗ | ✓ | ✗ | | API Access proof ↗ | ✓ | ✓ | | MCP Access | ✓ | Feedback + changelog tools | | Zapier Integration | ✗ | Pro $79/mo+ | | Security & Admin | | | | Documented Security Controls | All plans | SOC 2 | | Security Vendor Review | All plans | Business | | SSO | Free | Business (IdP) | | Team Collaboration | ✓ | Unlimited contributors | ## Things Canny Does That We Don't Canny is a feedback portal first. If you need voting boards, a public roadmap, or Autopilot to capture feedback, stay on Canny for that job. Changebot does not replace a feedback board. Feedback Boards & Voting All plans Public Roadmap All plans Tracked-User Feedback Billed by tracked users Canny Autopilot (feedback capture) All plans Changelog Email Subscribers Pro $79/mo+ Intercom, Zendesk, Gong Capture Autopilot sources User Segmentation Paid plans CRM (HubSpot, Salesforce) Business Zapier Integration Pro $79/mo+ ## What Only Changebot Does ### AI-Powered from Source Code Changebot reads your commits and drafts customer-facing updates. Canny Autopilot captures and triages feedback. It does not generate changelog entries from what shipped in GitHub or Bitbucket. [Draft Together: AI Chat Now in Update Builder ↗](https://updates.changebot.ai/changebot/2026-02-08-draft-together-ai-chat-now-in-update-builder) ### Repo Pricing, Not Tracked Users Changebot gives away hosted changelogs, widgets, custom domains, Slack, MCP/API publishing, and SSO. The agent is $99 per repo. Canny Pro starts at $79/mo yearly for 100 tracked users, then steps up as votes and comments grow. ### MCP for Publishing, Not Just Feedback Canny has an official MCP server for feedback data and changelog entries. Changebot MCP publishes customer-facing updates from Claude Code, ChatGPT, Slack, or your own agent, for free. ### Editions, Recaps & Spotlight Generate channel-specific variants with Editions, summarize sprints with Recaps, or highlight a single feature with Spotlight. Canny changelog writing is a markdown editor. [One Update, Many Voices: Meet Editions ↗](https://updates.changebot.ai/changebot/2026-02-12-one-update-many-voices-meet-editions) ### 15+ Widget Themes & Preview Embed your changelog with developer-friendly themes like Catppuccin, Gruvbox, and Dracula. Preview live with generated React, Vue, or HTML code. Canny offers a changelog widget with a notification badge. [Introducing Widget Preview ↗](https://updates.changebot.ai/changebot/2026-02-06-introducing-widget-preview) ### Publish the Update, Not Just the Vote Push changelog updates to your hosted page, Slack, Webflow, widgets, and RSS. Canny Slack is for feedback capture and alerts. Changelog email requires Pro, on top of the portal and widget. [Publish Once, Reach Them All ↗](https://updates.changebot.ai/changebot/2025-08-28-publish-once-reach-them-all) ## Free Publishing vs Tracked-User Billing Canny Pro starts at $79/mo yearly for 100 tracked users, then rises as attributed posts, votes, and comments grow. Changebot gives away the publishing layer, then charges $99 per repo for the agent that drafts from source. Pricing verified September 18, 2026 against [Canny's pricing page](https://canny.io/pricing). Changebot ### Free + Agent $0 publishing - ✓ Free hosted changelog, widget, and custom domain - ✓ Free MCP/API publishing from Claude Code or your own agent - ✓ Free Slack, Webflow, RSS, Atom, API, and webhooks - ✓ $99/repo/mo for Changebot-written updates and answers - ✓ Free white-label and security controls - ✓ SSO, security controls, and review gates Canny ### Pro $79 /mo yearly - – 100 tracked users to start, then increment table - – Public roadmap and changelog on every plan - – Custom domain and changelog email - – Manual changelog writing - – Autopilot for feedback, not source drafts - – SSO and CRM on Business ## Changebot vs Canny: FAQ Is Changebot a replacement for Canny? Only for the changelog. Canny's core is feedback collection: boards, voting, a public roadmap, and Autopilot capture from tools like Intercom and Zendesk. Changebot does not replace any of that. Teams that need both often keep Canny for feedback and use Changebot to publish what shipped. How does Changebot pricing compare to Canny? Canny Pro starts at $79 per month billed yearly for 100 tracked users and rises as attributed posts, votes, and comments grow. Changebot's publishing layer is free regardless of audience size, and the agent that drafts updates from source costs $99 per repository per month. Is Canny Autopilot the same as the Changebot agent? No. Canny Autopilot works on the feedback side: it captures, deduplicates, and triages incoming requests. The Changebot agent works on the output side: it reads the commits and pull requests in a connected repository and drafts the customer-facing update describing what shipped. Can AI tools publish to Changebot the way they cannot to Canny? Yes. Changebot exposes an MCP interface and a JSON API, so Claude Code, ChatGPT, Slack, or your own agent can write a draft straight into Changebot for review. Publishing through MCP or the API is free. Which is better for a changelog specifically? Changebot, because the changelog is the whole product rather than a module: 15 or more widget themes, three hosted templates, a free custom domain, RSS and Atom feeds, Slack and Webflow publishing, and agent-drafted updates. Canny's changelog is a solid companion to its feedback board, not a publishing platform. ## Need a Changelog, Not Another Board? If your job is a feedback portal, Canny is built for that. If product updates are a revenue lever, start free with publishing and add the $99/repo agent when you want drafts from what shipped. [Start Free →](https://app.changebot.ai/signup) # Headway Alternative: Changebot vs Headway URL: https://www.changebot.ai/compare/headway/ Description: A Headway alternative for changelog publishing. Compare Changebot vs Headway on hosted changelogs, widgets, custom domains, Slack, and MCP/API, then $99/repo agent automation. Last updated: 2026-09-18 [Best changelog software](/best-changelog-software) # Changebot vs Headway A Headway alternative for changelog publishing Headway is a simple, manual changelog tool. Changebot starts free with the full publishing layer, then adds codebase-aware agent automation when your team is ready. In short Changebot and Headway are both changelog tools. Headway is a manual editor whose Pro plan costs $29 per month for a custom domain, white-labeling, and Slack. Changebot gives those away free and adds $99 per repository per month agent automation that drafts updates from GitHub or Bitbucket. ## TL;DR - → Free hosted changelog, widget, custom domain, MCP/API publishing, and Slack distribution - → 15+ embeddable widget themes vs one basic widget - → Free MCP/API publishing from Claude Code, ChatGPT, Slack, or your own agent - → Codebase automation for GitHub and Bitbucket when you need Changebot to monitor what shipped ## Feature-by-Feature Comparison | Feature | Changebot | Headway | | --- | --- | --- | | Core | | | | Hosted Changelog proof ↗ | ✓ | ✓ | | Custom Domain proof ↗ | Free | Pro $29/mo | | Draft & Publish Workflow proof ↗ | ✓ | ✓ | | Scheduled Publishing proof ↗ | ✓ | Pro $29/mo | | Private & Public Feeds proof ↗ | ✓ | Pro $29/mo | | Tags & Categorization proof ↗ | ✓ | Categories only | | Import Existing Posts | ✓ | ✗ | | AI & Automation | | | | AI-Generated Updates from Commits proof ↗ | $99/repo/mo | ✗ | | AI Co-Writing / Chat in Editor proof ↗ | $99/repo/mo | ✗ | | Editions (Multi-Channel Variants) proof ↗ | $99/repo/mo | ✗ | | Recaps (Date-Range Summaries) proof ↗ | $99/repo/mo | ✗ | | Spotlight (Single Feature Updates) proof ↗ | $99/repo/mo | ✗ | | Commit Skip Patterns proof ↗ | $99/repo/mo | ✗ | | Branch Selection proof ↗ | $99/repo/mo | ✗ | | Deployment Notifications proof ↗ | $99/repo/mo | ✗ | | Distribution | | | | Embeddable Widgets proof ↗ | 15+ themes | Basic widget | | RSS / Atom Feeds proof ↗ | ✓ | ✗ | | Multi-Destination Publishing proof ↗ | ✓ | ✗ | | Boosters (Popups / Banners) proof ↗ | Via Widgets | ✗ | | Customization | | | | Multiple Hosted Templates proof ↗ | 3 templates | 1 template | | Widget Preview Tool proof ↗ | ✓ | ✗ | | Dark Mode proof ↗ | ✓ | ✗ | | Custom CSS proof ↗ | ✓ | ✗ | | Remove Branding proof ↗ | Free | Pro $29/mo | | Multi-Language Support proof ↗ | $99/repo/mo | ✗ | | Integrations | | | | GitHub Integration proof ↗ | $99/repo/mo | ✗ | | Bitbucket Integration proof ↗ | $99/repo/mo | ✗ | | Jira Integration proof ↗ | $99/repo/mo | ✗ | | Linear Integration | $99/repo/mo | ✗ | | Slack Publishing proof ↗ | ✓ | Pro $29/mo | | Webflow Publishing proof ↗ | ✓ | ✗ | | API Access proof ↗ | ✓ | ✗ | | Zapier Integration | ✗ | Pro $29/mo | | Security & Admin | | | | Documented Security Controls | All plans | ✗ | | Security Vendor Review | All plans | ✗ | | SSO | Coming soon | ✗ | | Team Collaboration | ✓ | Pro $29/mo | ## Things Headway Does That We Don't Headway has a couple of features we don't currently offer. If these are must-haves, they might be worth considering. Zapier Integration Pro $29/mo Direct Twitter Posting Pro $29/mo ## What Only Changebot Does ### AI-Powered from Source Code Changebot reads your commits and generates human-readable updates automatically. Co-write with AI chat to iterate. Headway requires you to write every word manually in a basic markdown editor. [Draft Together: AI Chat Now in Update Builder ↗](https://updates.changebot.ai/changebot/2026-02-08-draft-together-ai-chat-now-in-update-builder) ### Source Code Integrations Pull from GitHub, Bitbucket, Jira, and Linear in one workspace. Headway has zero source code or project management integrations — every update starts from scratch. [Bitbucket Integration Now Available ↗](https://updates.changebot.ai/changebot/2026-02-06-bitbucket-integration-now-available) ### Editions, Recaps & Spotlight Generate channel-specific variants with Editions, summarize sprints with Recaps, or highlight a single feature with Spotlight. Headway has a markdown editor and that's it. [One Update, Many Voices: Meet Editions ↗](https://updates.changebot.ai/changebot/2026-02-12-one-update-many-voices-meet-editions) ### 15+ Widget Themes & Preview Embed your changelog with developer-friendly themes like Catppuccin, Gruvbox, and Dracula. Preview live with generated React, Vue, or HTML code. Headway offers one basic widget style. [Introducing Widget Preview ↗](https://updates.changebot.ai/changebot/2026-02-06-introducing-widget-preview) ### Publish Everywhere at Once Push updates to your changelog, Slack, Webflow, widgets, and RSS simultaneously. Headway publishes to your changelog page and that's about it. [Publish Once, Reach Them All ↗](https://updates.changebot.ai/changebot/2025-08-28-publish-once-reach-them-all) ### Practical Security Controls Changebot emphasizes practical controls: read-only access, scoped permissions, audit logs, human review gates, and security vendor review support. SAML/OIDC SSO is coming soon. Headway offers a simpler security posture. ## Start Free, Add Agent Automation Headway Pro charges for a basic manual changelog with white-labeling. Changebot gives away the publishing layer for free, then charges $99 per repo when you want the agent to write from source context and run automation. Pricing verified September 18, 2026 against [Headway's pricing page](https://headwayapp.co/#pricing). Changebot ### Free + Agent $0 publishing - ✓ Free hosted changelog, widget, and custom domain - ✓ Free MCP/API publishing from Claude Code or your own agent - ✓ Free Slack, Webflow, RSS, Atom, API, and webhooks - ✓ $99/repo/mo for Changebot-written updates and answers - ✓ Free white-label and security controls - ✓ Security controls and review gates Headway ### Pro $29 /mo - – Unlimited changelogs - – Manual writing only - – Custom domain & remove branding - – Basic widget - – Slack & Zapier integration - – No published security posture ## Changebot vs Headway: FAQ Is Changebot cheaper than Headway? For the features Headway charges for, yes. Headway Pro is $29 per month for a custom domain, removed branding, scheduled publishing, and Slack. Changebot includes all of those for free, and charges only for the agent that writes updates from your repository, at $99 per repository per month. What can Changebot do that Headway cannot? Changebot drafts updates from connected GitHub and Bitbucket repositories, accepts drafts over MCP from AI tools, publishes to Slack, Webflow, RSS, Atom, webhooks, and an API at once, and offers 15 or more widget themes. Headway is a manual markdown editor with one basic widget and no source integrations. What does Headway do that Changebot does not? Headway offers a Zapier integration and direct posting to Twitter on its $29 per month Pro plan. Changebot has neither today, though its webhooks and JSON API cover many of the same automation cases. Can I keep my custom domain if I move from Headway? Yes. Custom domains are free on Changebot, and Changebot can import your existing posts, so the changelog keeps its address and its history. Does Changebot write release notes automatically? Yes, on the $99 per repository per month plan. Changebot reads the commits, pull requests, and releases in a connected repository, groups related changes, identifies what is customer-facing, and drafts the update in your categories and voice. A human approves it before it publishes. ## Ready to Upgrade Your Changelog? Go from a manual changelog editor to a free publishing workflow. Add $99/repo agent automation only when you want Changebot to write from source context. [Get Started for Free →](https://app.changebot.ai/signup) # LaunchNotes Alternative: Changebot vs LaunchNotes URL: https://www.changebot.ai/compare/launchnotes/ Description: A LaunchNotes alternative for changelog publishing. Compare Changebot vs LaunchNotes on hosted changelogs, widgets, custom domains, Slack, and MCP/API. Free to start. Last updated: 2026-09-18 [Best changelog software](/best-changelog-software) # Changebot vs LaunchNotes A LaunchNotes alternative for changelog publishing LaunchNotes is an enterprise communications platform starting at $249/mo for 2 users. Changebot gives away changelog publishing, widgets, custom domains, Slack, and MCP/API publishing for free, then charges per repo for agent automation. In short Changebot and LaunchNotes both publish product updates. LaunchNotes is an enterprise product-communications platform starting at $249 per month for two users. Changebot publishes for free — hosted page, widget, custom domain, Slack, and MCP/API — and charges $99 per repository per month for agent-written updates drafted from source. ## TL;DR - → Free hosted changelog, widget, custom domain, MCP/API publishing, and Slack distribution - → Free MCP/API publishing from Claude Code, ChatGPT, Slack, or your own agent - → 15+ embeddable widget themes vs one basic widget - → GitHub and Bitbucket automation when you want updates drafted from what shipped ## Feature-by-Feature Comparison | Feature | Changebot | LaunchNotes | | --- | --- | --- | | Core | | | | Hosted Changelog proof ↗ | ✓ | ✓ | | Custom Domain proof ↗ | Free | Growth $249/mo | | Draft & Publish Workflow proof ↗ | ✓ | ✓ | | Private & Public Feeds proof ↗ | ✓ | ✓ | | Tags & Categorization proof ↗ | ✓ | ✓ | | Import Existing Posts | ✓ | ✗ | | AI & Automation | | | | AI-Generated Updates from Commits proof ↗ | $99/repo/mo | ✗ | | AI Co-Writing / Chat in Editor proof ↗ | $99/repo/mo | From Jira only | | Editions (Multi-Channel Variants) proof ↗ | $99/repo/mo | ✗ | | Recaps (Date-Range Summaries) proof ↗ | $99/repo/mo | ✗ | | Spotlight (Single Feature Updates) proof ↗ | $99/repo/mo | ✗ | | Commit Skip Patterns proof ↗ | $99/repo/mo | ✗ | | Branch Selection proof ↗ | $99/repo/mo | ✗ | | Deployment Notifications proof ↗ | $99/repo/mo | ✗ | | Distribution | | | | Embeddable Widgets proof ↗ | 15+ themes | Basic widget | | RSS / Atom Feeds proof ↗ | ✓ | ✓ | | Multi-Destination Publishing proof ↗ | ✓ | ✓ | | Boosters (Popups / Banners) proof ↗ | Via Widgets | ✗ | | Email Notifications | ✗ | Via ESP integrations | | Customization | | | | Multiple Hosted Templates proof ↗ | 3 templates | 1 template | | Widget Preview Tool proof ↗ | ✓ | ✗ | | Dark Mode proof ↗ | ✓ | ✗ | | Custom CSS proof ↗ | ✓ | ✓ | | Remove Branding proof ↗ | Free | Growth $249/mo | | Multi-Language Support proof ↗ | $99/repo/mo | ✗ | | Integrations | | | | GitHub Integration proof ↗ | $99/repo/mo | ✗ | | Bitbucket Integration proof ↗ | $99/repo/mo | ✗ | | Jira Integration proof ↗ | $99/repo/mo | Growth $249/mo | | Linear Integration | $99/repo/mo | ✗ | | Slack Publishing proof ↗ | ✓ | ✓ | | Webflow Publishing proof ↗ | ✓ | ✗ | | API Access proof ↗ | ✓ | ✓ | | Security & Admin | | | | Documented Security Controls | All plans | All plans | | Security Vendor Review | All plans | All plans | | SSO | Coming soon | Growth $249/mo | | Team Collaboration | ✓ | 2 users on Growth | ## Things LaunchNotes Does That We Don't LaunchNotes is a broader product communications platform. If you need roadmaps, feedback collection, or deep analytics integrations, they offer more — at a higher price. Product Roadmap Growth $249/mo Feedback Inbox & Idea Voting Growth $249/mo Email Digest / Notifications Via ESP integrations Microsoft Teams Integration Growth $249/mo Confluence Publishing Growth $249/mo Analytics Integrations (Segment, Amplitude, Mixpanel) Growth $249/mo Loom Video Integration Growth $249/mo Zapier Integration Growth $249/mo ## What Only Changebot Does ### AI-Powered from Source Code Changebot reads your commits and generates human-readable updates automatically. LaunchNotes can draft from Jira tickets, but has no connection to your actual source code — the gap between what shipped and what's announced stays wide. [Draft Together: AI Chat Now in Update Builder ↗](https://updates.changebot.ai/changebot/2026-02-08-draft-together-ai-chat-now-in-update-builder) ### Free Publishing, Simple Agent Pricing Changebot gives away the publishing layer, then charges $99 per repo for agent-written updates, product-change answers, and automation. LaunchNotes Growth starts at $249/mo for just 2 users, with custom pricing for more. ### Real Source Code Integrations Pull from GitHub, Bitbucket, Jira, and Linear in one workspace. LaunchNotes connects to Jira for ticket data, but has no GitHub or Bitbucket integration — you can't generate updates from what your engineers actually committed. [Bitbucket Integration Now Available ↗](https://updates.changebot.ai/changebot/2026-02-06-bitbucket-integration-now-available) ### Editions, Recaps & Spotlight Generate channel-specific variants with Editions, summarize sprints with Recaps, or highlight a single feature with Spotlight. LaunchNotes has announcement templates but no AI-driven content workflows. [One Update, Many Voices: Meet Editions ↗](https://updates.changebot.ai/changebot/2026-02-12-one-update-many-voices-meet-editions) ### 15+ Widget Themes & Preview Embed your changelog with developer-friendly themes like Catppuccin, Gruvbox, and Dracula. Preview live with generated React, Vue, or HTML code. LaunchNotes offers one basic widget. [Introducing Widget Preview ↗](https://updates.changebot.ai/changebot/2026-02-06-introducing-widget-preview) ### Self-Serve, No Sales Call Required Sign up, connect your repos, and start generating changelogs in minutes. LaunchNotes requires a sales process for anything beyond the Growth tier, and even Growth starts at $249/mo with a 14-day trial. ## Start Free Before You Buy a Suite LaunchNotes Growth starts at $249/mo for 2 users. Changebot gives away the publishing layer for free, then charges $99 per repo when you want agent-written updates, product-change answers, and automation. Pricing verified September 18, 2026 against [LaunchNotes's pricing page](https://www.launchnotes.com/pricing). Changebot ### Free + Agent $0 publishing - ✓ Free hosted changelog, widget, and custom domain - ✓ Free MCP/API publishing from Claude Code or your own agent - ✓ Free Slack, Webflow, RSS, Atom, API, and webhooks - ✓ $99/repo/mo for Changebot-written updates and answers - ✓ Free white-label and security controls - ✓ Security controls and review gates LaunchNotes ### Growth $249 /mo - – 2 users included - – AI drafts from Jira only - – Roadmap & feedback tools - – Basic widget & custom domain - – Slack, Teams, Confluence - – Security controls ## Changebot vs LaunchNotes: FAQ How much cheaper is Changebot than LaunchNotes? LaunchNotes Growth starts at $249 per month for two users. Changebot's publishing layer, including the hosted changelog, widget, custom domain, white-labeling, and Slack, costs nothing, and the agent that drafts updates from your repository is $99 per repository per month. What can Changebot do that LaunchNotes cannot? Changebot accepts updates over MCP from Claude Code, ChatGPT, Slack, or your own agent, and its agent drafts updates directly from connected GitHub and Bitbucket history. LaunchNotes is built around humans writing and approving announcements in its own workspace. What does LaunchNotes do that Changebot does not? LaunchNotes bundles a product roadmap, a feedback inbox with idea voting, Microsoft Teams and Confluence publishing, Loom video embeds, Zapier, and analytics integrations with Segment, Amplitude, and Mixpanel. Those are part of its $249 per month Growth plan. Changebot is a changelog tool and does not offer them. Is Changebot suitable for an enterprise team? It is built for teams that want controls without a suite: read-only repository access, scoped permissions, audit logging, and a human review gate before anything publishes, with security vendor reviews supported on every plan. SAML/OIDC single sign-on is on the roadmap rather than available today. Can we trial Changebot before leaving LaunchNotes? Yes, and there is no trial clock. Publishing is free indefinitely, so you can run a Changebot changelog alongside LaunchNotes, import existing posts, and only pay if you decide you want the agent writing your updates. ## Ready to Switch? Start with a free changelog publishing workflow, then add $99/repo agent automation when your team wants Changebot to write from source context. [Get Started for Free →](https://app.changebot.ai/signup) # Customers - Changebot URL: https://www.changebot.ai/customers/ Description: See how teams use Changebot to publish agent-first changelogs, keep customers informed, and turn shipping velocity into proof. # Trusted by Teams That Ship Product, engineering, support, and founder-led teams use Changebot to publish what changed without turning release communication into another project. [Get Started for Free](https://app.changebot.ai/signup) > "I showed someone my changelog during a demo and his jaw hit the floor when he saw we shipped 10 updates in the past 3 weeks. I'm making Changebot a core part of our messaging / marketing now." **Alkarim Lalani** CEO, Rollout > "Our new changelog has been a competitive super power for all of our portfolio companies. Now we're driving the market messaging. Changebot is the first product we install for any new acquisition." **Paul Lynch** CEO, Import.io ## How Teams Use Changebot ### Agent-First Publishing Draft in the Changebot Agent, Claude Code, ChatGPT, Slack, or Linear, then publish to a real changelog destination. [Learn more →](/product/agent) ### Free Hosted Changelog Start with a public page and embeddable widget so customers can see what is new even before repo automation is connected. [Learn more →](/product/publishing) ### Custom Domains Put release notes on your domain, remove Changebot branding, and make your changelog part of your customer experience. [Learn more →](/pricing) ### Codebase Automation Connect GitHub or Bitbucket so Changebot can draft weekly or monthly updates from what actually shipped. [Learn more →](/product/integrations) ## Backed By Changebot is backed by leading startup accelerators and technology companies. Google for Startups Microsoft for Startups AI Launchpad ## Ready to Publish What Changed? Get started for free with a hosted changelog, or choose the agent workflow that fits your team. [Get Started for Free](https://app.changebot.ai/signup) [Choose Your Path](/start) # Changelog Glossary - Changelogs, Release Notes, llms.txt, MCP URL: https://www.changebot.ai/glossary/ Description: Plain definitions of the terms that come up when teams publish product updates: changelogs, release notes, changelog widgets, llms.txt, and the Model Context Protocol. Glossary # Changelog Glossary Plain definitions of the terms that come up when teams publish product updates: changelogs, release notes, changelog widgets, llms.txt, and the Model Context Protocol. In short This glossary defines the vocabulary of product-update publishing: what a changelog is and how it differs from release notes, what a changelog widget does, what the llms.txt convention asks a site to publish, and how the Model Context Protocol lets AI agents write updates. [Get Started for Free](https://app.changebot.ai/signup) [See Changebot](/product) [ ## Changelog What is a changelog? A changelog is a dated, public record of the changes made to a product, listed newest first. Software teams publish one so customers, sales, and support can see what shipped without asking engineering. A changelog entry usually names the change, explains who it affects, and links to documentation. Read the definition →](/glossary/changelog/)[ ## Release notes What are release notes, and how do they differ from a changelog? Release notes are a written summary of what a specific release contains, published when that release ships. A changelog is the running list of those releases over time. Release notes describe one version in depth; a changelog is the archive readers scroll through. Read the definition →](/glossary/release-notes/)[ ## Changelog widget What is a changelog widget? A changelog widget is an embeddable component that shows recent product updates inside an application, usually behind a bell icon or a "What's new" link. It pulls from the same entries as the hosted changelog page, so one published update appears in both places. Read the definition →](/glossary/changelog-widget/)[ ## llms.txt What is llms.txt? llms.txt is a plain-text file at the root of a website that gives large language models a curated, Markdown-formatted map of the site's most useful content. It was proposed by Jeremy Howard in 2024 and is a convention, not a standard: no model is obliged to read it. Read the definition →](/glossary/llms-txt/)[ ## Model Context Protocol (MCP) What is MCP? The Model Context Protocol is an open standard, introduced by Anthropic in November 2024, that lets AI assistants connect to external tools and data sources through a common interface. An MCP server exposes tools; an MCP client such as Claude Code or ChatGPT calls them on the user's behalf. Read the definition →](/glossary/mcp/) # What is a changelog widget? - Changebot Glossary URL: https://www.changebot.ai/glossary/changelog-widget/ Description: A changelog widget is an embeddable component that shows recent product updates inside an application, usually behind a bell icon or a "What's new" link. It pulls from the same entries as the hosted changelog page, so one published update appears in both places. [Glossary](/glossary/) # What is a changelog widget? Changelog widget A changelog widget is an embeddable component that shows recent product updates inside an application, usually behind a bell icon or a "What's new" link. It pulls from the same entries as the hosted changelog page, so one published update appears in both places. ## Why teams embed one A hosted changelog page only reaches people who visit it. A widget puts the same updates in front of users while they are in the product, which is where a new feature is most likely to be tried. Unread indicators give returning users a reason to look. ## How it is installed Most widgets are a small script or component dropped into the application shell, with a generated snippet for React, Vue, or plain HTML. Styling is controlled through a theme and custom CSS so the widget matches the surrounding product rather than the vendor's brand. ## Related terms - [Changelog](/glossary/changelog/) — What is a changelog? - [Release notes](/glossary/release-notes/) — What are release notes, and how do they differ from a changelog? ## Publish your changelog for free Hosted changelog page, embeddable widget, custom domain, Slack, and MCP publishing at no cost. Add the agent when you want Changebot to write the updates. [Get Started for Free](https://app.changebot.ai/signup) # What is a changelog? - Changebot Glossary URL: https://www.changebot.ai/glossary/changelog/ Description: A changelog is a dated, public record of the changes made to a product, listed newest first. Software teams publish one so customers, sales, and support can see what shipped without asking engineering. A changelog entry usually names the change, explains who it affects, and links to documentation. [Glossary](/glossary/) # What is a changelog? Changelog A changelog is a dated, public record of the changes made to a product, listed newest first. Software teams publish one so customers, sales, and support can see what shipped without asking engineering. A changelog entry usually names the change, explains who it affects, and links to documentation. ## What goes in a changelog entry A useful entry answers three questions: what changed, who it affects, and what to do about it. Most teams categorize entries as new features, improvements, or fixes, and tag them so readers can filter to the parts of the product they use. Entries are written for customers, not for engineers. "Added pagination to the exports endpoint" is a commit message; "Exports over 10,000 rows now download in pages instead of timing out" is a changelog entry. ## Where a changelog lives A changelog is typically published as a hosted page on the product's own domain, mirrored into the product through an embeddable widget, and syndicated over RSS or Atom so other tools can subscribe. Many teams also push each entry to Slack for internal teams and customers in shared channels. Keeping the changelog on a public, crawlable URL matters beyond customers: search engines and AI assistants use it as the primary evidence of whether a product is actively developed. ## Changelog vs CHANGELOG.md Open source projects keep a CHANGELOG.md file in the repository, often following the Keep a Changelog convention and semantic versioning. That file is written for developers upgrading a dependency. A customer-facing changelog covers the same events in product language, and the two can coexist. ## Related terms - [Release notes](/glossary/release-notes/) — What are release notes, and how do they differ from a changelog? - [Changelog widget](/glossary/changelog-widget/) — What is a changelog widget? ## Publish your changelog for free Hosted changelog page, embeddable widget, custom domain, Slack, and MCP publishing at no cost. Add the agent when you want Changebot to write the updates. [Get Started for Free](https://app.changebot.ai/signup) # What is llms.txt? - Changebot Glossary URL: https://www.changebot.ai/glossary/llms-txt/ Description: llms.txt is a plain-text file at the root of a website that gives large language models a curated, Markdown-formatted map of the site's most useful content. It was proposed by Jeremy Howard in 2024 and is a convention, not a standard: no model is obliged to read it. [Glossary](/glossary/) # What is llms.txt? llms.txt llms.txt is a plain-text file at the root of a website that gives large language models a curated, Markdown-formatted map of the site's most useful content. It was proposed by Jeremy Howard in 2024 and is a convention, not a standard: no model is obliged to read it. ## What the file contains The file is Markdown: an H1 with the site or product name, a short summary, then lists of links with one-line descriptions of what each page covers. Many sites also publish an llms-full.txt containing the full text of those pages, so an assistant can retrieve the whole corpus in a single fetch. It is complementary to robots.txt and sitemap.xml rather than a replacement. robots.txt states who may crawl, sitemap.xml lists every URL, and llms.txt states which pages are worth reading and what they say. ## Why sites publish one HTML pages carry navigation, scripts, and styling that waste an assistant's context window and obscure the content. A Markdown index — and Markdown versions of the pages themselves — gives a model the substance without the markup, which makes accurate quoting and citation more likely. Changebot publishes both files: llms.txt as the index and llms-full.txt as the full corpus, alongside a Markdown twin of every content page. ## Related terms - [Changelog](/glossary/changelog/) — What is a changelog? - [Model Context Protocol (MCP)](/glossary/mcp/) — What is MCP? ## Publish your changelog for free Hosted changelog page, embeddable widget, custom domain, Slack, and MCP publishing at no cost. Add the agent when you want Changebot to write the updates. [Get Started for Free](https://app.changebot.ai/signup) # What is MCP? - Changebot Glossary URL: https://www.changebot.ai/glossary/mcp/ Description: The Model Context Protocol is an open standard, introduced by Anthropic in November 2024, that lets AI assistants connect to external tools and data sources through a common interface. An MCP server exposes tools; an MCP client such as Claude Code or ChatGPT calls them on the user's behalf. [Glossary](/glossary/) # What is MCP? Model Context Protocol (MCP) The Model Context Protocol is an open standard, introduced by Anthropic in November 2024, that lets AI assistants connect to external tools and data sources through a common interface. An MCP server exposes tools; an MCP client such as Claude Code or ChatGPT calls them on the user's behalf. ## How it works An MCP server describes the tools it offers — their names, arguments, and what they do. The client passes those descriptions to the model, and when the model decides to use one, the client executes the call and returns the result. The integration is written once and works with every MCP-compatible client. Before MCP, each assistant needed a bespoke plugin per tool. The protocol turns that into one server per tool, which is why adoption spread quickly across AI coding and chat clients. ## What it means for changelogs The agent already sitting in your editor knows what changed. With an MCP interface in front of a changelog tool, that agent can draft the update and submit it for review without anyone copying text between windows. Changebot exposes MCP publishing on its free tier. ## Related terms - [Release notes](/glossary/release-notes/) — What are release notes, and how do they differ from a changelog? - [llms.txt](/glossary/llms-txt/) — What is llms.txt? ## Publish your changelog for free Hosted changelog page, embeddable widget, custom domain, Slack, and MCP publishing at no cost. Add the agent when you want Changebot to write the updates. [Get Started for Free](https://app.changebot.ai/signup) # What are release notes, and how do they differ from a changelog? - Changebot Glossary URL: https://www.changebot.ai/glossary/release-notes/ Description: Release notes are a written summary of what a specific release contains, published when that release ships. A changelog is the running list of those releases over time. Release notes describe one version in depth; a changelog is the archive readers scroll through. [Glossary](/glossary/) # What are release notes, and how do they differ from a changelog? Release notes Release notes are a written summary of what a specific release contains, published when that release ships. A changelog is the running list of those releases over time. Release notes describe one version in depth; a changelog is the archive readers scroll through. ## Release notes vs changelog The difference is scope and shape, not subject. Release notes are tied to a version or a date range and often include context, screenshots, upgrade steps, and known issues. A changelog is the chronological index of entries, optimized for scanning rather than reading. In practice most teams write release notes and publish them as changelog entries, so the changelog becomes the archive of every set of release notes they have written. ## What good release notes contain State the user-visible outcome first, then the detail. Group related changes so a reader sees one coherent story rather than fifteen commits. Call out anything that requires action: breaking changes, deprecations, migrations, or new settings that default to off. Write a version for each audience that needs one. Customers need the outcome; support needs the edge cases and the workaround; sales needs the sentence they can say on a call. ## Who writes them Release notes are usually written by product marketing, a product manager, or the engineer who shipped the change. Because the raw material lives in commits, pull requests, and issue trackers, teams increasingly draft them with an AI agent that reads that history and then have a human review the draft before it publishes. ## Related terms - [Changelog](/glossary/changelog/) — What is a changelog? - [Model Context Protocol (MCP)](/glossary/mcp/) — What is MCP? ## Publish your changelog for free Hosted changelog page, embeddable widget, custom domain, Slack, and MCP publishing at no cost. Add the agent when you want Changebot to write the updates. [Get Started for Free](https://app.changebot.ai/signup) # Pricing - Free Publishing, $99/Repo Agent Automation URL: https://www.changebot.ai/pricing/ Description: Write and publish updates for free through hosted changelogs, widgets, custom domains, Slack, MCP, and APIs. Upgrade for Changebot-written updates, source-aware answers, and automation. # Publishing Is Free. Agents Are $99/Repo. Get started for free. Write your own updates, publish them through Changebot, and send them to every customer-facing destination. Pay only when you want Changebot to read your source systems, explain what changed, write the updates, and run the automation for you. In short Changebot is free to publish with: a hosted changelog page, an embeddable widget, a custom domain, Slack distribution, RSS and Atom feeds, and MCP/API publishing all cost nothing. The paid Agent plan is $99 per repository per month and connects GitHub or Bitbucket so Changebot writes customer-facing updates from what shipped. [Get Started for Free](https://app.changebot.ai/signup) ## Bring Your Own Words If you write the update yourself, generate it in Claude Code, or push it through MCP/API, Changebot gives it a durable home for free. ## If You Do the Work, Publishing Is Free Other changelog tools make your team track what changed, write the update, then pay to host and distribute it. With Changebot, that publishing layer is free. You only pay when our agent does the work. ## Pay for the Agent The paid product starts when Changebot connects to your source systems, explains what changed for non-technical teams, writes the update, and runs recurring automation. ## Free The basics everyone else charges for are free $0 /mo - Google sign-in, onboarding, and team access - Write your own updates in Changebot - Publish updates from Claude Code, MCP, or the API - Hosted changelog page with custom domain - Embeddable widget with themes and CSS customization - Slack, Webflow, RSS, Atom, API, and webhooks - Draft, review, approve, and publish workflow [Get Started for Free →](https://app.changebot.ai/signup) ## Agent When Changebot writes and automates $99 /repo/mo - Everything in Free - Connect GitHub, Bitbucket, Jira, and Linear context - Product-change briefings for support, sales, and leadership - Ask what changed by feature, customer impact, or date range - Agent-written updates from commits, PRs, tickets, and releases - Daily, weekly, and monthly automated recaps - Internal update and customer changelog automation - Branch selection, commit skip patterns, and deployment signals [Get Started for Free →](https://app.changebot.ai/signup) ## Enterprise Procurement, scale, and custom controls Let's talk - Everything in Agent - Volume pricing for many repos - Dedicated onboarding and support - SLA & uptime guarantees - Custom retention and security requirements - Security review support - Custom agent workflows [Get Started for Free →](https://app.changebot.ai/signup) ## Don't take our word for it, see what our clients say. ![Illustration of a figure presenting a laptop with updates to an amazed viewer](/_astro/testimonial-demo-wow.BbZ6IWVl_Z1UEXN4.webp) “ "I showed someone my changelog during a demo and his jaw hit the floor when he saw we shipped 10 updates in the past 3 weeks. I'm making Changebot a core part of our messaging / marketing now." **Alkarim Lalani** CEO, Rollout ![Illustration of a rocket launching from connected buildings trailing update cards](/_astro/testimonial-competitive-edge.PGW_aS9M_1EpYw0.webp) “ "Our new changelog has been a competitive super power for all of our portfolio companies. Now we're driving the market messaging. Changebot is the first product we install for any new acquisition." **Paul Lynch** CEO, Import.io ## Pricing FAQ How much does Changebot cost? Publishing is free with no seat limits or monthly-active-user billing. The Agent tier is $99 per repository per month and covers agent-written updates from commits, pull requests, and tickets, product-change answers for support and sales, and automated recaps. Enterprise pricing is available for volume, procurement, and custom controls. What is included in the free plan? Google sign-in and team access, writing updates in Changebot, publishing from Claude Code, MCP, or the API, a hosted changelog page with a custom domain, the embeddable widget with themes and CSS customization, Slack, Webflow, RSS, Atom, webhooks, and the full draft, review, approve, and publish workflow. Is there a free trial or a credit card requirement? The free tier is a permanent plan rather than a trial, so you can publish a changelog indefinitely without paying. Upgrade only when you want Changebot to read your source systems and write the updates for you. Why is Changebot priced per repository instead of per seat? The paid work is reading a codebase and turning it into customer-facing updates, which scales with the number of repositories, not the number of people who read the changelog. Per-seat and monthly-active-user pricing penalize you for the outcome you want, which is more people seeing what shipped. What counts as a repository? One connected GitHub or Bitbucket repository that Changebot reads to draft updates, at $99 per month. Teams with many repositories should talk to us about volume pricing. # Privacy Policy URL: https://www.changebot.ai/privacy/ Description: Changebot Privacy Policy # Privacy Policy This privacy notice for Changebot, LLC ("we," "us," or "our"), describes how and why we might collect, store, use, and/or share ("process") your information when you use our services ("Services"), such as when you: - Visit our website at changebot.ai, or any website of ours that links to this privacy notice - Engage with us in other related ways, including any sales, marketing, or events **Questions or concerns?** Reading this privacy notice will help you understand your privacy rights and choices. If you do not agree with our policies and practices, please do not use our Services. **What personal information do we process?** When you visit, use, or navigate our Services, we may process personal information depending on how you interact with us and the Services, the choices you make, and the products and features you use. Learn more about personal information you disclose to us. **Do we process any sensitive personal information?** We do not process sensitive personal information. **Do we collect any information from third parties?** We do not collect any information from third parties. **How do we process your information?** We process your information to provide, improve, and administer our Services, communicate with you, for security and fraud prevention, and to comply with law. We may also process your information for other purposes with your consent. We process your information only when we have a valid legal reason to do so. Learn more about how we process your information. **What are your rights?** Depending on where you are located geographically, the applicable privacy law may mean you have certain rights regarding your personal data. ## 1\. What Information Do We Collect? ### Personal information you disclose to us _In Short: We collect personal information that you provide to us._ We collect personal information that you voluntarily provide to us when you register on the Services, express an interest in obtaining information about us or our products and Services, when you participate in activities on the Services, or otherwise when you contact us. **Personal Information Provided by You.** The personal information that we collect depends on the context of your interactions with us and the Services, the choices you make, and the products and features you use. The personal information we collect may include the following: - names - email addresses - usernames - passwords - contact preferences **Payment Data.** We may collect data necessary to process your payment if you choose to make purchases, such as your payment instrument number, and the security code associated with your payment instrument. All payment data is handled and stored by Stripe. You may find their privacy notice link(s) here: [https://stripe.com/privacy](https://stripe.com/privacy). All personal information that you provide to us must be true, complete, and accurate, and you must notify us of any changes to such personal information. ### Signing in with Google We offer the ability to register and log in using your Google account through Google Sign-In. If you choose to do this, Google shares with us the basic profile information associated with your account — your name and email address — so that we can create and authenticate your account. We use this information only to create and secure your account, set up your workspace, and communicate with you about the Services. We do not request access to your Gmail, Google Drive, Google Contacts, or any other Google service, and we do not sell this information. You can review and revoke Changebot's access to your Google account at any time in your [Google Account permissions](https://myaccount.google.com/permissions). ### Information automatically collected _In Short: Some information — such as your Internet Protocol (IP) address and/or browser and device characteristics — is collected automatically when you visit our Services._ We automatically collect certain information when you visit, use, or navigate the Services. This information does not reveal your specific identity (like your name or contact information) but may include device and usage information, such as your IP address, browser and device characteristics, operating system, language preferences, referring URLs, device name, country, location, information about how and when you use our Services, and other technical information. This information is primarily needed to maintain the security and operation of our Services, and for our internal analytics and reporting purposes. Like many businesses, we also collect information through cookies and similar technologies. The information we collect includes: **Log and Usage Data.** Log and usage data is service-related, diagnostic, usage, and performance information our servers automatically collect when you access or use our Services and which we record in log files. Depending on how you interact with us, this log data may include your IP address, device information, browser type, and settings and information about your activity in the Services (such as the date/time stamps associated with your usage, pages and files viewed, searches, and other actions you take such as which features you use), device event information (such as system activity, error reports (sometimes called "crash dumps"), and hardware settings). ## 2\. How Do We Process Your Information? _In Short: We process your information to provide, improve, and administer our Services, communicate with you, for security and fraud prevention, and to comply with law. We may also process your information for other purposes with your consent._ We process your personal information for a variety of reasons, depending on how you interact with our Services, including: To facilitate account creation and authentication and otherwise manage user accounts. We may process your information so you can create and log in to your account, as well as keep your account in working order. To deliver and facilitate delivery of services to the user. We may process your information to provide you with the requested service. ## 3\. When and With Whom Do We Share Your Personal Information? _In Short: We may share information in specific situations described in this section and/or with the following third parties._ We may need to share your personal information in the following situations: **Business Transfers.** We may share or transfer your information in connection with, or during negotiations of, any merger, sale of company assets, financing, or acquisition of all or a portion of our business to another company. ## 4\. Do We Use Cookies and Other Tracking Technologies? _In Short: We may use cookies and other tracking technologies to collect and store your information._ We may use cookies and similar tracking technologies (like web beacons and pixels) to gather information when you interact with our Services. Some online tracking technologies help us maintain the security of our Services and your account, prevent crashes, fix bugs, save your preferences, and assist with basic site functions. ### Google Analytics We may share your information with Google Analytics to track and analyze the use of the Services. To opt out of being tracked by Google Analytics across the Services, visit [https://tools.google.com/dlpage/gaoptout](https://tools.google.com/dlpage/gaoptout). For more information on the privacy practices of Google, please visit the Google Privacy & Terms page. ## 5\. How Long Do We Keep Your Information? _In Short: We keep your information for as long as necessary to fulfill the purposes outlined in this privacy notice unless otherwise required by law._ We will only keep your personal information for as long as it is necessary for the purposes set out in this privacy notice, unless a longer retention period is required or permitted by law (such as tax, accounting, or other legal requirements). ## 6\. Do We Collect Information from Minors? _In Short: We do not knowingly collect data from or market to children under 18 years of age._ We do not knowingly collect, solicit data from, or market to children under 18 years of age, nor do we knowingly sell such personal information. By using the Services, you represent that you are at least 18 or that you are the parent or guardian of such a minor and consent to such minor dependent's use of the Services. If we learn that personal information from users less than 18 years of age has been collected, we will deactivate the account and take reasonable measures to promptly delete such data from our records. ## 7\. What Are Your Privacy Rights? _In Short: You may review, change, or terminate your account at any time, depending on your country, province, or state of residence._ **Opting out of marketing and promotional communications:** You can unsubscribe from our marketing and promotional communications at any time by clicking on the unsubscribe link in the emails that we send. You will then be removed from the marketing lists. However, we may still communicate with you — for example, to send you service-related messages that are necessary for the administration and use of your account, to respond to service requests, or for other non-marketing purposes. **Cookies and similar technologies:** Most Web browsers are set to accept cookies by default. If you prefer, you can usually choose to set your browser to remove cookies and to reject cookies. If you choose to remove cookies or reject cookies, this could affect certain features or services of our Services. ## 8\. Controls for Do-Not-Track Features Most web browsers and some mobile operating systems and mobile applications include a Do-Not-Track ("DNT") feature or setting you can activate to signal your privacy preference not to have data about your online browsing activities monitored and collected. At this stage, no uniform technology standard for recognizing and implementing DNT signals has been finalized. As such, we do not currently respond to DNT browser signals or any other mechanism that automatically communicates your choice not to be tracked online. If a standard for online tracking is adopted that we must follow in the future, we will inform you about that practice in a revised version of this privacy notice. California law requires us to let you know how we respond to web browser DNT signals. Because there currently is not an industry or legal standard for recognizing or honoring DNT signals, we do not respond to them at this time. ## 9\. Do United States Residents Have Specific Privacy Rights? _In Short: If you are a resident of Delaware, you may have the right to request access to and receive details about the personal information we maintain about you and how we have processed it, correct inaccuracies, get a copy of, or delete your personal information. You may also have the right to withdraw your consent to our processing of your personal information. These rights may be limited in some circumstances by applicable law._ ### Categories of Personal Information We Collect We have collected the following categories of personal information in the past twelve (12) months: - **A. Identifiers** - Contact details, such as real name, alias, postal address, telephone or mobile contact number, unique personal identifier, online identifier, Internet Protocol address, email address, and account name - **YES** - **B. Protected classification characteristics under state or federal law** - Gender, age, date of birth, race and ethnicity, national origin, marital status, and other demographic data - **NO** - **C. Commercial information** - Transaction information, purchase history, financial details, and payment information - **NO** - **D. Biometric information** - Fingerprints and voiceprints - **NO** - **E. Internet or other similar network activity** - Browsing history, search history, online behavior, interest data, and interactions with our and other websites, applications, systems, and advertisements - **NO** - **F. Geolocation data** - Device location - **NO** - **G. Audio, electronic, sensory, or similar information** - Images and audio, video or call recordings created in connection with our business activities - **NO** - **H. Professional or employment-related information** - Business contact details in order to provide you our Services at a business level or job title, work history, and professional qualifications if you apply for a job with us - **NO** - **I. Education Information** - Student records and directory information - **NO** - **J. Inferences drawn from collected personal information** - Inferences drawn from any of the collected personal information listed above to create a profile or summary about, for example, an individual's preferences and characteristics - **NO** - **K. Sensitive personal Information** - **NO** We may also collect other personal information outside of these categories through instances where you interact with us in person, online, or by phone or mail in the context of: - Receiving help through our customer support channels; - Participation in customer surveys or contests; and - Facilitation in the delivery of our Services and to respond to your inquiries. ### Sources of Personal Information Learn more about the sources of personal information we collect in "WHAT INFORMATION DO WE COLLECT?" ### How We Use and Share Personal Information Learn about how we use your personal information in the section, "HOW DO WE PROCESS YOUR INFORMATION?" **Will your information be shared with anyone else?** We may disclose your personal information with our service providers pursuant to a written contract between us and each service provider. Learn more about how we disclose personal information to in the section, "WHEN AND WITH WHOM DO WE SHARE YOUR PERSONAL INFORMATION?" We may use your personal information for our own business purposes, such as for undertaking internal research for technological development and demonstration. This is not considered to be "selling" of your personal information. We have not disclosed, sold, or shared any personal information to third parties for a business or commercial purpose in the preceding twelve (12) months. We will not sell or share personal information in the future belonging to website visitors, users, and other consumers. ### Your Rights You have rights under certain US state data protection laws. However, these rights are not absolute, and in certain cases, we may decline your request as permitted by law. These rights include: - Right to know whether or not we are processing your personal data - Right to access your personal data - Right to correct inaccuracies in your personal data - Right to request the deletion of your personal data - Right to obtain a copy of the personal data you previously shared with us - Right to non-discrimination for exercising your rights - Right to opt out of the processing of your personal data if it is used for targeted advertising, the sale of personal data, or profiling in furtherance of decisions that produce legal or similarly significant effects ("profiling") Depending upon the state where you live, you may also have the following rights: - Right to obtain a list of the categories of third parties to which we have disclosed personal data (as permitted by applicable law, including Delaware's privacy law) ## 10\. Do We Make Updates to This Notice? _In Short: Yes, we will update this notice as necessary to stay compliant with relevant laws._ We may update this privacy notice from time to time. The updated version will be indicated by an updated "Revised" date at the top of this privacy notice. If we make material changes to this privacy notice, we may notify you either by prominently posting a notice of such changes or by directly sending you a notification. We encourage you to review this privacy notice frequently to be informed of how we are protecting your information. ## 11\. How Can You Contact Us About This Notice? If you have questions or comments about this notice, you may contact us by post at: Changebot, LLC 131 Continental Dr Suite 305 Newark, DE 19713 United States ## 12\. How Can You Review, Update, or Delete the Data We Collect from You? Based on the applicable laws of your country or state of residence in the US, you may have the right to request access to the personal information we collect from you, details about how we have processed it, correct inaccuracies, or delete your personal information. You may also have the right to withdraw your consent to our processing of your personal information. These rights may be limited in some circumstances by applicable law. # Product - Agent-First Changelog Publishing URL: https://www.changebot.ai/product/ Description: Changebot lets teams publish product updates from MCP/API workflows for free, then add paid codebase integrations when they want Changebot to write updates, answer product-change questions, and automate recaps. # Understand, Write, and Publish What Changed Start with a free hosted changelog, widget, custom domain, and MCP/API publishing. Use your own AI-written update for free, then add the Changebot Agent when you want automated release notes and source-aware answers from what shipped. In short Changebot is an agent-first changelog platform for product and marketing teams. It publishes updates to a hosted page, embeddable widget, custom domain, Slack, and feeds for free, and its paid agent reads connected GitHub or Bitbucket repositories to draft customer-facing release notes that a human reviews before publishing. [Get Started for Free](https://app.changebot.ai/signup) ## How It Works 1 ### Publish for Free Turn any draft from an agent, chat window, or release note into a hosted changelog post and embeddable widget. 2 ### Bring Your Agent Use MCP to publish from Claude Code, ChatGPT, Slack, Codex-style tools, or your own agent without copy-pasting into a CMS. 3 ### Make It Yours Add your logo, remove Changebot branding, customize the widget, and put the changelog on your own domain. 4 ### Automate From Code Connect GitHub or Bitbucket so Changebot can analyze what shipped, identify customer value, answer product-change questions, and draft recurring updates. ## Core Capabilities ### Changebot Agent A paid conversational workflow for understanding product changes, writing updates, and automating recaps from your source systems. ### MCP Publishing Plug Changebot into Claude Code, ChatGPT, Slack, Codex-style workflows, or your own agents so drafts can become published updates for free. ### Hosted Changelog Every team gets a durable URL for product updates. Keep customers, prospects, and AI systems pointed at a live record of what changed. ### Embeddable Widget Put the same changelog inside your product, docs, or marketing site so customers see what is new without hunting for it. ### White-Label Publishing Add your own domain, remove Changebot branding, customize categories, and make the changelog feel like part of your product. ### Codebase-Aware Recaps Connect repos so Changebot can read commits, PRs, and deployments, then draft release notes for last week, last month, or a specific launch. ### Product Change Briefings Give support, sales, and leadership Claude Code-level context without setting them up in a dev environment. Ask what changed by feature, date range, or customer impact. ### Slack and Internal Updates Send concise internal versions to support, sales, leadership, or customer Slack rooms while the canonical update lives in your changelog. ### Multi-Audience Versions Ask for customer, support, sales, or leadership versions from the same source update instead of rewriting release notes five times. ### API for Everything Else Build dashboards, custom review flows, internal agents, and publishing automations on top of the same structured update history. ## Why Changebot? ### Agent-Native Use the workflow your team already lives in instead of logging into another editor. ### Free to Publish Hosted pages, widgets, custom domains, Slack, MCP, and APIs are free. ### Human Review Built In Draft with the agent, but approve what customers see before it goes live. ### Code Context When Ready Upgrade to $99/repo/mo when teams need codebase-aware release notes and answers. ## Ready to Publish Your First Update? Get started for free with a hosted changelog, or choose the workflow that fits your team. [Get Started for Free](https://app.changebot.ai/signup) [Choose Your Path](/start) # Changebot Agent - Write Updates With Product Context URL: https://www.changebot.ai/product/agent/ Description: Use the Changebot Agent to understand what changed, brief support and sales, write customer-ready updates, and publish when the answer should become a changelog post. Changebot Agent # Write Updates With Claude Code-Level Context Ask what changed, why it matters, who might notice, and what to tell customers. Changebot writes customer-ready updates from source context, and gives non-technical teams product-level answers before anything needs to be published. In short The Changebot Agent reads your connected GitHub or Bitbucket repository, groups related commits and pull requests, and drafts customer-ready updates in your own categories and voice. It also answers questions about what changed for support and sales. Every draft waits for human review, and the agent costs $99 per repository per month. [Get Started for Free](https://app.changebot.ai/signup) [Use MCP](/product/mcp) Changebot Agent Ask → Draft → Review → Publish You Write a customer update for everything we shipped last month. Changebot I found 6 customer-facing changes. Drafting a changelog post with a short support version. You Make it less technical and add a launch headline. Changebot Done. Review the post, then publish it to your hosted changelog and widget. Ready to publish **June product update** Hosted changelog + widget + Slack ## Ask Like This Monthly recap "Write a customer-facing update for everything we shipped last month." Support brief "Give support a brief on what changed in billing this week." Feature history "What changed in exports over the past month, and who might notice?" Feature discovery "What cool new features should we share with our customers?" Audience rewrite "Rewrite this for support so they know what to tell customers." Publish command "Looks good. Publish this to our changelog and send the internal version to Slack." ## The Agent Loop 1 ### Ask Tell Changebot what you need: a launch note, support brief, feature history, fix summary, or internal recap. 2 ### Understand Changebot reads source material and explains the work at a feature, benefit, customer-impact, and update-worthy level. 3 ### Answer Draft the update, ask for audience variants, or give support, sales, product, and leadership an answer they can use without engineering archaeology. 4 ### Publish When the answer should become an update, push it to your hosted changelog, widget, Slack channel, custom domain, or downstream workflow. ## Built for Product Communication ### Drafts from intent Start with a sentence, a rough launch note, a support question, or a date range. Changebot turns the ask into a structured update or answer. ### Product-change briefings Ask what changed in a feature, what customers might notice, or whether a recent release could explain a support ticket. ### Edits in conversation Ask for a shorter version, a calmer tone, or a support-ready summary without copying the answer into another tool. ### Human approval The agent helps you write and route updates, but publishing stays reviewable so customer-facing communication never goes out by accident. ### Changelog publishing Every approved update can land on a hosted changelog, an embeddable widget, Slack, Webflow, or your own workflow through the API. ## Write Better Updates With Product Context Get started for free. Add the agent when you want Changebot to draft updates and give support, sales, and product source-aware answers without a developer sitting beside them. [Get Started for Free](https://app.changebot.ai/signup) [Choose Your Path](/start) # Integrations - MCP, GitHub, Bitbucket, Slack & More URL: https://www.changebot.ai/product/integrations/ Description: Changebot plugs into MCP/API publishing workflows for free, then connects to codebase tools for paid Changebot-written updates, source-aware answers, and automation. Integrations # Plug Into the Tools That Know What Changed Start from an agent prompt, a Linear release note, a Slack conversation, or your actual code changes. Changebot is the publishing layer that turns that context into a live changelog. In short Changebot connects to GitHub, Bitbucket, Jira, and Linear for source context, and publishes to Slack, Webflow, embeddable widgets, RSS and Atom feeds, webhooks, and its JSON API. MCP and API publishing are free; the source integrations that let the agent write updates are part of the $99 per repository plan. [Get Started for Free](https://app.changebot.ai/signup) ## Where Changebot Works Use MCP and APIs for free publishing, then connect source tools when you want the paid Changebot Agent to draft updates automatically and answer product-change questions from the same context. ### MCP Publish from Claude Code, ChatGPT, Slack, Codex-style tools, or your own agents without leaving the conversation. - Draft and review in chat - Inline review URLs - Publish to hosted changelog - Works with agent marketplaces ### GitHub Let Changebot read commits, pull requests, and releases across your repos when you want codebase-aware updates. - Reads commit messages - Pulls from PR descriptions - Grabs release notes - Rolls up across repos ### Bitbucket Connect your Bitbucket workspace so Changebot can monitor work and draft updates from what actually shipped. - Workspace connection - Automatic commit pickup - Multi-repo support - OAuth authorization ### Jira Use Jira context to connect tickets, sprints, and releases to customer-ready changelog updates. - Tracks issue status - Follows sprint progress - Maps to release versions - Custom field support ### Linear Workflow Ready Bring Linear-generated release notes or issue context into Changebot, then publish them to a hosted changelog instead of leaving them inside Linear. - Tracks completed issues - Rolls up cycles and projects - Filter by label - Per-team views ### More Coming Soon We're always adding new integrations. GitLab, Shortcut, Notion, and more are on the roadmap. - GitLab - Shortcut - Notion - PRDs & Documentation ## Developer Workflow Use your terminal and automation stack to decide what gets drafted, reviewed, and published. ### MCP Commands Ask Changebot to write last week's update, revise it for customers, and return a review URL without leaving your agent surface. ### Branch Selection Choose which branch drives automated updates. Point Changebot at production so drafts reflect what customers can actually use. ### Deployment Notifications Drop Changebot into your CI pipeline so release notes can follow what deployed to each environment. ## How It Works 1 ### Pick a Surface Start with MCP, the API, or direct publishing from a generated release note. 2 ### Add Context Connect GitHub, Bitbucket, Jira, or Linear context when you want deeper automation. 3 ### Set Review Rules Decide what needs approval, where review links go, and which channels can receive published updates. 4 ### Publish the Changelog Approved updates land on your hosted page, widget, Slack channel, API, or custom domain. ## Ready to Plug In? Get started for free with MCP/API publishing, then add $99/repo agent automation when Changebot needs to write from source context. [Get Started for Free](https://app.changebot.ai/signup) [Choose Your Path](/start) # Changebot MCP - Publish Changelogs From Claude Code and AI Chat URL: https://www.changebot.ai/product/mcp/ Description: Use Changebot through MCP-compatible AI tools to write, review, and publish changelog updates without leaving your workflow. Changebot MCP # Your AI Workflow Can Publish Now Linear can draft a release note. Claude can summarize a diff. Changebot is the MCP-powered publishing layer that turns those drafts into a hosted changelog, widget, Slack update, or custom-domain release page. In short Changebot MCP is a Model Context Protocol interface that lets Claude Code, ChatGPT, Slack, and other MCP-compatible agents write and publish changelog updates directly. The agent sends the draft; Changebot handles review, hosting, and distribution to your changelog page, widget, Slack, and feeds. MCP publishing is free. [Get Started for Free](https://app.changebot.ai/signup) [Choose Your Path](/start) changebot-mcp agent workflow $ ask changebot "write last month's customer update" Changebot Drafted 6 customer-facing updates from recent work. Changebot Review: https://app.changebot.ai/review/monthly-update $ make it shorter and publish to the changelog Changebot Published to your hosted changelog and queued Slack. ## Watch the Agent Close the Loop Agent directly to changelog agent session $ write an update for last month Changebot Grouped 7 customer-facing updates. Changebot Generated customer and support versions. $ make it punchier and publish done Published. Widget refreshed. Slack queued. → Review URL Ready ### May shipped features Billing exports, faster onboarding checks, reporting filters, and better admin controls are now live. 7 updates · 3 versions · published Changelog Widget Slack Agent directly to changelog agent session $ what cool new features should we share with our customers? Changebot Found 4 candidates. Reporting filters look strongest. Changebot Drafted a launch note and widget copy. $ send it to review done Review URL ready. Widget draft saved. → Review URL Ready ### Smarter reporting filters Customers can narrow release history by team, feature area, and audience without digging through old notes. 4 candidates · 1 recommended launch · review ready Review URL Widget Draft Support Note ## Works Where Agents Work ### Claude Code Ask for last week's release note, get a draft and review link inline, then publish without leaving the terminal. ### ChatGPT and Claude Use the chat interface your team already trusts, then send the approved update to Changebot for publishing. ### Slack Draft internal release notes, route customer-ready versions, and keep teams informed from the channels they already use. ### Custom agents Plug changelog publishing into the agents and automations you already run through MCP-compatible tools. ## The MCP Flow Ask Write a changelog update for the billing improvements we shipped last week. Review Changebot returns the draft, source context, and a review URL in the same workflow. Edit Ask for a customer version, a support version, or a shorter Slack summary. Publish Approve the update and push it to your hosted changelog, widget, Slack, or API. ### Not another copy-paste step Drafts generated in Linear, Claude, ChatGPT, or a terminal can become published updates without a manual CMS handoff. ### Not raw Jira text Changebot adds product-aware translation, audience variants, and publishing destinations on top of raw source material. ### Not automatic blast mode Review links and approval gates keep customer-facing updates under human control before they go live. ## Ready to Publish From Your AI Tools? Get started for free, then publish changelog updates from Claude Code, ChatGPT, Slack, or any MCP-compatible workflow. [Get Started for Free](https://app.changebot.ai/signup) [Choose Your Path](/start) # Problems We Solve - Changebot URL: https://www.changebot.ai/product/problems-we-solve/ Description: Your team ships constantly but customers have no idea. Changebot closes the gap with an agent-first changelog workflow. # The Gap Between Shipping and Communicating Your team already has AI tools that can summarize, draft, and chat. The missing piece is a workflow that turns that context into reviewed, published updates customers can actually find. In short Changebot closes the gap between shipping and telling customers. Engineering work lands, nobody writes the update, and sales, support, and customers never hear about it. Changebot drafts updates from what shipped, routes them through review, and publishes them where customers, teammates, and AI assistants can find them. [Get Started for Free](https://app.changebot.ai/signup) 01 ## The Awareness Problem ### If your team doesn't know something shipped, they can't talk about it. Support gets asked about features they've never heard of. Sales pitches capabilities that launched months ago as "coming soon." Leadership asks what shipped last quarter and nobody has a complete answer. With dozens of repos, multiple teams, and hundreds of commits per week, there's no human who can maintain visibility into everything that shipped. Updates get produced but never consumed. > "I'm the one answering support tickets, and half the time I forget what we shipped last week. Customers ask about features I built but never announced."— Technical founder, seed-stage startup #### How Changebot Fixes This Changebot gives teams a standing place to ask what changed, review the answer, and publish the result. Add repo integrations when you want the agent to monitor what shipped. - Agent prompts for weekly, monthly, or launch-specific updates - Hosted changelog and widget for every approved update - GitHub and Bitbucket context for automated recaps 02 ## The Translation Problem ### Technical work doesn't translate itself into customer language. Even when you know what shipped, turning "Refactored auth service to use JWT tokens" into "Login is now faster and more secure" takes real effort. Multiply that across release notes, blog posts, in-app announcements, and internal updates—it's hours of work that nobody has time for. Marketing rewrites PM drafts. PMs chase engineers for context. The same update gets written three different ways for three different audiences. And half of what shipped never gets written up at all. > "I don't need to know what database tables were added. I need to know how the experience is changing for our customers."— Founder handling marketing at a 30-person team #### How Changebot Fixes This Changebot is built for the context change: customer update, support note, leadership summary, or Slack version from the same underlying work. - Conversational edits before publishing - Audience-specific versions from one draft - Product-aware translation instead of raw ticket summaries 03 ## The Distribution Problem ### If customers never see it, was it really shipped? Code ships. Maybe it gets a Slack message to the team. Maybe it makes the monthly recap if someone remembers. But customers? They find out about new features by accident—or they don't find out at all. Launches are ephemeral. Big announcements happen, then the content disappears. There's no steady drumbeat, no persistent place for customers to discover what's new. The tree falls in the forest and nobody hears it. > "Customers say 'I had no idea this thing exists' even after our launches. There's no running changelog destination for them to find."— Engineering lead at a 40-person SaaS company #### How Changebot Fixes This Changebot makes publishing the default outcome. Drafts can come from an agent, Linear, code changes, or Slack, then land on a durable changelog URL. - Free hosted pages with RSS and Atom feeds - Embeddable widgets for your product and docs - Custom domains, white-labeling, MCP, and API publishing on the free plan - Slack publishing to public and private channels ## Why Now? ### AI Development Increased Output AI coding tools made shipping faster. Customer communication is still manual. Small teams are experiencing big-team release communication problems. ### AI Discovers You First When prospects ask ChatGPT for recommendations, what will it find about your product? Detailed changelogs help AI tools discover and recommend your features. ### Communicate Without New Headcount Most teams will not add a writer for every release. Changebot lets the agent do the repetitive drafting while humans keep approval. ## The Result ### Less Release Note Busywork Teams spend less time chasing engineers, rewriting the same update, and copying drafts between tools. ### Nothing Falls Through Every customer-impacting change gets surfaced. No more "I didn't know that shipped" moments from support or sales. ### Customers Stay Informed A steady drumbeat of updates keeps customers engaged. Show prospects your shipping velocity as a competitive advantage. ## Ready to Close the Gap? Get started for free with a hosted changelog, then add the agent, MCP, and codebase context your workflow needs. [Get Started for Free](https://app.changebot.ai/signup) [Choose Your Path](/start) # Changelog Publishing - Hosted Pages, Widgets, MCP, Slack URL: https://www.changebot.ai/product/publishing/ Description: Publish product updates to a hosted changelog, embeddable widget, Slack, custom domain, MCP, or API for free. Changelog Publishing # A Real Destination For Every Update The agent can write the draft. Changebot gives it somewhere durable to go: a hosted changelog, an embeddable widget, Slack, API, or your own domain. In short Changebot publishes one update to every destination at once: a hosted changelog page on your own domain, an embeddable widget with 15+ themes, Slack, RSS and Atom feeds, webhooks, and the API. Publishing is free, including the custom domain and white-labeling that other changelog tools charge for. [Get Started for Free](https://app.changebot.ai/signup) ## Where Updates Go ### Slack Drop updates right into Slack channels. Your team sees what shipped without leaving where they already work. - Public and private channels - Route to any channel - Rich formatted messages - One-click publish ### MCP and Agents Publish from Claude Code, ChatGPT, Slack, Codex-style tools, or your own agent. The agent writes; Changebot stores and distributes. - Review URLs in chat - Human approval before publish - Hosted changelog destination - Works with agent workflows ### Embeddable Widgets Put a changelog right inside your product or docs. 15+ themes, live preview tool, and full CSS customization. - 15+ built-in themes - Live widget preview - React, Vue, or plain HTML - Full CSS customization ### Hosted Changelog Pages Beautiful changelog pages with multiple templates, dark mode, and optional custom domain support. RSS and Atom feeds included. - 3 templates (Headwind, Kitty, GreatHub) - Custom domains with SSL - Dark mode built in - RSS & Atom feeds ### Webflow Publish updates directly to your Webflow CMS collections. Keep your marketing site in sync without copy-pasting. - CMS collection publishing - Draft and live modes - Automatic formatting - One-click publish ### API Build whatever you want on top of your structured product update history. - RESTful API - Webhook support - Full update history - Custom filtering ### AI Agent Feeds Give support bots and internal agents accurate, up-to-date info about what shipped via the same changelog data. - Structured data output - Real-time sync - Better bot answers - Fewer hallucinations ## Tailor the Message ### Customers Show customers what's new and why it matters to them. Benefits, not commit hashes. ### Sales Keep your sales team armed with what just shipped. No more pitching "coming soon" for stuff that launched last month. ### Support Give support the context to answer "is this fixed yet?" without hunting through Jira. ### Leadership Quick summaries for the people who need the big picture without the implementation details. ## Ready to Publish? Get started for free with a hosted changelog, widget, custom domain, Slack, MCP/API publishing, and every destination your update needs. [Get Started for Free](https://app.changebot.ai/signup) [Choose Your Path](/start) # Security - Practical Controls for Agent Workflows URL: https://www.changebot.ai/product/security/ Description: Changebot is built with security in mind. Read-only access, scoped permissions, encryption, audit logging, and human review for customer-facing updates. Security # Security Controls Without the Ceremony We are keeping the security work: read-only access, scoped permissions, encryption, audit logs, and review gates. Our posture is based on the controls we operate, not just a badge. In short Changebot reads source repositories read-only, with scoped permissions, encryption in transit and at rest, audit logging, and a human review gate before any customer-facing update publishes. Changebot supports security vendor reviews on every plan, including the free one, and SAML/OIDC single sign-on is coming. [Get Started for Free](https://app.changebot.ai/signup) ## Security Posture Controls ### Security Work Continues We keep operating with practical controls: least-privilege access, encryption, audit trails, access review, and human approval before publishing. Google ### Google Sign-In Teams sign in with Google to create a workspace. No separate password to manage, and only basic profile information is requested. SSO ### SAML / OIDC SSO Coming Soon SAML 2.0 and OIDC so your team logs in through Okta, Azure AD, or another identity provider. This is not on the free plan today. ## Minimal Permissions We only ask for read access to what we need. We never write to your repos. ### Read-Only Access We never write to your repos. We read commits, PRs, and issues—that's it. ### Scoped Permissions Only the repositories you explicitly authorize. No organization-wide access required. ### Easy Revocation Pull the plug any time through your provider's settings. Takes effect immediately. ### Audit Logging Full audit trail of everything we access. You can see exactly what we read and when. ## Infrastructure Security ### Encrypted at Rest All data encrypted using AES-256 encryption at rest. ### Encrypted in Transit TLS 1.3 for all data in transit. No exceptions. ### Cloud Infrastructure Runs on established cloud infrastructure with availability monitoring and operational safeguards. ### Regular Backups Automated backups with point-in-time recovery. Your data is safe. ### DDoS Protection Edge-level DDoS mitigation keeps things running when others go down. ### Penetration Testing Regular third-party penetration testing and vulnerability assessments. ## Security FAQ What access does Changebot need to my code? Read-only, scoped access to the repositories you explicitly connect. Changebot reads commits, pull requests, and release metadata to draft updates. It never writes to your repositories, and connecting a repository is optional because free publishing requires no code access at all. Can I control what Changebot reads, and revoke access? Yes. Permissions are scoped to the repositories you connect, with branch selection and commit skip patterns to narrow it further, and a full audit trail of what was read and when. Access can be revoked at any time through your provider's settings and takes effect immediately. Can Changebot publish something without a human approving it? Updates enter a draft and review workflow by default, and a person approves before anything reaches customers. Automated recaps are generated on a schedule, but the publish step remains under your control. How is data protected? AES-256 encryption at rest, TLS 1.3 in transit, automated backups with point-in-time recovery, edge-level DDoS mitigation, and regular third-party penetration testing. Teams sign in with Google today, and SAML 2.0 and OIDC SSO are coming. ## Questions About Security? Get started for free and we'll share docs, or email us if you need a security review. [Get Started for Free](https://app.changebot.ai/signup) # Refund Policy URL: https://www.changebot.ai/refund/ Description: Changebot Refund Policy # Refund Policy Refund Policy for Changebot.ai Last Updated: 12.11.24 ## 1\. Introduction At Changebot.ai, we strive to deliver a valuable and reliable service. We understand that circumstances may change, and you may wish to cancel your subscription. This Refund Policy outlines the conditions under which refunds will be issued. ## 2\. Subscription Payments Your Changebot.ai subscription is billed on a recurring basis (e.g., monthly or annually) according to the plan selected. By subscribing, you agree to the recurring billing terms stated at the time of purchase. ## 3\. Refund Eligibility **Used Services:** Once you have generated any AI-driven updates or utilized the platform's AI features during a billing cycle, we consider the associated usage costs incurred. Due to the computational expense of providing those AI-generated updates, no refunds will be issued for the portion of the subscription that covers already-used services. **Unused Services:** If you have not generated any updates or otherwise consumed AI-related platform resources during the current billing cycle, and you decide to cancel your account, you may request a full refund for the unused portion of your subscription. We will happily refund you in such cases, as long as the request is made within the same billing period in which you have not utilized the service. ## 4\. How to Request a Refund To request a refund, please contact our support team at [support@changebot.ai](mailto:support@changebot.ai) with the following details: - Your account email address - The reason for cancellation and refund request - Confirmation that no AI updates or platform usage took place during the billing cycle (if applicable) Our support team will review your request, and if approved, process the refund promptly. ## 5\. Refund Processing Times Once approved, refunds typically take 5–10 business days to appear on your original payment method. Please note that processing times may vary depending on your financial institution. ## 6\. Changes to this Policy We may update this Refund Policy from time to time to reflect changes in our practices or for other operational, legal, or regulatory reasons. When we make changes, we will update the "Last Updated" date at the top of this policy. We encourage you to review this policy periodically to stay informed. ## 7\. Contact Us If you have any questions or concerns about this Refund Policy or would like further clarification on your eligibility for a refund, please contact our support team at [support@changebot.ai](mailto:support@changebot.ai). # Service Description URL: https://www.changebot.ai/service/ Description: Changebot Service Description and Features # Service Description ## Overview Changebot is an agent-first changelog platform for software teams. It helps organizations write, review, and publish clear product updates to hosted changelog pages, widgets, Slack, APIs, and custom-domain destinations. ## Scope of Services Changebot currently provides the following services: - **Changelog Publishing:** Provides hosted changelog pages, embeddable widgets, RSS and Atom feeds, and custom-domain publishing. - **Agent-Assisted Drafting:** Helps users write, edit, review, and approve product updates through agent and chat-based workflows. - **Product-Change Briefings:** Helps support, sales, product, and leadership teams understand the same source context behind generated updates without requiring direct access to developer tooling. - **Context Awareness:** Builds an evolving understanding of the company's product and systems to generate increasingly accurate messaging over time. - **Delivery Integrations:** Supports distribution of updates via Slack, API, hosted pages, widgets, and other configured destinations. ## Features - **Hosted changelog:** Publishes product updates to a durable customer-facing URL - **Agent and MCP workflows:** Supports drafting and publishing from compatible AI and agent surfaces - **Codebase integrations:** Can ingest PRs, commits, and releases from supported repositories when enabled - **Product-change Q&A:** Lets authorized users ask what changed by feature, date range, or customer impact before turning that context into updates - **Slack delivery:** Sends product updates to team channels or individuals - **Manual editing:** Users can review and edit generated updates before publishing - **Activity filtering:** Users can choose which types of activity to include (e.g., code only, docs) - **Audit trail:** Maintains logs of updates sent and who received them ## Limitations - Publishing destinations are available on the free plan; agent-written updates and repo-aware automation may depend on plan, availability, and third-party platform support. - Automated summaries are machine-generated and may require review for accuracy. - Customer-facing updates should be reviewed before publishing. ## Availability Standard availability is 24/7 excluding scheduled maintenance. ## Data Handling - Changebot processes metadata and content from integrated product tools (e.g., commit messages, diffs, PR titles.) - All data is encrypted in transit and at rest. - Changebot does not store source code or sensitive business logic beyond the generated summaries used to write updates. ## Change Management Service descriptions are reviewed quarterly or when a significant change is released. Customers are notified of any major updates via email. # Why Changebot? - Proof of What Shipped URL: https://www.changebot.ai/solutions/product-marketing/ Description: Product and marketing teams use Changebot to turn shipping into customer-visible proof: a hosted changelog, widget, and a record sales, support, and AI systems can use. Why Changebot? # Shipping Should Be Impossible to Miss Product and marketing already know what shipped. Changebot turns that work into customer-visible proof — a hosted changelog, widget, and a record sales, support, and AI systems can actually find. In short Product marketing teams use Changebot to turn shipping into customer-visible proof. Changebot maintains a hosted changelog, in-app widget, and Slack feed drawn from what engineering actually shipped, so launches, sales conversations, and support answers all reference one dated public record instead of a scattered internal list. [Get Started for Free](https://app.changebot.ai/signup) [Choose Your Path](/start) ## Built for Teams Who Have to Show the Work ### Product Product teams need a source of truth for what actually shipped — so sales, support, and customers are not guessing from Slack threads and stale docs. ### Marketing Marketing teams need proof of velocity and language they can use in messaging, not a blank changelog to fill in after the launch is already old news. ### Enterprise GTM As the org grows, the value case is alignment: support, sales, and customers working from the same record. That is the conversation for Agent and Enterprise plans. ## Sound Familiar? ### "We shipped it, but nobody saw it" Great work gets buried because no one has time to write it up. Your customers think nothing is happening while your team is shipping constantly. ### "Marketing is still positioning last quarter" Sales pitches a feature that launched months ago. Support finds out from the customer. The work shipped. The story never made it to the people who need it. ### "The update is stuck in another tool" Linear generated release notes. Claude wrote a clean draft. Slack has the context. But none of that becomes a public URL customers can find. ## How Changebot Helps ### Agent and MCP Workflow Draft in Changebot, Claude Code, ChatGPT, Slack, or another agent workflow, then send the approved update to your changelog. ### Hosted Changelog and Widget Start free with a hosted page and embed the widget anywhere your customers already are. Your updates get a durable home. ### Custom Domain and White Label Upgrade when the changelog should live on your domain, match your brand, and remove Changebot branding. ### Codebase-Aware Automation Connect GitHub or Bitbucket so the agent can identify what shipped and draft weekly or monthly updates automatically. ## Common Use Cases ### Weekly Recaps Ask the agent for what changed this week. Publish the customer version and send the internal version to Slack. ### Feature Launch Announcements Turn one feature into a changelog post, support summary, and customer Slack update from the same approved draft. ### Linear to Published Changelog Take the release note Linear helps generate and give it somewhere public to live without copying it into another changelog CMS. ### In-App Changelog Embed a widget directly in your product with 15+ themes. Customers see what's new without leaving your app. > "I showed someone our changelog during a demo and his jaw hit the floor when he saw we shipped 10 updates in the past 3 weeks. It's now a core part of our messaging." **Alkarim Lalani** CEO, Rollout ## Ready for an Agent-First Changelog? Get started for free with a hosted changelog, or choose the workflow that fits your team. [Get Started for Free](https://app.changebot.ai/signup) [Choose Your Path](/start) # Start - Choose Your Changebot Workflow URL: https://www.changebot.ai/start/ Description: Get started for free with hosted changelog publishing, MCP/API publishing, custom domains, widgets, and Slack. Upgrade only for repo-aware agent automation. Start Here # Choose Your Changelog Workflow Get started for free today. Publish your own update, use MCP or APIs when you want to bring an AI-written draft, and add the paid agent when you want Changebot to write, explain, and automate from your source systems. In short Changebot has three starting points. Publish an update you wrote yourself for free, push a draft from an MCP-compatible AI tool such as Claude Code or ChatGPT for free, or connect a GitHub or Bitbucket repository so the agent writes updates from what shipped for $99 per repository per month. [Get Started for Free](https://app.changebot.ai/signup) [Free ## Publish for free Log in, write your own update, publish it to a hosted changelog, and embed the widget in your product. - Hosted Changebot page - Embeddable widget - Custom domain included Get started for free →](https://app.changebot.ai/signup) [Free ## Use the MCP Write the update in Claude Code, ChatGPT, Slack, or another MCP-compatible surface, then push it to Changebot for free. - Prompt from your AI tool - Review URL inline - Publish through MCP or API See MCP →](/product/mcp) [Free ## Distribute everywhere Send approved updates to the places customers and internal teams already look. - Slack and Webflow - RSS, Atom, API, webhooks - Themes and CSS control See publishing →](/product/publishing) [$99/repo/mo ## Let the agent run Let Changebot monitor GitHub, Bitbucket, Jira, or Linear so it can draft updates, answer what changed, and automate internal and customer communication. - Daily or weekly recaps - Support and sales briefs - Internal and customer automation Connect tools →](/product/integrations) ## Free and MCP Powered [Play](https://youtube.com/watch?v=EDWyZuACVNg) Watch how Changebot publishes your changelog for free from the AI tools you already use, then [get started for free](https://app.changebot.ai/signup). # Terms of Service URL: https://www.changebot.ai/terms/ Description: Changebot Terms of Service and legal agreements # Terms and Conditions Effective Date: July 4th, 2024 ## 1\. Introduction Welcome to Changebot ("Service"), operated by Changebot, LLC ("Company", "we", "us", or "our"). By accessing or using our Service, you agree to be bound by these Terms of Service ("Terms"). If you do not agree to these Terms, you may not access or use the Service. ## 2\. Use of the Service ### 2.1 Eligibility You must be at least 18 years old and capable of forming a binding contract with us to use the Service. By using the Service, you represent and warrant that you meet these eligibility requirements. ### 2.2 Account Registration To access certain features of the Service, you may need to register for an account. You agree to provide accurate, current, and complete information during the registration process and to update such information to keep it accurate, current, and complete. ### 2.3 Account Security You are responsible for safeguarding your password and any activities or actions under your account. You agree to notify us immediately of any unauthorized use of your account. ## 3\. Subscription and Payment ### 3.1 Subscription Plans We offer various subscription plans for the Service. The specifics of each plan, including pricing and features, are available on our website. ### 3.2 Payment Terms By subscribing to a plan, you agree to pay the fees specified at the time of purchase, along with any applicable taxes. Payments are due in advance for the subscription period selected. ### 3.3 Changes to Subscription Plans We may modify the subscription plans and their prices from time to time. Any changes will be effective upon your next renewal date. ## 4\. License and Restrictions ### 4.1 License Grant Subject to these Terms, we grant you a non-exclusive, non-transferable, limited license to access and use the Service for your internal business purposes. ### 4.2 Restrictions You agree not to: - Copy, modify, or create derivative works based on the Service. - Reverse engineer, decompile, or disassemble the Service. - Use the Service to build a competitive product or service. - Use the Service for any unlawful purpose. ## 5\. User Content ### 5.1 User Content You may submit content, including data, text, files, and other materials, to the Service ("User Content"). You retain ownership of your User Content. ### 5.2 License to User Content By submitting User Content to the Service, you grant us a worldwide, non-exclusive, royalty-free license to use, reproduce, modify, and distribute your User Content for the purpose of operating and improving the Service. ## 6\. Privacy Policy Your use of the Service is also governed by our Privacy Policy, which can be found below the Terms of Service. Please review the Privacy Policy to understand our practices regarding your information. ## 7\. Termination We may suspend or terminate your access to the Service at any time, with or without cause, and with or without notice. Upon termination, all licenses and other rights granted to you in these Terms will immediately cease. ## 8\. Disclaimer of Warranties The Service is provided "as is" and "as available" without warranties of any kind, either express or implied, including, but not limited to, implied warranties of merchantability, fitness for a particular purpose, or non-infringement. We do not warrant that the Service will be uninterrupted or error-free. ## 9\. Limitation of Liability In no event will Changebot, LLC, its affiliates, or their licensors, service providers, employees, agents, officers, or directors be liable for any indirect, incidental, special, consequential, or punitive damages, including, but not limited to, loss of profits, data, use, goodwill, or other intangible losses, arising out of or related to your use of or inability to use the Service. ## 10\. Security and Data Protection Changebot is committed to maintaining the confidentiality, integrity, and availability of Customer Data. We implement and maintain industry-standard administrative, technical, and physical safeguards designed to protect Customer Data against unauthorized access, loss, misuse, or alteration. These safeguards include access controls, encryption, audit logging, vulnerability management, secure software development practices, and continuous monitoring. For more information about our security program and practices, please visit our Trust Center. ## 11\. Governing Law These Terms will be governed by and construed in accordance with the laws of the state of Delaware, without regard to its conflict of law principles. ## 12\. Changes to Terms We may update these Terms from time to time. We will notify you of any changes by posting the new Terms on our website. You are advised to review these Terms periodically for any changes. Changes to these Terms are effective when they are posted on this page. # Thank You - Changebot URL: https://www.changebot.ai/thank-you/ Description: You're on the list. We'll be in touch soon. # You're on the list! Thanks for signing up. We'll be in touch soon with updates. **No need to wait, though.** [Get started for free →](https://app.changebot.ai/signup)