5 Reasons Product Updates Don’t Belong on Your Blog

Summary

1. Your blog audience is different than your product audience
2. Your blog subscribers are also different than your product audience
3. Not every product update warrants a full blog post
4. Blogging platforms were never built for product updates
5. Unpredictable release schedules disrupt organized content calendars

{{resources-component-1}}

Background

Within the software industry, publishing product updates on your company blog has been a common practice for decades.

Whenever a big release lands or a new version ships, a blog post is always one of the first and most important launch tactics. And, from a practical standpoint, this trend isn’t surprising. Every company has a blog, the blog usually garners quite a bit of traffic, and users subscribe to it. Whenever something changes, product marketers can easily draft a post about what’s changed, add in a few screenshots and gifs, hit publish, and it’s a win for everyone.

Or is it?

In this post I’m going to make the case that, while blogging about product updates is certainly one approach to communicating and promoting what’s changing (or has changed) in your product, it’s far from the most efficient, effective, or strategic approach. Should a blog post be one channel you leverage during your most significant product launches? Absolutely. But realistically, tier 1 launches of this size and importance only come around once or twice a year. The product changes that land on the other 363 days of the year need their own home.

Below, I’ll explain why your blog should not be that home, and what you should do instead.

A topic on which I speak from personal experience

Before I dive in, I’ll note that this is a topic that I’m not only particularly passionate about, but also one that I’ve wrestled with firsthand for over 10 years while working on a number of different product and product marketing teams. At Atlassian, where I led the product marketing team for Jira, dialing in the perfect channels for communicating product changes was something we vastly improved upon, but never got just right. And it was largely this frustration of needing to find a better way that led me to joining LaunchNotes.

But before I get side-tracked talking about that, let’s dig in! 

Here are five reasons product updates don’t belong on your blog:

These days organic content plays a very important role in the growth strategy of most SaaS companies. If your goal is to build SEO authority in particular areas or on specific topics then publishing rich, well-structured, SEO-optimized thought leadership content on said topics is the best way to do it.

Great thought leadership content is key to building a big, relevant social media following and blog subscriber list, as well as leveraging both of these things to rank for the specific terms you need. Don’t believe this is a winning strategy? Reach out to me directly and I’ll make you a believer in no time :)

Here are a few companies that have, and continue, to implement this strategy with incredible effectiveness:

• Atlassian: teams, team culture, and workplace productivity
• HubSpot: stellar content marketing and SEO strategies
• Shopify: building and maintaining the best online businesses
• Intercom: more conversational sales, marketing, and support
• Profitwell: the clear thought leader on SaaS subscription growth
• Sentry: expert application monitoring for developers
• Effx: the the future of microservices, site reliability, and engineering
• Gremlin: chaos engineering and 'breaking things on purpose'
  

Given the above, the first and most obvious reason why blogs aren’t a great venue for communicating product change is that they fly directly in the face of this strategy.

An example

Let’s say your blog is being filled with a steady stream of content around the topic of effective remote teamwork. You’re beginning to see organic entrances to some key terms that you’ve been writing about on the topic, your backlinks are starting to increase, and your blog subscriber count is increasing. People are passionate about this topic and hungry for more original content on it.
‍

‍
Then one day a group of your regular readers head to your blog and find that the top two articles are about a new UI you’ve recently rolled out and some improvements you’ve made to your API. Huh? At a minimum this news will probably be viewed as irrelevant and annoying. To others, especially those who have subscribed to your blog, it may even feel like a bait and switch tactic. 

If you’re building authority and thought leadership in effective remote teamwork, and readers associate you and your blog with great content on that topic, beginning to mix in product update posts sends the impression that you’re either switching tactics for what kind of content they should be expecting on the blog, or that you’re trying to subtly push product on them. Are either of these things the end of the world? No. But it’s a subpar and jarring user experience that can easily be avoided. It’s also a guaranteed way to increase bounces from your blog and unsubscribes from your blog subscriber rolls (more on this below).

The bottom line: if your blog is the tip of the spear of your content strategy and organic traffic goals, product updates are out-of-place and don’t fit into the user journey of your blog’s readers/visitors/subscribers.

Addressing the organic readership objection

