How to Avoid the Developer Dark Side

I’m going to do it. I know I shouldn’t, but I am.

Have you ever seen those click-bait LinkedIn one-liners? Yes, they drive me crazy too. But, they are effective. You’re still reading aren’t you?

I hate those one-liners. I opened this article with one to prove a point. I will never do it again. This idea of annoying marketing gimmicks got me thinking. What are the things that irk developers the most when looking at material online? After over a decade in? Developer Relations and a lifetime building apps in C, Java, Ruby, Photon, Node, and Swift, I’ve seen, and to be honest, probably used, some of these tactics to get Developer’s attention. I think the first step to recovery is admitting it, don’t you? Here are three of the main culprits I see too frequently. Hopefully it will help you the next time you post something that might lead you to the Developer Dark Side

Avoid Weasel Words

A former colleague at Twilio, Scott Fallon, hated what he called Weasel Words. You know those words like fast, easy simple that don’t actually explain anything. They kinda weasel their way out of answering a Developer’s question of “how is your product better?”. Don’t use weasel words. Ever. Always use something that is descriptive and self-explanatory.

Instead of simple, substitute it with why is it simple. Perhaps it’s simple because of drag and drop, or code completion, automatic dependency management, etc. Whatever it is, explain it. Of course, if you can find a word that summarizes your goal, excellent, go for it. The best example I can think of this comes from my time with Heroku. Heroku were masters at this. Terms like erosion resistant and polyglot speak directly to the geeky side of developers.

Avoid Too Many Sign up Fields

There is nothing worse to a developer, who has expressed interest in trying your product, then making them jump through hoops just to sign up for a free trial. Ask for the bare minimum to allow you to measure, track, and nurture a new developer, and get them into the product as quickly as possible. Spend more time making the product experience amazing so when they want to upgrade to a full license, they are happy to give you more information. You shouldn’t ask for more than an email, and password or provide a magic link for verification. Anything more and you will see attrition in your sign up process.

ThoughtSpot does an excellent job of this, by providing a live, ungated playground of their embedded analytics product. Developers can try it, and if it meets their needs, sign up. And for god’s sake, never require a Developer to get on a hangout or zoom to see a Demo. That’s an instant no-go.

Avoid the Sales Funnel

I get it, companies exist to grow revenue, PLG (Product Led Growth) is a huge part of this, especially for Developer offerings. At some point, you have to get developers to convert to your paid version, but don’t drop Developers in a sales funnel where they feel they are getting sold too. As discussed above, get Developers hands-on on your product quickly, let them see the benefits for themselves, and incentivize them to upgrade because your product solves their problem.

Twilio was a great example of avoiding the sales funnel, especially with their SMS APIs. As a developer I could signup, provision a phone number and send an SMS anywhere in the world. The process was frictionless. In less than 5 minutes you could see that the product solved your problem. But here’s the masterful part. In the free version, you could only provision one phone number and the SMS messages you sent were watermarked with a “Sent from Twilio Free Trial” message.

As a developer, you proved the product worked, you loved the Developer Experience, and now you choose to upgrade without ever hitting a traditional sales funnel. Yes, of course we measured the number of conversion on the backend, but our primary goal was not only the number of conversions, but also how could we reduce the time to conversion by ensuring the product exceeded the Developers expectations.

That’s how you market to developers and win! So much credit to this Developer-first model goes to Jeff Lawson. It really saddened me to see him step down as CEO. Jeff, if you are reading this, you inspired so many of us.?Keep those coding gloves on, and thank you for your vision and leadership.

Avoid the Summary

It’s too easy to fall into the Developer Dark Side tricks as a way to grab developers attention. Yes, sometimes they may work, but in the long run they will hurt your credibility and slow developer adoption and retention.? Developers are voracious learners. They are problem solvers. They thrive on building. They are always looking for a new tool, or service to make them more productive and leverage the latest technology.

As I conclude the post, I realized one other Dark Side Developer’s hate: the summary. At the end of a Quickstart or onboarding process, always include a next step for developers to keep learning and keep using more of your product. Make it seamless and flow into the next experience or use case. Expand their understanding of your products by introducing a sample application that ties in what? features they just used and how they can do more. Avoid the summary, and keep learning more.