In our industry, we launch products constantly. When we're in the daily soup of running our business, we lose sight of the fact that 99% of our target developers don't give one iota of a damn about our launch. We think, "We worked on this amazing thing and everyone is going to love it!" But we all tend to forget that 99% of our customers are going through their own daily grind and haven't really thought about us our our product.

So, how do you break through?

I have always lived by a singular guiding principle in both my personal and professional lives:

Help First.

The Help First ethos centers our activities in a service-oriented mindset. Help First managers work to better the careers of their people first and foremost, rather than their own careers or even the bottom line of the company. Help First community members put the health and well-being of the community over their own petty concerns.

The best way to break through the noise and drive awareness among developers is to help them learn something new.

In Developer Relations, the Help First ethos will manifest itself daily. Every day, you will be presented with choices about content, events, community engagement, and more. Adopting the Help First ethos means putting your customers and community first.

Blog posts that don't help

Let's say you have a new Amazing Feature you'd like to announce. It's a feature your engineering team has spent 8 weeks working on, and you believe customers will benefit tremendously if they begin to use it. As part of your launch plan, you write a glorious blog post titled "Announcing Our Amazing Feature: do more with less!" with an outline that looks something like this:

1. An introduction to our feature
2. Thing 1 you can do with this feature
3. Thing 2 you can do with this feature
4. Thing 3 you can do with this feature
5. How to download and get started with the feature

Surely, there's nothing particularly wrong about this blog post outline! Many a launch blog post has been written with almost exactly this format. Indeed, if you have a minor release or something that really is only of interest to your existing customers, then this kind of launch blog post is entirely sufficient.

But this blog post doesn't necessarily help you attract new developers to your product or service. Sure, if they find your product and if they start using your feature, they'll benefit. But the post hasn't really taught them anything new or educated them. As a result, unless your install base is already massive, it's not a post that will trend on any social media or news site, and it's not a post that will break through.

A Help First blog post

In contrast, consider using your blog post as an opportunity to teach your customers something new. Use your in-house engineering expertise and deep knowledge about your problem space to help them become better developers.

First, let's discuss the blog post title. A good blog post title solves three problems simultaneously:

1. Your blog post title must clearly target the type of developer who will care about your product
2. Your blog post title needs to be optimized for SEO, and specifically the types of questions your target developer is searching for at their greatest time of need
3. Your blog post title should promise to teach developers something new

Let's try the following title:

Title: How we made X 1000 times faster, and why that matters

Second, let's talk about the outline. I like to start with a really brief introduction of what we are announcing above the fold. There's no need to bury the lede. But we quickly pivot to providing context about the announcement and why it matters to the industry. If your product or feature is truly solving a developer pain point, this context will be something most developers will be able to relate to. After setting context, teach developers about the history of solutions for the pain point you're describing. This enables you to establish how you differ from both legacy and competitive solutions. Then talk about your solution and why it's unique.

So, our outline would look something like this:

1. (Really brief intro of your feature above the fold...really, really brief!)
2. A brief history of X. How did X come about? What tradeoffs and decisions were made over time that resulted in X?
3. Some of the solutions people have tried for X. (hint: this is a great place to differentiate yourself from your competitors!)
4. What the ideal solution for X looks like. (hint: a great place for you to lay out your roadmap without laying out your roadmap)
5. Introducing Our Amazing Feature
6. How we built Amazing Feature (establish your engineering credibility and if this is sufficiently impressive information, consider breaking it out into a second follow-on blog post!)
7. How to download and get started with Our Amazing Feature

Some examples of Help First blog posts

Here are some really great examples of Help First blog posts that break through the noise. All of these posts teach developers something new, and as a result, all of these posts ended up trending in first place on Hacker News:

• From Timescale: How we made DISTINCT queries up to 8000x faster on PostgreSQL
• From Neon: Why does Neon use Paxos instead of Raft, and what’s the difference?

Closing thoughts

Writing better launch blog posts is key to breaking through the noise and reaching new developers. By framing launches within the context of teaching developers something new and helping them become better at their jobs, you'll have earned enough of their attention that there's a greater likelihood that they'll give your product a shot.