Your latest event recap post has 12 views. And if you look closely, most of those views are from your colleagues. There’s an event next month, too, and an associated recap sits on the content calendar. You have the sinking feeling that eyeballs on that one will be just as few.
It’s not just event recaps. A lot of technical content suffers from low views and unengaged readers. The underlying issue is that much of this content doesn’t attract new technical audiences. Instead, it speaks to those who already know your product well. This post looks at how these mistakes happen, how to better reach developers who don’t know you yet, and even how to fix navel-gazing content like the dreaded event recap.
The Danger of Navel-Gazing Content
Many marketing teams set publication volume goals. It’s with good reason — consistent publishing helps fuel other marketing efforts. It also sends positive signals to readers and search engines alike, but not every blog post sends as strong a signal.
To meet volume goals, teams can often include less valuable posts in the mix. Posts that neither attract anyone new nor engage those who already know about you. These metric-padding posts are easy to spot:
- Recap of an event the company attended
- Product changes and updates
- Interviews with a community or team member
These posts aren’t all bad; sometimes, they’re written for good reason. And each can be framed to be more successful. But most are navel-gazing disasters simply because they focus inward on your company rather than outward on developer needs — this limits their ability to attract new eyes and ears.
The event recap is a prime example of navel-gazing content. Often posted with a headline like [Company] Attends [Conference], it offers little else in the body of the article: perhaps a list of colleagues who attended, a bit about someone from your company who gave a talk, or a giveaway at your company’s booth. In other words, it’s a lot of your company. It’s so cookie-cutter that most of the text could have been written before the event. And each post is like the last.
Product changelogs suffer from a similar lack of point of view when they’re actually prime opportunities to attract new developers. They usually go out with templated headlines: [Product] Updates: [Month] [Year]. Product managers, marketers, and developer advocates all pat themselves on the back for sharing what’s new. But they’ve missed something more important: showing why it matters.
A changelog page in documentation gets a pass for being bullet points. Not so much when it’s published as a blog post. This kind of content can attract new developers, but you have to frame it with a story of how developers can use these changes. Heck, even your existing audience cares why a product update matters. Tell them, first in the headline, then in each article section.
Even developer experience darling Twilio has made this mistake. The company invests in a regular changelog video to share updates with its community. The blog post companion is a simple categorized list. Its headline hints at the “Content Template Builder” subject, but not why it matters. In the middle of the runtime section are some details about why it’s useful, if you make it that far. The video’s title is slightly better, suggesting it provides “Better RCS and WhatsApp messages.” Ultimately, neither the video nor the blog post will likely attract anyone unfamiliar with Twilio.
You could argue events and changelogs aim at goals other than reaching a new audience. But what about community interviews? As with the other types, the writers of a community interview are well-meaning, but they often conjure an old Bette Midler quote:
“But enough about me, let’s talk about you… What do you think of me?”
Often told in Q&A format, these interviews suggest their focus even with their formatting. The company’s questions are delivered in bold, followed by the community answers in plain text. And many of the questions ask about the developer’s experience with — you guessed it — the company’s product.
Like all the navel-gazing content in this section, you can reframe the community interview to work better. It can engage the current audience and expand to attract those who haven’t heard of your company.
But it’s admittedly more work to think about what potential readers care about and frame your event recap, changelog, or interview around those things. Indeed, you might be better off spending that effort on other types of content.
Focus on Developer Problems Instead of Your Developer Product
When you work at a company with a technical product, it’s nearly impossible to see the world as developers do. You’re very aware of your product’s features, benefits, and maybe even quirks. That knowledge clouds your judgment about how developers see you.
Where you see your product as the obvious solution, developers are still figuring out the problem. The same issues that cause navel-gazing content can inflict similar pain across your content. Get into the head of your developer audience, and you can start to understand their problems.
Developers aren’t looking for your marketing. Their time is precious, often split between coding, meetings, and keeping up with tech trends. When they visit your site or read your content, they’re making a trade: their attention for something useful. If you only offer company news and product hype, that’s a bad deal for them.
What makes the trade worth it? When it comes to content, developers want to:
- Learn new skills they can apply right away
- Solve specific problems blocking their work
- Gain insights that help them make better tech decisions
- Find trustworthy sources that understand their world
Notice how none of these value points start with your product. They all focus on the developer’s goals and challenges. The most successful technical content addresses these needs first, then gently connects to your solution only when relevant.
Technical readers can easily spot promotional content. Yes, you need to promote your product, but do it in a way that builds trust. When your content starts with your product before establishing why it matters to their problem, you’ve already lost their trust.
To create content that developers want, start with their problems, not your product. Follow this problem-first framework:
- Begin with the developer’s context
- Explore the technical challenge
- Demonstrate solutions without pushing your product
You can make natural connections to your product’s unique approach only after you’ve shown you understand where they’re coming from.
For example, Algolia reached thousands of developers by tapping into the problem behind its product. The company’s search product supports autocomplete functionality, but instead of pushing the feature, we recommended a different approach — describing what it would take for developers to build it themselves.
By explaining the architecture developers need to build their own autocomplete, Algolia earned a mention of their product that already implements the feature. This approach struck the right balance between education and promotion.
The rule of thumb is simple: the more educational value you provide, the more product mentions you’ve earned.
For introductory or problem-definition content, you might not mention your product at all. For solution-focused content, wait until you’ve thoroughly explained the challenge before introducing your product as one pathway forward.
The beauty of problem-first content is that it serves multiple audiences simultaneously. New visitors discover you through their search for solutions, not your brand name. And they’re naturally more qualified leads because they’re already wrestling with problems your product solves. Meanwhile, existing users want to see how you think about the problem space. A problem-first blog post reinforces their decision to use your product and may reveal new ways to apply it.
This approach can transform your entire content strategy, including those necessary-but-often-overlooked pieces like event recaps and product updates. In fact, with the right framing, you can even reimagine these traditional content types to focus on developer problems first.
How to Maximize Events and Product Releases to Attract Developers
You don’t need to delete those content calendar slots for events and changelogs. Instead, you can transform them into more meaningful content to attract developers. They won’t always fit the problem-first framework, but you can use similar ideas to tap into the developer mindset. Then, reframe the post to balance serving existing users and attracting those who have yet to discover your product.
Remember, seeing the developer perspective from within your company can be challenging. One way to force this shift is to put on your journalist hat. You can make this literal, if you want, and keep a fedora tagged with the classic “press” card above the brim. But really, all you have to do is ask yourself these questions:
- Why does this matter to someone not already using your product?
- How does someone currently solve the problems this addresses?
- What is the story or trend within this potential piece of content?
Developers and journalists alike are good at uncovering ulterior marketing motives. When you proactively ask yourself these questions, one or more of them will point you toward better serving your technical audience.
Your work on that event recap post, for example, starts before the event is over. You and others on your team can attend sessions and look out for trends. Even if you’re tied to booth duty, you can survey everyone who meanders past your part of the expo hall. Your recap is not just a regurgitation of the event, but a journalistic examination of the state of your industry.
You can even put in some legwork in advance. Ambassador scheduled interviews with API experts before a conference and used them to turn in an insightful article with none of the downsides of a typical event recap.
The boring bulleted list of a changelog is also no match for your journalist’s eye. Even if your update is the most requested feature by current users, you can identify why someone new would consider it important. Often, the answer is a downside to how the problem is currently solved. In a product update that may have multiple changes, elevate the strongest story to the headline. Even better, find a throughline within the updates, much like the trends in the event recap.
Try one of these template headlines for your next changelog post:
- Build [Common Use Case] Without [Downside]
- The End of [Technical Limitation] in [Developer Task]
- Prevent [Costly Mistake/Downside] Without Sacrificing [Benefit]
- [Developer Task] Without the [Pain Point]
These help you see the story behind your changelog. When you use them, beware of hyperbole and glossy solutions. When in doubt, tone down the overpromises, but even that beats the generic “Changelog for Version 3.14.”
As for those community and team interviews, you can probably guess the recommended approach. Treat that content type like a journalist. Find the story and explain it. You may not need the Q&A format; instead, you can tell the story you discover from the answers. Use subheadings to call out the individual’s point of view. Then, take the best of what they have to say and put it in block quotes.
Even if you keep the Q&A format, you’ll find your questions improve when you foreground the audience, not your product: less “what do you think of me?” and more “why does this matter to you?”
Stop Writing for Yourself, Start Writing for Developers
There’s always room for content that speaks to your existing audience and reminds them about the work you’re doing for them.
But your marketing should focus on reaching those not yet familiar with your product or community. You need to understand their problems and mindset, so you can attract them in the first place. The good news is that these same things should appeal to your existing audience. They’ll confirm their decision to use your product and participate in your community.
Take some practical steps to bring this approach into your content:
- Attend your next event with a journalist mindset
- Use the problem-first framework on a changelog post
- Find a new angle on an old Q&A post and republish it
- Build the dev mindset into your content strategy
Compare the results of these approaches to your old way. Whether you choose pageviews, reading time, or signups as a metric, you’ll see better results.
That event recap post with 12 views? It’s in the past.
Need a partner to help you reach more developers and build trust in your solution? EveryDeveloper brings an outside perspective to help you implement the problem-first framework.