{"id":19455,"date":"2019-02-13T17:53:53","date_gmt":"2019-02-13T17:53:53","guid":{"rendered":"https:\/\/www.intercom.com\/blog\/?p=19455"},"modified":"2024-07-25T11:36:43","modified_gmt":"2024-07-25T10:36:43","slug":"the-secret-to-scaling-product-announcements","status":"publish","type":"post","link":"https:\/\/www.intercom.com\/blog\/the-secret-to-scaling-product-announcements\/","title":{"rendered":"The secret to scaling product announcements: a changelog"},"content":{"rendered":"

One of the biggest challenges with marketing a SaaS product is figuring out a way to announce the continuous stream of updates and feature releases while maintaining a sense of sanity.<\/p>\n

To stay on top of it, you need to figure out two things:<\/p>\n

    \n
  1. A framework for scoping announcements based on the relative value of the feature or update.<\/li>\n
  2. Tactics that can scale with the cadence you ship at.<\/li>\n<\/ol>\n

    We recently shared our evolving approach to scoping announcements<\/a>, so I want to focus more on the second point. Specifically, the tactics for small releases that are valuable, but don\u2019t necessarily justify a big announcement or significant resources. For these small announcements, there are two common strategies for keeping up with the volume \u2013 you can group similar features<\/a> together into a single announcement, or ruthlessly prioritize<\/a> and simply not announce the least impactful updates.<\/p>\n

    It\u2019s not a groundbreaking idea, but grouping similar features into a \u2018wrap-up\u2019 announcement<\/a> is a really useful tactic. First, it maximizes the touchpoints you have with customers by essentially creating a condensed list of all relevant updates.<\/p>\n

    Collectively, these updates make a single touchpoint more valuable to your customer and it’s more likely that they will engage. And by consolidating touchpoints, you\u2019re less prone to over messaging. This wrap-up announcement can take many forms, from an email to a blog post, or even a webinar \u2013 whatever makes sense based on your resources and channels.<\/p>\n

    “The primary goal of a changelog is to increase feature awareness and adoption”<\/p><\/blockquote>\n

    Ruthlessly prioritizing<\/a> and forfeiting announcement opportunities can be difficult, especially when those choices are driven by a lack of time and resources. Not only are you faced with choices that will impact the business\u2019 bottom-line, but you need to defend your rationale even if it relies on limited evidence and many assumptions.<\/p>\n

    This is the reality of the job for a product marketer, so it\u2019s on you to make the most with what you have. That\u2019s why it\u2019s critical to develop a scalable, bare bones announcement plan<\/a> that you can explain the strategy behind. It\u2019s your safety net for covering everything that\u2019s worthy of an announcement without digging yourself into an insurmountable hole of work. For us, this is a changelog announcement.<\/p>\n

    Start with a changelog<\/h2>\n

    Nearly every one of our product announcements at Intercom will include a post to our product changes page<\/a>, also known as our changelog. It\u2019s a curated feed of relevant updates and changes that\u2019s meant to raise customer awareness around what\u2019s new<\/a> in the product. It differs from release notes, in that it\u2019s not just a bulleted list of technical changes, and it differs from help docs<\/a>\u00a0because its primary purpose is not to improve product proficiency. The primary goal of the changelog is to increase feature awareness and adoption and that\u2019s why it’s owned by the product marketing team at Intercom. Even with this focus, a changelog can take different forms, both in structure and content, to meet the needs of your customers and your business.<\/p>\n

    Curating a changelog<\/h2>\n

    Although it\u2019s not difficult to create changelog posts<\/a>, not all product changes warrant one. In general, it should be limited to the updates that are valuable to most of your customers. At Intercom, we tend to avoid posts about bug fixes, speed improvements and small updates that users don’t see value in. But it\u2019s not always that straightforward. We have many spirited debates about whether certain changes deserve a post. And that can be a good thing. It\u2019s the tough calls that help your team gain a shared understanding of what matters to customers and how to prioritize product announcements<\/a>.<\/p>\n

    “Changelog posts should be reserved for the updates your customers care most about”<\/p><\/blockquote>\n

    So how often should you post to your changelog? You want to announce relevant updates, but avoid overwhelming your users. You also want to avoid large gaps between posts. If there\u2019s a year-long gap in your posts, it can give the impression that your product isn\u2019t progressing. All this is to say that there\u2019s no hard-and-fast rules here.<\/p>\n

    In the past year, we had 92 posts to our changelog. We\u2019ve had up to 17 posts in a single day, and on the other end, a few weeks without a new post (it can get quiet over the holidays). Whatever your strategy is, just keep your updates relevant, somewhat consistent, and always considerate of your customers’ time, otherwise they\u2019ll tune out.<\/p>\n

    How to create a useful changelog post<\/h2>\n

    Your posts should always be clear, concise and benefit-oriented. Like any announcement, you need to distill the value in a way that resonates with customers. Be sure to include the following:<\/p>\n