My good friend Bryan Ross has extended upon this article on his Chief Therapy Officer blog

Blogs.

I appreciate that you’re reading one right now, but the word still seems quaint, old-fashioned. It’s all so very turn-of-the-century, so very web 2.0.

I’m going to describe some of the reasons why, even in 2024, you might want to have a blog for your platform. Or, if you already have a blog, some hints and tips for making the most of it, and maybe some encouragement to use it more.

Blogs excel at providing detailed context

When you release a new feature, or make a change, your platform may have a banner, with a call to action. You might also post a message to Teams or Slack, with a summary of the change.

You’re also almost certainly sending out e-mails with a bit more context, maybe even to the right people. But we all know that long e-mails don’t get read, so we need to keep them short.

So where do people go when they need more information?

For those users who want to know why something is happening, blogs provide an excellent way of contextualising that information. Adding a link to your banner, notification, or e-mail means that people who want, can choose to get that context, and you’re not overwhelming those people who don’t need or want that material.

The blog post can provide all sorts of extra information. If it’s a new feature, why was it implemented? How do your customers go about using it? Is there a mechanism for providing feedback? If it’s a change to the way the platform works, then why was it implemented? What does the customer need to do? Are further changes planned?

A blog also gives your existing, and new customers an opportunity to view a record of the improvements which have been made to the platform. Remember, Static platforms are dead platforms. You should always be releasing new features, and updates. At the very least you should be applying patches, security fixes and making changes to conform to changing corporate guidance and legislation. If customers can’t see a history of changes, updates and improvements, it may cause them to worry that the platform is not well maintained, and unresponsive to user needs.

Blogs can be updated

As soon as you hit the send button on an e-mail, that information is now out there. Even if you e-mail a follow-up, the original e-mail could be referenced without context, or forwarded-on. I’m sure you have been sent e-mails which were quickly followed-up by clarifications (one of my favourites involves a follow-up which had to explain to otherwise intelligent people that “12:00 means afternoon, not midnight!”). How many times have you sent something out, only to quickly get back a few replies all asking the same thing (or pointing out the same error!). If it’s not happened yet, it’s likely only a matter of time!

But … if your e-mail contains only the essential information, and includes a link to your platform blog, you can update the blog as many times as you like. Further context can be added, links to documentation can be updated … dates can (ahem) be changed. Anyone following the link from an e-mail with a subject line starting Fwd: Fwd: Fwd: will get still the most up-to-date details.

If you get questions (via e-mail, Slack, or comments on the post itself) you can add clarifying information directly to the post.

Blogs encourage your engineers to think of customers

If you ask your platform engineers to write a blog post prior to the release of a new feature, they are forced to put themselves into the customer’s position.

I typically like to start all new product blog posts with the format:-

  • What is happening?
  • Who is affected?
  • Why is it happening?
  • When is it happening?
  • What does the customer need to do?

If you structure your writing like that, and encourage your engineers to do the same, you’ll find that you very much need to see things from the point-of-view of the consumer.

Without taking this kind of approach, you can easily end up with engineers providing a laundry list of new features, backend-technologies, protocols, and version numbers which often means nothing to your customers.

Instead focus on the improvements. For example, it’s unlikely anyone will be interested in a new obscure security feature, but maybe it’s an audit requirement (and customers are always interested in passing audits, especially when compliance requires no work on their side).

A blog personalises your platform

Until the day that we’re all replaced by AI, the majority of us are still human. And humans naturally prefer interact with other humans.

A blog gives you the opportunity to personalise your platform, to give you and your team more character.

You can have a bit more of a voice on a blog than you can have via e-mail and documentation. You can be a bit more open about challenges you’ve faced. You can acknowledge that things are late, or imperfect (for now), in a way that you can’t really do in documentation.

You can even add photos, pictures and memes to show that you and your team are not an amorphous blob of corporate capability, but a small group of people, people who probably look-like, talk-like and act-like your customers.

Humanising your platform builds loyalty. People are more likely to forgive small issues if they’ve interacted with the people running the platform.

A blog also provides a direct avenue for interaction. A small number of people may comment, but - if they do - there are probably other people relieved that they did, and keen to see the answer in a public forum. Always try to reply to comments, and try to keep the responses positive; you’re not just replying to the person who left the comment, but all of the other people reading it too. The people who do comment are likely to tbe the ones who care the most about your platform, and - if brough onboard - will likely be able to advocate for you to other customers.