Relentless empathy (AKA genuinely addressing your technical audience’s needs)
The questions your content has to answer to be human and valuable
You know when you’re in a conversation with someone and it’s clear the person is talking to make a point or respond to you vs understand you? Not the best experience.
That’s bad technical content marketing, in a nutshell. And it’s the product of writers and brands either A) writing content for the sake of itself or B) writing content that assumes to know the plight of the reader (without ever asking the reader about their pain points).
This kind of approach will strangle your audience relationships before they really even mature, especially when you’re wading into technically complex subject matter for skeptical, expert readers.
The issue with most technical content
Content that’s written with a product push in mind from the jump is often assumptive in two main ways:
You’re assuming your audience’s problem is 1D and you can pinpoint it.
You’re assuming the solution to that problem is, without a doubt, whatever you’re selling them or building.
In reality, we (and our products) aren’t the holy grail solution to much at all (unless you’re secretly out there developing the next cancer cure). Our users and readers are in a constant battle with multi-faceted pain points, and, no matter how shiny, our product is at best a tool to help them piece together their ultimate fix, not the solution itself.
To write effective technical content, you need to take that to heart. It’s kind of painful depending on how close to your product you are but instills a sense of humility that makes your content human.
By doing so, you can begin to see the other skills, tools, and mindsets readers need to leverage your tool as part of their winning strategy. And then you need to write product-agnostic content that supports all those pieces together.
Technical content and the practice of relentless empathy
Ann Handley, the author of Everybody Writes, talks about this reader-first prioritization as having “relentless empathy for the audience.” Handley and her book talk more broadly to the whole of content marketing and writing, but this mindset is particularly useful for those of us acting as proxy technical experts and channels for our community.
Here’s how I think about relentless empathy within the context of technical content marketing:
Relentless empathy means reverse-engineering the skills, mindsets, pain points, communication channels, and ecosystems that your readers had to experience before ever needing your product. It means writing human first, instead of product- or algorithm-first.
To execute on this empathy both genuinely and strategically, you need to *consider five things about your technical audience for every piece of content you generate*:
Why they need this content
When they need this content
What kind of content they need
Who that content should come from
Where the content should reach them
Let’s take a closer look at what I mean by each of those considerations.
1. Why does your technical audience need content?
This is the first question, and more important, question to answer. And if you can’t come up with a genuine reason that someone needs a particular content idea, it’s a bad idea.
“Because we want them to know about our product” isn’t a good enough answer. You need to drill down on the pain point that your audience is trying to solve when they’re reaching out into the world.
Generally, people look for technical content for one of two reasons:
They’re experiencing a pain point (aka they’re troubleshooting something or have an acute problem they’re looking to fix).
They’re experiencing an expansion point (aka they’re curious about learning something new and expanding their skills).
Distinguishing between these two flavors of pain points can make a world of difference in motivating your readers.
2. When does your developer audience need content?
After we’ve checked that our idea is one that our audience actually needs when we can move on to the timing of it all.
Just like your product has its own customer journey, your content has a reader journey. You need to support each stage of the reader journey with the right kind and timing of content to make your message resonate with your reader.
I’ve found the easiest way to break down the timing of your content is to map the demands of the reader to each stage of buyer awareness:
Unaware: Reader demands “get my attention” with expansion content that talks about big ideas and inspiration.
Problem aware: Reader demands “help me understand what to think about” and asks for content that begins to frame the problem-solution your product sits within. Open their eyes to the issue.
Solution aware: Reader demands “Help me think through options” and wants you to act as counsel to support them in how to make a decision about their problem.
Product aware: Reader demands “Help me understand why your product specifically” and asks for product-centric content to address their immediate needs.
I generally focus more on expansion content in the unaware stage since I like to build a reader relationship that’s optimistic at first to inspire them to dig deeper vs drive them with fear. You can start to speak more acutely to a pain point as you move down the funnel.
3. What kind of technical content does your audience need?
Not all content types are created equal. Don’t hit your audience with a tutorial when they need top-of-mind inspiration, and don’t send them to thought leadership when they need a how-to.
Generally speaking, I break down content types into three buckets and then drill down the exact format based on persona preference:
Audio content (i.e. podcast or webinar)
Written content (i.e. blog post or ebook)
Visual content (i.e. webinar or infographic)
This accounts for folks’ different learning styles, while also giving your content legs on different distribution channels. Especially when it comes to either A) core messaging of your brand or B) highly technical instruction, this multi-format approach gives people different ways to learn the same information based on what they need and respond to best.
Keep in mind that not every kind of content should be repurposed into all three content types. Highly technical product walkthroughs and document-adjacent coding tutorials would make pretty terrible podcast content. High-level philosophical thought leadership generally makes bad webinar content for the opposite reason, and folks just end up leaving the show running and treating it like a podcast anyways.
4. Who does that developer content need to come from?
It hurts writers not to have bylines, I know. But you need to accept that your voice and your name often aren’t the best source of credibility for your audience.
For each article, depending on the kind of insights being shared, you need to attach the name of someone the community will respect for that subject matter. If you’re writing about deep engineering concepts, find someone from your developer team (or your technical founder) to sponsor the piece and publish it under their name. If you’re writing to your ops persona about your product functionality, have someone who sits between engineering and business write the article. The byline is one of the earliest opportunities for your reader to relate to the piece.
The same thing goes for the distribution of content. If you’ve ever been on the internet, you know it’s a ruthless place, especially the communities where developers, engineers, and analysts hang out. More often than not, posting from branded accounts will get you told off, and posting from accounts without much history or community standing will result in the same. Either spend the time to spin up a company account with a history of community service through content, or find a couple of folks in your company to evangelize for your content directly.
Better yet—as I’ll expand on in future articles—partner with a few influencers and thought leaders in the community to write and distribute your product-agnostic content whenever possible.
5. Where should content reach your technical audience?
Different classes of technical audiences enjoy and resonate with different mediums better than others. If you know that your scrappy indie startup developer audience is super active on Reddit and Discord, write and create content for those channels that’s easily shareable. If you know your enterprise audience of IT experts responds better to industry publications and newsletters, write to that. If your decisions makers don’t have time to sit down and read, create podcast and video content that they can passively listen to.
This brings up a point that I’ll hammer on a lot in future newsletters, but you can’t do technical content well unless you have a crystal clear idea of the personas you’re writing for (this goes beyond just saying “we want to write for developers). You need to be able to pinpoint their tool stack, their favorite communities, and their individual challenges in order to get the kind of content they need right.
Well, that’s all for this week folks. 👋 I hope you enjoyed the walkthrough of how I dial in on empathy for technical audiences. I’d love to hear about your approach, if you use a similar framework, or if there’s a whole other system you’ve tested out that works well for your strategy. Drop me a line over on Twitter at @alliewritestech.