Four Strategies for Business-to-Developer (B2D) Marketing

B2D or Business-to-Developer marketing is rising in visibility. It’s becoming more viable with the increase in influence (and responsibility) that developers wield in organizations of all sizes. Having spent the last 10 years primarily marketing B2B, it’s been an interesting (and sometimes hard) transition to business-to-developer marketing. This article gives you a bird’s-eye perspective on some of the main thrusts I’ve learned about in marketing to this audience. If you’re wondering how to get your message to developers, it breaks down into: human motivators, a flipped sales cycle, content and community. OK, now you can read the rest or not.

What I’ve always loved about marketing is that it’s a combination of two elements with very different approaches: your message and the delivery of the message. Message is creative; it’s inspiration-driven. Delivery of the message — the mechanisms by which you get your message in to the hearts and minds of your buyer — can be process-driven, hyper-analytical. This left-brain, right-brain combination is what makes marketing a challenge every single day of the week. How you craft your message and deliver it, however, is totally driven by who the core consumer of your message is.

Over the last six months at Jut we morphed from a DevOps oriented “data hub” to an “Analytics stack for developers” based on feedback from over two dozen enterprise beta customers. From marketing perspective this has been a fantastic experience, and allowed me to apply marketing principles to a new set of buyers.

Here are a few of the core things to think about if you’re going to market to developers.

Developers are people, too.

First and foremost, developers are people. (Shocking!) Why is this important? First — everyone is different. Just the fact that I refer to millions of people by one term is a bit off-putting. But to some degree it’s a necessity otherwise it’s pretty hard to put any kind of scale-out marketing strategy in place.

At Jut we had two developer-specific personas, and planned to build out more as we grew into a more sophisticated understanding of our buyer. One was a forward-looking software architect “Thomas” and the other was the core developer “Jenny.” For Jut they represented the person who was thinking of the system as a whole and how it would operate in the coming months or years; the other who thought of their company’s existing code as a service and they just used it to get their project done. Different skills, different focal points, different goals.

Why does this matter? Well, it does and it doesn’t. It does because you need to appeal to someone who has a shared view of the world as your company and product. You’re solving something they care about.

On the other hand it doesn’t because… people are people, and on some level we all want pretty similar things. Developers want to solve the problem in front of them; they want their lives to be easier. They want to focus on doing what they do better. Your product either gets some low-priority things out of their way or provides a revolutionary approach to a core challenge they are struggling with.

If you understand your buyer, their challenge, and what you’re providing, you’re most of the way to crafting a message that will resonate. From there it’s a matter of degrees and inspiration to take your message from merely functional to eye-catching. This last part is best done over many sessions, many participants and perhaps a few beers.

Flip the notion of a “sales cycle” on its head

Message may get a developer to initially use the product, but from there the product does the heavy lifting of proving that it delivers on the promise your message made. This is pretty different than sales-driven B2B selling. In those cases there’s lots of PowerPoint, whiteboarding, and perhaps a few expensive dinners before you ever get to trying the product. When the customer actually tries it, a sales engineer may be doing most of the heavy lifting for the customer.

My experience with developers has shown that the most important thing you can do is quickly and easily let them use your product. This statement can be easily applied to other segments — most obviously consumer sales, and also some lightweight B2B products (take Hootsuite for example).

With developers, however, much of the core integration and programmatic interface is exactly what you need to get into their hands. Developers do not want to trial the product. They do not want to demo the product. They want to use the product to accomplish a meaningful task at some scale that is meaningful for their ongoing operations, without regard of a 30-day trial period or typical sales engagement. As an anti-pattern, check out Hubspot… if you want those APIs, you gotta pony up the big bucks. No developer is going to proactively consider it as a solution to an issue they are facing; it would have to be pushed down on them by someone else.

I think this is one of the reasons the commercialized open-source model has taken off in the past few years. Developers have had experience with the open source product, they know what it does well and where its faults are. They have gotten to use the software without any commitment, any “sales cycle”.

Opensource isn’t the only way to do it, however. There are a fair number of examples of companies that have done an excellent job of providing a commercial product that has a useful offering at no cost, or a cost so low that anyone would be willing to try it. Some examples:

The key is that value derived from the product comes before purchase. It’s a given. If your product requires consulting, training, and your company’s experts to get the first level of value out of what you’re offering, you should either rethink the product or rethink your go-to-market.

