B2B developer marketing? It’s complicated.

We’ve covered a lot of ground thus far in terms of how to market to developers, from how to deploy content marketing to the importance of not making assumptions about them on the basis of the developers you may happen to know.

I’ve got a pretty vital word of advice to add to all of that: When you’re marketing to developers, never forget the fact you’re not just marketing to developers.

Who are you really selling to? Code or software design isn’t ever standalone. It’s part of something bigger: a product, whether it’s an app or an enterprise platform.

Beyond that, you may have to consider your potential customer’s product as being part of something even larger: the company that’s bringing it to market, or a developer ecosystem or user community built around it.

So developers aren’t your sole audience. There are others who’ll have a voice in the purchase process, and you need to figure out who they are — and how to engage them, too.

A longer journey, with more gatekeepers

Even without the nuances of dealing with developers, B2B selling has gotten tougher. The average number of customer stakeholders involved in a B2B purchasing decision now stands at 6.8.

Back in 2014, you had to convince a mere 5.4 of them. That’s 25 percent more participants in the purchase process in just two years, driven by factors like decentralized decision-making, globalization and aversion to risk.

In approaching a development team, it’s not going to be any different. You’ll just have to contend with the idiosyncrasies of communicating your value proposition to devs, something we’ve delved into in-depth already.

Yet very rarely do two or more developers on a project come cut from the same cloth. The dev working on a product kernel and the one dealing with UI/UX have broadly different jobs and skill sets, but they might both have a say about what you’re trying to sell.

Each individual developer will have a multi-faceted role, too. That’s just the nature of the beast inside fast-paced enterprises. They’ll spend time developing applications, modifying existing ones, testing, researching, purchasing, and somehow carving out time for learning new languages and skills.

So, depending on the nature of what you’re marketing, there’s a good chance you’ll need to develop a targeting and engagement strategy that accounts for a variety of different developers, as well as for non-dev stakeholders (who may be outside of a product team) who’ll have a say in the decision process. That’s nearly guaranteed if you’re trying to make inroads with anything above a small firm or development studio.

Where’s a dev in the org?

Let’s examine a fairly simplified org chart for a development team.

Everyone on this chart may be part of the same product development effort, and may have a voice in the purchase process, but as with any other hierarchy at any other organization, each of them has a different role, agenda, set of responsibilities and accountabilities.

There are “developers” all over this chart, but no two have the same job or demands.

This doesn’t even map in a project controller, CFO or procurement/purchase manager, who have an even more distinct perspective, since they’re holding the purse strings. They’ll definitely be part of what SiriusDecisions calls the “Buying Group” involved, in some organizations, in vetting any purchase bigger than, oh, a router or a new box of paper clips.

Other stakeholders you may want to keep in mind beyond the ones who are directly involved with a purchase? The direct and indirect users of your customer’s product, managers of those users, customer support/help desk members, developers working on other programs that may interact with your customer’s product, even the “gold owner” who puts up money to fund its development. For starters.

Hitting their hot buttons

But let’s bring our focus back to the product team you’re trying to romance. What’s one plain example of how developers may view your product from different perspectives?

Let’s say you’ve identified two members of a potential customer’s development team, a software architect and a development manager, both playing a part in evaluating and (we hope) eventually buying your widget.

The software architect is looking at your widget from a top-down perspective, since he or she is charged with making macro decisions about a software product or platform, including defining its technical standards, coding standards, and the tools and platforms to use and design parameters.

The development manager is closer to the ground, supervising the design of specific modules, functionalities and features, with programmers below him or her to do the actual coding.

The development manager will want your product to simply work within the framework the architect has handed down. The architect wants your product to work within that framework without requiring workarounds or shortcuts that create technical debt, a great term for the trade-off that happens when gaining functionality in the short term creates headaches and a need to rework a product in the long run.

When you can identify product development stakeholders like this going in, and what their hot-button concerns or pain points may be, you’re a lot closer to success than if you’re focusing on just the “developer” you imagine your widget will absolutely, positively sing to. Because within any given organization, that presumed developer archetype may not actually even exist.

Feel their need(s)

Does it sound discouraging? It shouldn’t. When you accept how diverse your target audience is, even within a single prospect organization, you’ve taken a big step toward solving the challenge.

Here are the next steps. Mind you, the path isn’t short or easy, and it demands due diligence. At the end of the day, though, you’ll have a far more targeted marketing program ready for launch.

First: Create a target account profile

• If you know the customers you want to capture, build a profile of each organization so you’ve got a clear understanding of its products, its market stance, its goals, its hierarchies and more.
• If you don’t have specific target accounts in mind, build a profile of your ideal account based on your existing data and key learnings about past successes, or on where you want to drive your business.

Next: Map an account’s buying groups and their demand triggers

• Suss out the personnel and teams who’ll be interested in your product, as well as getting a clear understanding of what the “demand triggers” are that’ll get them interested in the first place. Price? Functionality? What’ll make them sit up and shortlist you?

Then: Personalize your pitch

As a growth hacker and a marketer, I’m always mindful of how important it is to have empathy for my audience, and this is a perfect example of applying that.

• Once you’ve identified the role-players who are part of a purchase decision loop, develop in-depth personas for each of them: the CTO, the development manager, the product planner, right down to the devs who’ll want a hands-on experience with your widget.
• The more detail about individual characteristics, job responsibilities, career situation, hopes and dreams and so on you can bake in, the better. That’s because it’s essential for customizing your marketing messages, even the channels and tactics you employ, for each key contact you’ve got to engage. The CTO may need to hear you speak at a conference; the dev designing a product may need to have heard good things about you from online peers. What you say and where you say it are crucial.
• There are AI-driven software engines available nowadays that can do some of this work for you and keep buyer profiles updated in real time, which can be 90 percent of the work in persona-based marketing — and is often the work that doesn’t get done. Keeping your buyer models current is key, especially in targeting developers.

Last but not least: Help them sell

• If you’ve engaged them, part of the nurturing process is to supply ammunition they can use to sell your widget in with the rest of the buying group or enterprise. The support you give them depends on their role, but it can include the actual product trial, ROI projections the dev manager or CTO can share with the CFO, or whatever else they tell you would come in handy in helping them make your case.

Go all-in on authenticity

I’ve written before about how important authenticity is in marketing to devs. A big part of establishing it is showing how you understand each of them as an individual, not just as a “target” you’ve typecast.

With developers, it may be even more necessary to flush away clichés than it is with other audiences, because they’re acutely sensitive to insincerity and presumption on the part of marketers. Drilling down into who they are and how you can help them succeed within their organizations will only set you up for success.

 

[Article on MarTech Today.]

---

Some opinions expressed in this article may be those of a guest author and not necessarily Marketing Land. Staff authors are listed here.

---