Marketing to developers has become increasingly common yet it’s unfamiliar territory to many experienced marketers. Companies remain confused about how to strike a balance between enterprise appeal and gaining traction with adopters. Learning the language and understanding the developer persona is just the first step. Go beyond by understanding a uniquely complicated buyer’s journey and the need for no-nonsense practical proofs.
To review, the natural evolution of software is components as primitives (base elements) and more specifically Service-Oriented Architecture (SOA). Instead of writing a function to perform a task from scratch and tightly integrating it in dependent ways, you rely on a component that runs independently and communicates with your application through an API. Need real time messaging? There are multiple vendors that provide APIs that take care of all the housekeeping. Need an analytics function or a data ETL process? Developers used to spend huge amounts of time writing basic functional code and then more time maintaining it. Now you can usually find a robust full-service solution that let’s you focus on delivering core product features and get to market faster.
It’s important to understand this in order to understand how crucial developer marketing has become over the last 15 or 20 years. As we become more modular and service-oriented in our architectures there are more businesses marketing to developers-as-consumers. Product-led-growth isn’t just for end-user applications but also for software components and services. Yet it’s been apparent to me that there is a huge deficit in understanding around the developer persona and in understanding how they engage with products.
I honestly only know a handful of other marketing people who started as engineers and almost none who still code and remain part of that world.
A lot of marketers seem to assume that developers act like businesses or, alternatively act like consumers. Few seem to understand that it’s both, but with a twist. B2D — Business to Developer marketing — is a particular thing. It’s essentially a hybrid of B2B and B2C in that you are marketing to a business but the initial decision maker (adopter) acts partly like a consumer. A HUGE difference is that there is a very appealing off-ramp: an adopter or buyer can quickly become a competitor, figuratively or literally. Imagine if you are selling cool electric cars but that your customers, if dissatisfied, might turn around and start their own company to compete with you. Or just build one because it’s fun. Obviously the barriers to entry for manufacturing automobiles is very high and so that really doesn’t happen. But with software a single developer could potentially obliterate your business. A buying decision maker, say a VP of Engineering may conclude (often erroneously) that it is cheaper/better/faster to build rather than buy even if they don’t intend to compete.
Software projects started by a single individual can quickly grow to be viable alternatives that have particular appeal to developers — they are usually free to use, easy to adopt, and often open source. There are so many examples of this. Linux started as a free alternative to desktop operating systems like DOS. Now various versions of it Linux together share market position for servers. MySQL was started as an open source project but ended up with a $1 billion valuation and was such a thorn in Oracle’s side they bought Sun (I’m not discounting Sun’s hardware business or Larry’s ego here). LibreOffice started as StarOffice and was bought and used by Sun which had a “No Microsoft ever” policy. This was forked into LibreOffice via OpenOffice to become a more mature and viable competitor to Microsoft Office — it’s estimated there are 200 million active users worldwide and it’s the default office suite on most Linux installations.
Those software alternatives didn’t happen overnight but they were all sparked by some developer’s desire for a cheaper/better/faster alternative and they all became a at least a drag on one or more company’s business. Many argue that Linux in fact killed Sun and that’s a big reason they bought Cobalt — to have a Linux answer in house. But, and this was my first lesson in this, they did not understand open source and failed.
So imagine how much easier it is to build a smaller-scale tool or service that solves one problem well in an SOA-oriented application, for example Socket.io vs Pusher. Even in early releases Socket.io worked well for many developers needing that functionality in their apps. It matured into a serious alternative that Pusher had to address in it’s marketing. That’s a whole segment you have to think about and expend more resources on.
And worse, choices for developers are like being in a well-stocked supermarket but you get to try products before you buy. There are 15 kinds of shampoo and you can take a few home to test out. You can read the detailed information about each one, tons of reviews, and ask your friends about them. Even use them for a long time to see how they perform in real world daily use. And if you don’t like any of them the ingredients to make your own, along with sample recipes, are freely available.
I’m hammering on this point because it’s crucial to understanding the developer persona and mindset. Any friction, be it cost, usability, extensibility, performance or something else, can push a developer to seek alternatives, just as a B2C persona might (I’d argue with a much lower tolerance for friction), but with the added complication that they can make their own. They desperately want to reinvent every wheel because it’s way more fun and interesting. And they probably want to avoid enterprise-y tools in part to avoid vendor lock-in but also because of a natural suspicion of enterprise B2B messaging & marketing which just isn’t speaking to them. Too much of the wrong kind of flash and polish and they’ll go out of their way to avoid your product and tell all their friends it’s junk.
There are many variables, but touch on some basics, B2D marketing requires a few really hard and fast rules to do right:
1. Never lie and avoid hyperbole. Developers have amazing BS detectors. You as a marketer kind of specialize in BS (admit it) so you really have to watch this.
2. Know the language and use it. There’s no faking this. If you are not a developer run everything by your engineers. Bringing them into the marketing conversation (often via Developer Relations) is a great tactic.
3. Understand the buyer’s journey for your product and that it’s almost certain that if developers are involved a traditional linear view of this is inadequate. In this world it’s multi-faceted and nonlinear with multiple personas and touchpoints having variable value that is highly situational. Understanding this and being able to map it to demand generation and revenue ops systems is one of my key skills. Most tools like Google Analytics can’t capture this at all. If you are facing this perplexing problem, get in touch. I can help.
4. Your numbers are wrong. Developers universally block ads and trackers, give fake emails and generally play havoc with all manner of tools we depend on. Some of us run our own DNS servers (e.g. dnscrypt-proxy) and use block lists to completely kill any tracking. You need to spend more time with product qualification metrics and figure out clever ways to manage that.
5. Proof is social. Your best road to adoption is prior adopters doing something cool and being vocal about it. Promoters, as with B2C, are key, but the proof has a lot of weight and will be dissected very carefully. An engineering blog, tutorials and conference presentations are very useful here.
6. You have to keep up. Like software, B2D marketing is iterative and needs continuous integration. Software moves quickly and techniques and practices are constantly evolving. Developers, unsurprisingly, develop stuff and the universe of everything from languages to frameworks to libraries and more is constantly expanding. A good example of this integrations. If you aren’t offering an integration with whatever tool or service is cool this week (slight exaggeration) you are going to fall behind trends that have real impact on signups and activation. Can you imagine launching a new marketing app and offering only Salesforce and not HubSpot integration?
This last rule also means you need to be constantly iterating on product hand-in-hand with your marketing. Like B2C consumer goods, this is especially true of your positioning (in tune with rapid industry trends) and messaging (in tune with broader cultural memes). I argue for driving product-led growth with product-centric teams in part because keeping things in sync speeds response time and gathers more critical input. Integrations, for example, could be seen first by anybody — a sales person getting a request, a DevRel person at a conference, a marketing or product person doing competitive analysis. Tight coordination is critical to getting ahead of these trends.
Thanks for hanging in here. I’m biased but feel there is just no substitute for marketers, especially PMMs, with developer experience. But you can get close by investing in Developer Relations to act as a bridge. They should be part of marketing, not product and accountable for marketing results. Just don’t call them that.