Content is king.

One of the most exciting parts (for me!) about marketing to developers has been the value and importance of content marketing. It’s fancy way of saying you need to write good stuff that your audience cares about. If you do, they will spend more time with you. Note that doesn’t mean they will immediately try your product (some do), they won’t immediately talk to a sales person (none will), but they will agree to spend time reading what you wrote, reading the next thing you write, and some will eventually use your free offering (see the section above!).

There are three kinds of content you can create that matter to devs:

  1. Documentation. It’s down in the weeds of docs that devs really figure out what your product is, what it does, and how it works. Invest in making your documentation a fantastic experience.
  2. Code. You want content that developers will connect with? Code is what they do day in day out, so it’s lingua franca. You can give them something useful that also expresses what you care about.
  3. Blog posts and articles. Tap into the broader issues that a developer deals with and start cultivating a relationship. Another cool example of this is Segment’s new Analytics Academy. It’s still young, but the concept is to provide a free, lightweight class on how developers and SaaS BI teams should think about analytics.

What’s interesting here is making content that’s relevant to your audience, and may or may not always be directly relevant to the value proposition of your product. It’s pretty hard to be the one who writes relevant content for a group of developers. If you’re a former developer you’re probably in worse shape, because you think you should be able to write relevant material. But content marketing works best when the author can speak to the pains that your audience is feeling right now, with a depth that shows you feel the pain as well.

As a result, my personal role in content marketing for developers has been one of brainstormer, facilitator, editor, and distributor. What’s missing? Writer. I’ve worked closely with our developers to take their ideas and help them flesh them out. Here’s an example, again from Jut:

We realized that our product concept of building an “hub” that stores log messages and metrics was something that many developer organizations were doing on their own. So working with Henri DF we brainstormed a high level, how-to article on the challenges we faced building such a hub. Henri did the heavy lifting of writing it, and I helped him edit, streamline it to (hopefully) make it more compelling. I also then worked to get the article broader distribution than we would have gotten on our blog alone. We ended up posting the article on The article eventually made its way to medium, was planned for our blog, and potentially into a larger paper that explains our end-to-end approach.

Find & contribute to your community.

When you talk to others about developers invariably there will be some comments about how “introverted” they are and how the only way to get anything done is via slack. While there may be some truth to that, I was also amazed that developer-centric events & conferences ended up being a pretty effective marketing mechanism. Why?

Turns out that even the quietest, inward focused person has passions that he or she would like to share with like-minded individuals. And events are simply one form of community that you can tap into to find your path forward.

If your objective is to show up in those communities (whether online or offline) and simply sell your wares, I think you’ll see limited success. Similarly, if you end up creating a community, you’ll probably fizzle if the only goal is to make the sale.

In all honesty, I’ve had little success creating successful communities and more success joining existing ones. Some of the products I’ve worked on were closed-source, enterprise-sales products that couldn’t effectively morph into a product that would be successful in a community. And others were just too young — community takes time and commitment. Instead, being a participant in the places where a community already exists has been a more useful way to get started. I’ll keep trying!

Most of all… be helpful to developers in their day to day work.

With other audiences, a more traditional approach of offering a product, building a face-to-face relationship through a sales cycle still works and makes sense. With developers, the model isn’t quite the same. If I could sum it up for you with one question that will help you direct your efforts it would be:

Are your efforts helpful in a developer’s day-to-day work?

It’s the critical element that appeals to the no-BS mentality of someone who is on tap to deliver new functionality and new code every sprint. It’s the difference between spinning yarns of how your product will increase company ROI, productivity, or collaboration. Those things are nice and valuable… but you’ll find that the appeal of those angles will ring true higher in the organization. Instead focus on:

  • Simple, low/no cost, no obligation ways for developers to use your product and derive value quickly. Your product must do most of the selling.
  • Open source — whether it’s your core product or an ancillary project — that has been helpful for you and would be helpful to your community of developers.
  • Great content that helps developers in core aspects of their jobs.
  • Community. It’s a great way to cultivate relationships. Get involved. Don’t go to the community to sell.

The Business-to-Developer model is challenging and, given it’s still in its youth, evolving pretty quickly. I won’t claim to have it nailed, but hopefully my experience will help you.

I’d also love to hear from other marketers or developers — what works?