Selling software is an exercise in convincing the buyer that what your software can do is worth the cost, and they can trust you to deliver. It boils down to a comparison; however, when your software is aimed at solving problems for developers, the math gets more complex.

Developers buy with time and risk, not money.

The amount of money is often trivial, or they are putting on a company account and don’t care too much. Developers are tasked with integration maintenance, and taking the heat if problems arise during those tasks. Developers are less concerned with getting the most value and more with making the right technology choice.

Empower developers to make the best choice

Developers want to know what they are getting themselves into, and they want to find out with as little friction as possible. Give developers ways to imagine what using your tool would be like, without actually having to use it. Demos are great at this. Then, put yourself in the shoes of a potential user, and think about what stumbling blocks or points of confusion they might run into along the way. Answer those questions and remove those stumbled blocks. Here are some examples:

How Do I Get Started?

“How hard will it be to set this thing up?” “Does it work with the languages and tools I’m already using?” Help developers get quick wins. Here are some tactics to consider using to improve your developer onboarding experience:

• A specific “getting started” guide on your blog or in your documentation. (Stripe Development Quickstart)
• Several examples with copy-pastable code snippets. (Installing NewRelic)
• Sample scripts and usable libraries on Github. (Docker for Java Devs)
• A document that shows the guiding principles behind your tool. (Thinking In React)

Getting started is, of course, just the start. Once a developer has completed your version of “Hello World”, then what?

What Happens When I Get Stuck?

At some point, developers will hit a roadblock. They know this, and they want to know that when it happens, they have help to get through it. Here are some signs I look for that build trust and make me feel safer when I’m looking at new technology:

• Your documentation is thorough and up-to-date. Nothing is worse than trying to solve an issue and when you look for help in the official docs, it just makes it worse. Don’t let this happen to your customers.
• A way to get in touch with others. This could be a community on Stack Overflow, on your own site, or on Github issues. You can’t control how others talk about your product, but you do need to show up. Be responsive to issues in whatever way you communicate with others.

Once you’ve torn down roadblocks out of the way of the developer, you can move on to the more fun stuff.

What Else Is Possible?

What else can your product do that maybe they didn’t think of? After you make someone feel safe, you want to get them inspired. Help your developers explore possibilities they haven’t thought of yet. If you convince devs that they can solve their problems and do more than that, then you’ve really earned their trust, and they’ll feel good about using your product for some time to come. Here’s a great example: Github Guides

Win Developers Over With Education Over Persuasion

Developers tend to be particularly allergic to the typical marketing schticks. Regardless of the audience, marketing should be done with a sense of generosity instead of self-indulgence. However, I’d be particularly wary of more aggressive forms of marketing, such as pop-ups or over-the-top headlines. Your best tools in this conversation are honesty and clarity. Here’s a great example of what not to do.

Kill the fluff. Be clear, be honest, and be useful.

Empower Developers and They’ll Happily Advocate For You

The more knowledge you can share, the more you de-risk the use of your product. Remember that the developer is taking on multiple risks. There is the risk that they make the wrong choice, and it harms the project. The other is that they make the wrong decision and it makes them look bad to their boss. That’s the true fear you need to overcome.

You need to turn developers into advocates.

Help them feel confident in recommending your product by making your product as easy and safe to work with as possible. Again, you can’t rely on marketing tricks here. You cannot appear easy-to-use and reliable, you have to actually build a great product, and communicate about it effectively. Do that, share everything you know, and you won’t have problems winning over the minds and hearts of developers.

The post The Struggle of Marketing To Skeptical Developers appeared first on Glenn Stovall.