Having spent years on marketing teams at B2B startups, I heard the following phrase a lot: "Developers don't like marketing." It was used to explain away many of our decisions. If we did or didn't do something, it was “because developers don’t like marketing.” But is it true?
The answer is no. Developers don't dislike marketing as a practice; they actually dislike gimmicks, irrelevant messaging, and things that don’t actually address their problems or their needs. They hate feeling like their time and their needs aren't respected. They hate "sleazy" sales tactics and spoken to as potential customers as opposed to people with real problems.
I know developers don’t hate marketing because many developers care about personal branding, content production, and selling their products and/or services. New products, tools, frameworks, libraries, and even programming languages emerge, and developers adopt them enthusiastically. Word-of-mouth, blogging, guides, even conference talks......all of these are forms of marketing that developers already use to build communities, generate leads, and turn leads into customers. And there are plenty of examples of people who are doing marketing well with developers.
So who is currently winning at developer marketing? Developers themselves. The best and most successful developer newsletters, blogs, screencasts, podcasts, events, books, have been created—and shared—by developers. These are all developer-led, and there is much that marketers at B2B companies can learn from this group.
Here are mistakes marketing teams make when marketing to developers:
Not specifying which "developers" they're referring to. Every developer is not in your audience, and yet time and time again, we use the singular (and enormously broad) “developers” label to define what is actually a very specific audience. What kinds of developers are you targeting? What do they know? What tools are they using? What are their problems? The more specific you can get, the more relevant your message will be. A product that targets enterprise developer teams is different from one that is meant to be used by security engineers. The best way to learn more about your audience is to talk to them. Not just draw conclusions based on a few conversations, but talk to them, observe them, and immerse yourself in their ecosystem. If the work they do and the conversations they have excites you, it becomes much easier to look at them as people versus "potential customers you have to study".
Expecting something from developers without having earned their trust. If you haven’t taken time to develop trust with your audience by consistently creating and sharing valuable content, they will hesitate to give you something in return. The problem is not that "developers" don't spend money; it's that they want to make sure your product addresses their problem first. Before you add friction (like placing content behind a gate) ask yourself: have I delivered enough value to my audience? Have I made it easy for them to find and access this information? In exchange for their email address, am I truly giving them something of value, something that will help them succeed in some way? The trust-building doesn't end there; you have to think more downstream. If you're asking users for an email address, what kind of nurture stream or funnel will you put them in, and what value will they get from that? You have to deliver value at every stage of the customer lifecycle.
Crafting messages that don’t address real problems. You've seen it before: the visually appealing B2B homepage that uses terminology like "blazing fast" and rattles off a bunch of cool features its signature product has. That's all well and good, but how does this solve my problem? "Value propositions" are sometimes interpreted as "list out the feature set and specs" by marketers, which leads to a missed opportunity. Users don't care about how fast your product is; they care what your product can help them do. Talk to a bunch of customers and users and ask them about their problems. Listen to the words they use. Ask them what the solution would enable them to do; not just at a low-level, but in a high-level. What will they be able to do once the problem is solved? You want to understand the entire problem space, including the downstream effects of using your product. Your feature set only matters if you've framed them in terms of actual wants and needs. (Note: one of the reasons this happens is because marketers speak to both users and the people making purchasing decisions, who are not always the user. The person making a purchasing decision might have different boxes to tick and scan your site for the right keywords—typically features. Features absolutely have their place! But you still have to understand the problem space very well.)
Users don't care about how fast your product is; they care what your product can help them do.
Everyone in the company describes the product differently. This is related to the problem above, but if everyone isn't singing the same tune, that will reflect in the company's marketing strategy—and not in a good way. If too many people have different ideas about who the audience is, what the value props are, and describe the product in different terms, the misalignment will lead to end-user frustration.
Using gimmicks and employing marketing tactics because a competitor is doing it (or because they don't understand the customer's goals). Two things are true: competitive analyses are helpful tools for gauging what your competitor is doing well (and not so well) AND doing something because your competitor is doing it makes you look unfocused. We don't have to reinvent the wheel here; just because Company A's multichannel strategy is comprised of heavy TikTok usage, an amazing podcast, and a hugely successful annual hackathon program does not mean that you need to do these things, too. There is and should be room for experimentation and trying new things. But jumping on the latest trends without tying them into the overall strategy and not investing the time and resources into building these channels out will make you look like you're trying too hard. Furthermore, adding a gate or paywall in front of a blog, putting an obtrusive pop-up before users have had the time to click through the site, or taking people to a page they did not expect to land on are frustrating user experiences. Multiple CTAs in an email are overwhelming. What is the most important thing here? What are users trying to get out of this interaction? You have to look at your marketing in terms of a user flow, a journey, and an end-to-end experience to better understand why some tactics will turn people off.
Not showing other teams internally how they can help. Have you heard the phrases, "UX is everyone's job" or "security is everyone's job"? The same is true of marketing. There is a difference between marketing as a corporate role and marketing as a practice and set of activities. Marketing is everyone's job at a company because ultimately people want to build, promote, or work on products that other people want to buy and use. That engineer who gave a conference talk about the way they scaled a team? That's marketing. The developer advocate who wrote a guide in the official documentation about deploying a site onto your cloud platform? That's also marketing. The designer who published a blog post about working for your company and shared job listings for her growing team on Twitter? That's marketing. The truth is marketing teams can do a lot to help their sister teams internally get their messages out, refine their messaging, or do better at their job. Is customer support writing their own canned responses for support tickets? Offer to review and/or rewrite these messages with them and share best practices, maybe a corporate style guide! Did the technical writing team produce new guides this last quarter as a result of incoming customer requests? Publish them in the weekly newsletter and push them out on Twitter to help users find them. There's other content being created and marketing-adjacent activities (like developer relations) taking place in non-marketing teams that nevertheless further company goals. Find out what those are and show people how your team can be of service.
There is a difference between marketing as a corporate role and marketing as a practice and set of activities.
Here are some guiding questions that will help marketers reach these audiences more effectively:
Are there other ways of meeting our goals that create less friction for the user?
What are they doing when they land on this page? What do they expect to see?
How do our users consume new information? Does this format facilitate user understanding?
What do our users value? What do they need?
What do we as a company do really well?
What problems do our products solve?
Who is my audience? What do they do? What conferences do they attend? What do they want to learn? What do they read? What do they like? What do they need?
In summary, developer marketers (and developers marketing to other developers) can learn a lot by observing and listening to their target audiences without judgment and without giving into preconceived notions about their audience's habits and preferences. Technologists are discerning customers who are sensitive to misused marketing tactics that exist only to get their money versus deliver value. Technologists value honesty, transparency, and people who understand their problems and their needs. Developer marketers who lead with a desire to learn more about their audiences will be more effective at reaching them and delivering value more consistently.
Like this post? Purchase The Developer's Guide to Content Creation for more content-related tips and exercises.
コメント