I’m sure that you’ve read or heard in a conference that developers don’t want to be marketed to. We’ll, let me assure you that it’s a myth. But before you accuse me of being a lunatic, let me explain.

First of all, I am a developer and I believe that developers, as a group, are no different than the rest of us on the subject of being a marketing target. None of us like marketing if it is poorly done. Contrary to Monty Python, we all hate spam; at least the email variety -- I won’t speak to the one in the can. Email spam is no different than the junk mail that lands on our doorstep; both are messages that were delivered to someone that does not find the contents of value. Spam is associated with marketing and thus we end up with the myth that developers don’t want to be marketed to where the truth is that no one wants spam including developers. Spam is simply content that is delivered to the wrong person at the wrong time and thus the content is not of value. Content marketing is the opposite of spam, it is about getting the right information to the person that needs that information to help them make decisions or to take action that is of benefit to them.

So how do I bust this myth and prove my point. First, let me state my conjecture. A developer will want to receive marketing messages that contain content of value. If true, this means that it is OK to market to a developer but you have to do it in the right way. The key questions that I need to answer are:

  1. Do developers value marketing content?
  2. What content does a developer value?
  3. What channels of communication do developers pay attention to?

Do developers value marketing content?

What developers want is to be productive; they want to get their job done quickly regardless if they work for a technology company, inside an Enterprise IT team, are an independent developer, or a student. Every developer seeks the tools and APIs that will make them more efficient. In the past, the decisions about the use of a software technology was made by a decision making unit (DMU) in which the CIO or some other executive had the final say. But today, nearly every development project has become a mash-up of APIs and developer’s simply make their own decisions as to which tools they will download and use either on their own in small teams.

But developers need help in making a decision to use a tool or an API. When I start looking for a tool or API, I start with Google. I’m looking for candidate technologies. I’ll make a list of those candidates and then one-by-one will start determine if it is capable of doing the job that I need to get done. Once I have my short list, I start looking at other factors about the tool or API:

  • Is there an overview of the technology such that I can understand what it does and how good a fit it is?
  • Does it work with the technology that I’m using? If I’m using Python with Django, having an Java or C++ SDK does not do me a lot of good.
  • What kinds of problems have others solved with the technology? I’m looking for use cases from others such that I’m confident that further investment of my time is not wasted on a dead-end.
  • Is there a community around the technology? If there is, I’m more confident that I’ll get support when I need it.
  • Is the technology mature and are there a large number of users of the technology? Not only is this about getting support from the community but it is also makes me more confident that the technology or API will be supported and not deprecated anytime soon.

If I look at these questions, these are not unlike the questions that you might see in a Request For Proposal (RFP) if you selling your technology to the CIO’s corporate IT team. But unlike the top-down marketing this is a bottoms-up marketing. With traditional Enterprise Software sales (top-down marketing), you would have an experience sales rep who will spend a lot of time with the CIO and the decision making unit (DMU) to help them make a favorable decision in your direction. But no one has enough sales reps to do this with all of the developers that are out there; the bottoms-up marketing model requires too much reach and is far too expensive for traditional enterprise sales. Instead, you must create a self-service approach were the developers can get their questions answered from their desktop in their own time and at their own pace. If you do that quickly and efficiently, you will find the developers who value what you offer. If you fail, your technology will languish into irrelevancy because no-one will use it.

What content does a developer value?

In a previous blog, I wrote about the developer journey which is critical to understanding what content a developer’s value. Your job is to supply prospective developers with the content that helps them along their journey and thus helps them get their job done. The more developers that you have that have completed the journey, the more popular and valuable your tool or API will become.

The developers journey is made up of the phases that are marked by milestones that describe the developer’s relationship with the tools and APIs that they are considering to use or are committed to use. A simple model of these milestones are:

  • The prospect is looking for candidate tool or API that can help them get their job done.
  • The student needs to learn the basics of the architecture and how things work with the tool or API.
  • The intern is putting what they have learned into practice and are building something real.
  • Finally, the expert will help other developers along their journey but also wants to help influence the future direction of the tool or API

It’s important for you to understand which milestone your developer is along their personal journey. You must provide them the content that is appropriate to the milestone phase. Provide a “Hello World” example at an expert and you become a spammer; provide the same “Hello World” example to a student and you’re a hero.

So, what content will a developer value? It’s a simple question with the difficult answer of “it depends”. It depends upon where they are in their personal journey with your technology.

What channels of communication do developers pay attention to?

There’s no single way to broadcast to developers; they are simply too diverse and defy traditional channels. To reach developer’s you need to inject yourself into the very tools that they use when they are looking for information and again this will vary with where they are in the developer’s journey with respect to your technology.

The prospect is looking for a specific technology to solve a problem. When I’m performing this tasks, the first tool that I use is Google. After that, I might look on Github to find projects that use the technology – the more repos on Github that refer to the technology the higher the probability that it is popular and proven. I’ll go to Stackoverflow and see how much action the technology gets in the industry. I’ll also check out the developer portal to do a quick inventory to see if the documentation, downloads, licensing, and other critical are there. And that is just to come up with my short list.

Your chore is to figure out how to get each of these tools working for you keeping in mind that all you control is your developer portal. This is the order that I would use:

  1. The natural place to start is your developer portal. You need to think about all of the content that a developer will need throughout their journey and make sure that it is there and easy to find.
  2. Next, you need to use Search Engine Optimization (SEO) to make sure that your portal has the right keywords such developers searching for Google will find your content. Google adwords help, but I find that they are best for tuning your SEO keywords. This is a task of constant tuning to ensure that you’re doing well with that initial Google search.
  3. You need to create a presence on Github and you need to encourage your developers to do the same. Github is a bit of a mess and I think that integrating your portal across all of the relevant Github repos is a great way to help you keep on top of your Github presence. You might also want to allow Github usernames and logins to be used for logging into your own developer portal. Bottom line, you need to make sure that your portal and Github are working together.
  4. You can’t ignore Stackoverflow. You can purchase keywords from Stackoverflow and it’s a good thing to consider but you can’t stop there. You will need to ensure that your engineers and developers are monitoring Stackoverflow and getting questions answered quickly. Also, if you have some frequently asked technical questions, consider posting them in Stackoverflow and providing answers.

This is just a glimpse of the types of things that I’ve done in the past to help developers – there is much more that you can do but this would be a good start.

As you can see, developers do want to be marketed to but not in the ways that you’ve done it in the past. They want to hear from you but they want value from each and every communication and they want it on their terms. They’re not interested in your hyperbole; they’re interested in your valuable developer content that will help them do their jobs better. So when you market your tools or APIs to developers, make sure that you’re doing it right. Good luck and good selling!