“... In order for the beautiful technology ... to achieve its intended vision, a bridge has to be built from the authors of the technology to the rest of the market. That bridge is the sales and marketing teams.” —Tomaz Tunguz
Developers have a reputation for being hard to sell to, but that’s because most marketers don’t understand developers, their tools, their processes or their problems. A marketer who doesn’t deeply understand the customer will fail every time.
If you ...
have a technical product to sell
sell that product to technical people
are not technical yourself
... then you simply have a steeper learning curve. Marketers who sell a CRM to salespeople have a learning curve too, it’s just not nearly as intimidating.
It’s easy for most people to understand what a salesperson does and how a better CRM might help them in the their work. It’s not easy for most non-technical people to understand how servers work or how developers collaborate or why monitoring tools are so important, therefore it’s hard to understand how to sell them products or services.
We will never make the case that subject matter expertise isn’t important, but we will make the case that a non-technical content team can run a wildly successful content marketing program for a technical product.
The core tenant: diversity is important. Of the technical companies we work with, all pursue multiple content lanes. This means that they don’t rely on any single type of content for acquisition.
This is extremely important to internalize. The more stakeholders involved in the adoption of your product, the more lanes you’ll need. If you market only to developers, it’ll be hard to get leadership’s buy-in. If you market only to executives, you won’t be able to convince the operators to adopt your product.
For most technical companies, we recommend three content lanes:
Technical content for technical people to build credibility
Business case content for managers and executives to talk dollars and cents
Use-case content for both audiences to build organic traffic
Lane #1: Technical Content for Technical People
Assuming your product’s end user is technical, you must appeal to these readers on their own turf. This means writing about topics that interest them in a way that intrigues them. This is true of all content but is harder to get right when the audience is technical.
There are two golden rules that govern technical writing:
Let your own engineers write. These are the people who understand the subject matter best, therefore they are in the best position to communicate with like-minded people who could become customers.
Share understanding, not just knowledge (and definitely not “content”). It’s easy to spot a fake. Developer content that looks, reads and smells like “content marketing” will almost always fall flat. It’s easy to tell when a good idea has been watered down by content gimmicks like keyword stuffing and click-bait titles.
If your developers don’t want to write, welcome to perhaps the single biggest challenge in content marketing.
There’s nothing unique about this—the sales team at a CRM company probably isn’t interested in writing for the company blog either. A company’s subject matter experts almost never have the time or interest in writing. In our experience, this is often because content teams make it far too difficult for them (plenty of developers and other subject matter experts maintain personal blogs that get far more traffic than their own company blogs).
Easy approval process, not many approvals necessary
Few or no non-engineering approvals required
Implicit or explicit fast [service-level objective] on approvals
Approval/editing process mainly makes posts more compelling to engineers
Direct, high-level (co-founder, C-level, or VP-level) support for keeping blog process lightweight
Dan Luu
It’s easy to imagine the opposite of this: a developer writes an interesting rough draft, which then gets over-optimized for SEO, “derisked” by legal and covered by a full-page call-to-action.
If you ask engineers to write, then suck all authenticity from their work, it will never resonate with the target reader. More importantly, it robs them of their technical credibility. Engineers are more likely to contribute if you make it easy for them to showcase their knowledge, ideas and opinions.
To see this in action, check out Auth0’s eight-part Real-World Angular Series. This is something that could only be created by a developer. The author explains how to setup a cloud-hosted MongoDB database and even builds a simple app to demonstrate it. This is not something your average content marketing team could do.
Here’s another example: Refresh Tokens: When to Use Them and How They Interact with JWTs. This is highly relevant to Auth0’s product, an SSO tool, and to the developers that may be tasked with setting it up. Pay attention to the visuals and the code snippets—clearly, this piece is written by a developer for other developers.
You get the point: content marketers can’t fake technical content. They can, however, bring their writing expertise to bear to help shape narrative, structure an argument, or take a half-baked article to the finish line.
You might consider giving your engineers their own space to publish. You might even consider incentivizing them to write. As a last resort, you could even have someone ghostwrite for them. Subject matter expertise can’t be faked, so do whatever it takes to get the operators publishing.
Lane #2: Business Case Content for Managers and Executives
If you sell a technical product, you need to attract technical end-users. But you will also need to make a strong business case for your product. This typically means convincing someone in leadership—COO/CTO/CRO, etc.—that your product either improves productivity or saves money.
A handful of companies have done this by creating products so good that developers can’t help but use them. Atlassian famously grew Jira with nothing more than a free trial. It’s an inspiring story and one to aspire to, but Atlassian is an outlier. Plenty of great products have never been successfully commercialized because the company was unable to reach its target market and convince them to try their software.
Business case content uses dollars and cents to explain to leadership why your product should be adopted. It’s good to talk about your product’s best features and explain how the software integrates into your existing stack, but there’s no need to cite code snippets. Good business case content is designed specifically for the reader who holds the purse strings.
Here’s a perfect example from Auth0: Recent M&A Deals that Imploded Over Cybersecurity. This is Auth0’s value proposition to the C-suite. You need a technical person to write about to how integrate a two-factor authentication, but you don’t to explain how lax security can costs a company lots of money. When a dev team says, “We need a better SSO solution,” and the CTO says, “Let’s not be the next [insert privacy crisis],” new products get adopted.
Here are a few others from Auth0 that strike the same tone:
Because Auth0 is a security tool, there’s bit of fear injected into each of these posts. That makes sense in this case—security is all about limiting risk. If your technical product increases productivity, for example, focus on that instead.
Here are a few other components of business case content:
Case Studies—How are your customers currently succeeding with your product? For the COOs and CTOs reading, social proof makes it easier to justify the purchase.
Segment has dozens of customer stories, showcasing actual results from well-known companies, such as this story from Digital Ocean.
Whitepapers/Ebooks/Reports—Content that gives concrete data points helps executives strengthen their case when making buying decisions.
Retool, a product that helps developers build internal tools more easily, recently published their State of Internal Tools in 2020 report. This helps executives, and developers, understand the space and provides the evidence they need when making decisions.
Thought Leadership—What personal insights can you share as a technology leader? How does you company see your space developing over the next few years? What practices do you want your industry to move away from, or push towards? What has your personal journey been like?
If you can position your company as the vanguard of your field, you'll naturally draw in your audience.
Lane #3: Use-Case Content for Developers and Executives Alike
If you're ramping up technical content production, use-cases allow you to assemble a library of ideas that resonate with your audience and build organic traffic over time. Use-cases can range from the technical to the non-technical depending on the use-case, persona, and industry you're targeting.
Zapier is the content leader of this type of content, primarily because the product has so many use cases:
Segment is using the same strategy but for a more technical audience with their Recipes. Each recipe shows how to perform a common task using Segment, and the specific integrations you’ll need. For instance, Flatten Nested JSON Objects with Segment and Mammoth demonstrates how you can use the Mammoth JSON parser to make data analysis easier with Segment. A developer searching “flatten JSONs” will come across this article and (a) be introduced to Segment, and (b) find an actual solution to their problem.
For more technical products, it might be less about use-cases for personas, and more use-cases by tooling or industry. How can Python programmers use your product, or what is a B2B use-case for your product?
Build a Bridge From Technology to Market
Intercom has built its entire content strategy by turning its own subject matter experts in sales, product, support and engineering into writers. The content team serves as editorial conduits—they encourage, guide and celebrate anyone willing to take a stab at a blog post.
This is how you win with technical content.
You can create an environment for your team to get ideas out there and talk directly to their fellow developers about your product. You can support this with the right business case content to make sure execs have all the information they need to make the right decision. Then, you can build out a use-case framework to get your product in front of as many eyeballs as possible.