One response I’ve heard to the above criticism is that blogs are actually a good venue to showcase product updates because, over time, they will reach far more eyeballs due to the organic traffic they receive. While this is a valid point, and a post may "get more eyeballs" on a blog, my response is simple: how many people enter your blog organically with the purpose of diving into product update posts?

Now let's examine this question from the perspective of a first-time visitor to your blog, and their reader’s (/buyer’s) journey. Given that you have precious little time to engage this potential new evaluator and get them to take a call-to-action (presumably to subscribe), do you really believe them spending their first 30 seconds in a post on your new UI refresh is the best way to do this?

I don’t think so. This isn't the kind of content that peaked their interest about your blog in the first place, and it’s not what’s going to keep them engaged and hungry for more.

One of the most attractive reasons for using a blog post to communicate product change information is that most blogs have a built-in audience. Once your blog post is finished, it can be loaded into an email and sent to the entire subscriber list.

Anyone writing blog content faces a dilemma: content creation is only half the battle. Once written, it has to be distributed. Distribution is easy with a well maintained blog because a subscriber list means instant eyeballs, and a lot of them.

However, the devil is in the details, and there are two reasons why you shouldn't broadcast product change communications to this list of subscribers:

A large percentage of blog subscribers aren’t users

If your blog is attracting a wide variety of subscribers and/or one of its key purposes is to build SEO and domain authority, there’s a good chance that, by design, many of those subscribers are not users of the product, and therefore have no interest in product updates. In my experience this number can be as high as 50%.

What’s the fastest way to drive up unsubscribe rates among this 50% of prospective new users you’re carefully nurturing? Fill their inbox with product updates that are irrelevant to them.

A segmentation step adds complexity and isn't foolproof

The best way to avoid falling into the above trap is to implement some sort of segmentation system so that non-users are filtered and excluded from product update emails from your blog. However, this filtering step introduces another layer of complexity, as the necessary segmentation must be completed at either the blog or email level.

