insights. the developer buying journey

Developer as a marketing persona has been around for a long time. If you Google developer marketing, you can find content targeting that niche published almost 10 years ago. So you have to ask, why is it just now becoming a hot topic for enterprise companies? I believe that there are three main drivers of this trend. First, increased competition around the products developers use has exploded. Second, as Horowitz would say, “Technology is eating the world.” Almost every company employs or contracts out to developers in one way or another. Finally, our visibility into funnel analytics has revealed a cohort of users who don’t follow the expected buyer journey, yet play an important role in software sale.

“34% of opportunities are lost as the direct result of developer influence.” Luke Kilpatrick

The developer persona as it relates to the sales process.

Recently CEB released updated research around the personas associated with an enterprise buying group. They identified and broke individuals that influence a buying decision, into 7 different types:

  • The Go-Getter
  • The Skeptic
  • The Friend
  • The Teacher
  • The Guide
  • The Climber
  • The Blocker

They then divided these types into two categories, mobilizers, and talkers. When you overlap these individual types with buying criteria, (think BANT or ANUM) you can identify and engage the right individual, with the right ask, at the right time while avoiding individuals who slow the progress of your opportunity. In theory, it’s the perfect framework to guide you through the sale process … Until you look at the developer persona and how developers make purchasing decisions.

Unlike other buying personas, developers do not assume a single type or state, instead, they transition through the various types as their familiarity with the product progresses.

Developers almost always start their journey as skeptics. They might evolve into blockers if your product doesn’t work, or teachers if it does. Eventually, depending on circumstance, they can evolve into a guide who evangelizes your technology and helps other developers understand it and if you’re lucky go-getter, advocating for your solution internally.

If your team can provide the resources needed for a developer to move through the stages of their journey at their own pace, they will begin to form what could be called a ‘buy-in group’. Buy-in groups are different than buyer-groups because their motive is not to make a purchase. Their motive is to maintain consensus around the best solutions for their organization. This is why developers do not fit into a typical sales framework.

an open buying journey

The second place where developers break the stereotypical sales framework is how solutions are identified and qualified. Though nothing is absolute, the developer buying journey often starts with open source. Open source communities are where innovation in the tech world happens. Open source projects live outside of the confines of any single corporate agenda and are usualy guided by a unified vision of the future. Additionally, open source projects can be used and evaluated for free. They can also be built on or customized however the developer would like.

When developers identify an issue they tend to shop for solutions that are open source. But that poses a few problems. Open source is not always the most practical or secure solution. Open source projects don’t come with support, there is no way to guarantee who can and cannot contribute, and most importantly you can never really know how secure the codebase is.

Because of this, developers begin moving downstream from open source projects to identify the products which are built on top of them. By the time a developer gets downstream, their buying decision has already been made.

a marketers role in a developers world

If developers are going upstream to identify solutions, what can marketers do to shape the buying journey?

When we look at a typical consensus sale, it’s usually lead by the head of whichever part of the organization where the tool or service will be used. Those individuals generally make the decision for their entire organization, they might get feedback or take their teams opinions into account, but at the end of the day, what they say goes.

Developers, on the other hand, don’t work this way. There is rarely a single developer who speaks on behalf of all the developers in an organization. This is where we get back to the ‘buy-in’ group. Once the solution has been identified the developers on their team will validate the solution for themselves. It’s up to the developer marketing team to make their solution the obvious choice.

Accomplishing this easier said than done. Developers will generally choose a product based on the perception of your company concerning the upstream (open source) project. Do you make valuable contributions to the project? Are you experts on the project and the underlying technologies? How deep is the value that you bring to the table?

It’s the job of the developer marketer to make sure that these questions are being answered visibly. This looks like including the upstream project name and branding in your marketing material, showing up to support the upstream community at events, participating in their community meetings, and amplifying the projects marketing efforts.

I hope this post was valuable. I am considering adding a second part to it. I consider shares, likes, and RTs votes for part 2.