While some blogs do allow you to only subscribe to certain sections or categories, this isn’t very common. As I will discuss below, it’s also a blunt instrument in and of itself. Meanwhile, introducing a filtering step within your email client not only requires that the proper tracking instrumentation be in place and accurate across your app, but usually requires the involvement of another stakeholder (often an (analyst) as well. 

In my experience, no matter how meticulous you are about cross-referencing your blog subscribers with your user base prior to sending emails, at the end of the day you will almost always end up hitting a larger audience than you intend, thus driving up unsubscribe rates. 

Finally, it’s worth noting that this entire segmentation process can quickly slide into grey areas in terms of GDPR compliance.

Yet another challenge that arises when using your blog to communicate product change is that most updates or changes don’t warrant a full blog post. 

If you’re rolling out a huge update (i.e. a tier 1 release in the priority matrix), then a blog post should absolutely be one component of your complete launch strategy. It’s a significant milestone for your business and product, and likely a marketing moment that you want captured with a long-form piece of content.

But realistically, tier 1 releases come around once or twice a year at most. Which then leaves you with the dilemma: where and how do you communicate tier 2 and 3 releases? Especially when they’re coming out on a weekly or bi-weekly cadence?

Comms about your tier 2 and 3 updates can (and should) be punchier and more concise. In my experience the perfect length is somewhere between a blog post, which demands longer-form content and a more thought leadership focus, and your release notes, which are usually as short as bullet points and optimized for skimming. This happy medium is usually a few paragraphs of text with screenshots and gifs, leaving you in a weird lurch of deciding where these kinds of comms should live. Too long to be a release note, but too short for a blog.

An example

Let’s assume you’re rolling out a few noteworthy enhancements to a popular feature in your app. These improvements aren’t groundbreaking from a competitive or industry standpoint, but they’ve been highly anticipated by your current users and warrant far more than a mention in your release notes. Not to mention you want to include a few screenshots to highlight what’s changed and how slick what you’re shipping is. 

Based on our priority matrix, these enhancements would fall squarely into the P3 category. Now you’re left in the gray area discussed above. And in my experience, the vast majority of product changes and updates actually fall squarely into this category.

At this point, you have three options:

1. Publish a very short blog post that doesn’t look or feel like anything else on your blog and that appears to have been published with only a third of the intended content
2. Don’t communicate about the enhancements beyond a mention in the release notes
3. Don’t communicate the release and instead save if for inclusion in some sort of monthly or quarterly “wrap-up” post
   

None of these options are great. 

If we’ve already established that a blog isn’t the most efficient or effective platform for communicating product changes, option #1 only further compounds this fact, as you’ll end up with long-form thought leadership content intermixed with P3 product update “half-blogs.”

Option #2 (only communicating via the release notes) creates the largest missed opportunity of all. Release notes are rarely read by anyone but your power users, who know where they are and actively look for them.

And #3 (deferring the communication to later) requires you to hold the valuable communication that you’ve shipped for weeks or even months simply because you’re waiting for enough content to fill a blog post. This not only flies in the face of everything your team is working towards day in and day out, but it’s a huge missed opportunity to please and excite your users about the value they have in front of them today. 

Addressing the “monthly round-ups work well for us” objection

I share concerns with a monthly or quarterly round-up blog knowing that this practice has become commonplace with many product marketing teams. And there’s definitely value in rounding everything up and presenting it in a single place on a regular cadence. With that in mind, I challenge teams using this strategy to flip the practice around and examine it from their customer’s perspective.

Putting aside the logistical hurdles of ensuring your product update blogs are properly categorized and reaching the correct audience whenever they’re published, take a big step back and ask yourself: where is the place your customers want or expect to be looking for and consuming product update information? Is your company blog the ideal destination for this, or was it just the most convenient spot when you started?

‍
If you’re a business that serves midmarket and enterprise customers, and they need details on what you’ve shipped to do internal enablement for their own teams, is the best and most effective user experience to tell them to wait for a monthly or quarterly wrap-up blog post and then point them to your company blog for consumption? What if they need access to this information before your wrap-up post is published? What if the blog post doesn’t include the level of detail they require? What if you aren’t able to get one of these blogs published on time?

While there’s no doubt that there’s value in a monthly or quarterly round-up communication to customers, the question remains: is the best channel for consumption the company blog? Is that where your customers would expect to find that information?

I would posit it’s not. Up until this point the blog has just been the most convenient channel for these communications. But this doesn’t make it the right one.

We already touched on the lack of blog segmentation a bit above, but it’s worth exploring even further in its own section as well. Why? Because not only do blogs have very basic segmentation capabilities that aren’t designed for communicating specific product changes, but these segmentation capabilities immediately fall apart as companies scale.

The organization of most blogs is based on some sort of basic tagging system that allows you to filter blog posts by content area. A typical list of tags usually looks something like this:

• Thought leadership topic #1
• Thought leadership topic #2
• Thought leadership topic #3
• Company news and announcements
• Product updates
  

While this structure may work with a single product and a dev team that is largely only working on one area of the app at a time, it falls apart as companies grow. As teams scale, their ability to build and release new code steadily increases. This increase in the rate of change means more teams and work streams shipping more product updates of all shapes and sizes. 

The question becomes: how do you set up your blog categorization system to effectively map to such a world?

Creating new blog tags or categories for different tiers of updates

Introducing specific tags for different tiers of updates seems overkill (and not what your blog is intended for), but throwing everything into the ‘product updates’ tag means each and every update is likely reaching your entire user base, regardless of its relevance to an intended audience.

‍

A very common example is separating updates for admins vs end users. Do each of these deserve a separate blog tag? What about core features vs third-party integrations? How do you handle features being rolled out in alpha and beta? In my experience these questions begin piling up very quickly as a company scales, and every time one of these questions pops up it serves as a reminder that blogs simply aren’t designed for communicating product updates effectively, especially at scale.

Creating new blog tags or categories across multiple products

While #1 is a headache, it’s also worth considering how this complexity further compounds if and when your company has more than one product. Then you not only have to think about how to handle the issue of tagging for one product, but multiple products. I won’t belabor the point, but you can see how the simplistic tagging systems on blogs fall apart as companies scale.

While neither of the above points may apply to you today, it’s always smart to lay the foundation for things that will scale along with you as your company grows. And as you can see from the above, blogs simply aren’t a scalable solution for communicating product change.

Speaking of scale, this final point is yet another reason to carefully consider how your product change communication strategy will scale as your company grows.

If you’re a smaller company and only have one marketer and/or one or two people writing content on your blog, you probably haven’t experienced this problem yet. However, larger and more mature marketing organizations need some sort of content calendar. As more blog items  are planned and written by more people, there needs to be a method to the madness so that not all of your content is landing on the same day or week. Creating a content calendar is the wise thing to do as a company scales, and it’s very common practice.

However, if you’re the owner of the product change communication, having a pre-set calendar that you have to fit into/work around is not only a hassle, but impedes your ability to effectively do your job. Anyone who has worked in software for more than a month knows that release dates are an ever-moving target. The idea that you’ll confidently know weeks in advance when something will land is a pipe dream, which makes it a constant game of tetris with whomever is managing your blog’s content calendar.

This tetris not only becomes a regular headache, but also leads to the obvious question of who gets priority if an important piece of content and a significant release end up landing on the same day. I know from experience that if a major piece of content (and usually an associated email send) is pushed back to make room for a product release that is then cancelled or postponed at the very last minute, everyone gets frustrated. And make no mistake that this will happen, and more often than you may be imagining!

In short, trying to fit release comms onto a blog content calendar is like trying to force a square peg into a round hole. While your content and SEO strategy isn’t time-bound and can be planned months in advance, the nature of software is that release dates are forever shifting. Any company serious about scaling efficiency needs to ensure both can happen in parallel: a steady stream of rich, SEO-driven content as well as timely, segmented product change comms that keep users informed, happy, and active.

The LaunchNotes solution

LaunchNotes solves each of the above five issues. Here’s how:

A single, dedicated channel for product announcements and change communications

By design, LaunchNotes lives perfectly alongside your company blog, giving you the best of both worlds: a company blog for thought leadership and SEO, and a dedicated LaunchNotes page for announcing new features, product improvements, bug fixes, and more. 

LaunchNotes is a launch blog, a changelog, and a release notes stream in one. We’ve even built in SEO controls so if you want your tier 1 releases to exist in both places, your LaunchNotes blog can be easily “no-indexed” from Google.

The confidence of only reaching your users—the right users—with relevant updates

Users can easily subscribe to receive LaunchNotes updates on only the categories they care about - eliminating the debate around who should receive which updates from your blog and how to segment those updates among subscribers. Relatedly, you’ll never need to bug another analyst for help pulling, filtering, or scrubbing an email list.

With two separate subscriber channels you can be confident that the right information gets to the right people. Those interested in your thought leadership will continue to receive it while those needing to know what’s changing when in your app will never miss a beat.

Built-in launch workflows for easily creating announcements of any tier

LaunchNotes enables you to quickly and easily make product announcements of any kind. LaunchNotes announcements can be set up and published in a matter of minutes, and no post is too short or too small.

Regardless of how many customers you have, or what size they are, your LaunchNotes page is the single source of truth for every product change and the one place where every user can dive into exactly what changed, when, and why. And if you want to continue publishing monthly or quarterly round-up posts there, we’ve even made it easy to do that too.

A robust segmentation platform that’s built for granular category creation

The entire LaunchNotes platform is built on a powerful categorization system. You can create and customize categories to map to your team structure, your product workstreams, the types of updates you’ll be making… whatever suits you and your business. 

And because your LaunchNotes page is designed for product updates and announcements, users will expect a more granular approach to your segmentation. Moreover, they’ll be delighted by the ability to subscribe to any of these categories, and only the ones they care about.

The freedom to publish product announcements and change communications as often as you need to

With a dedicated and direct LaunchNotes channel at your disposal, you’ll never have to worry about aligning (or misaligning) with your team’s content calendar or blog schedule. Both channels can be maximized to grow your business and engage your users, with zero friction or back and forth between teams.

As an added benefit, having these two channels working in parallel eliminates any back and forth between you and your content team, saving everyone time and headache. Yet again, the best of both worlds!

Closing thoughts

If you've made it this far, you firstly deserve a thank you! This is quite a dense topic and I went deep on it. As I mentioned in the opening paragraph, it's a topic I'm particularly passionate about. But my opinion and experience is my own. I'd love to hear from you!

Do you agree with the case I've laid out above? What are the holes in it? If you're a PMM, do the experiences I've had line up with your own? If you've successfully incorporated product updates into your blog, how have you done it?

Reach me directly any time with your own thoughts: jake [at] launchnotes.io.