The following is a guest post from Michael Ferranti, a marketer and product guy living and working in San Francisco, USA. You can follow him on Twitter @ferrantim where your tweets in English and français are welcome, or on his blog.
I’m lucky enough to be writing this post during a break at LeWeb in Paris, a conference celebrating its first 10 years by looking out towards what’s happening in the next 10. One speaker that opened the conference’s first day was Phil Libin of Evernote, who frequently speaks about an even longer time horizon as he builds a “100 year old startup”. In addition to being a genuinely humble and likable speaker, in his talk Phil nailed the essence of branding which drives Evernote’s marketing strategy: “The job of marketing isn’t to convince people to buy a product, it’s to figure out what will make customers love you more.” Evernote accomplishes this task, in part, by selling socks of all things. For the increasing number of developer-focused products, the methods for branding may be different, but at its core, the goal is the same: make customers fall in love.
First things first, what’s a developer?
The word “developer” is problematic when discussing a “target market”. It’s well known that Cobol developers are some of the profession’s best paid and they are highly sought after. A search for “Cobol developer” on Indeed.com, one of the U.S.’s most popular job boards, receives 943 results. These individuals programming mainframe servers for some of the world’s largest companies are clearly developers, but fall outside of what most people mean when speaking about “developers”.
I think a more useful analogy is to talk about where the developer you want to target falls on the Technology Adoption Lifecycle. Often, the people we refer to as “developers” fall into the Innovators and Early Adopters category. These are individuals who are comfortable adopting new technology, often preferring something that’s new (think Go or Docker) over more mature technologies (Python or virtualization) because they’re new and promising and these cutting-edge developers love to learn about what’s new.
The “developers” in right half of the distribution are by definition increasingly conservative in their adoption of new technology. This is still a huge market (50% to be exact), but not the focus of this particular article. Appealing to more conservative buyers requires different sales, marketing and product development tactics and is generally less relevant for developer-focused startups today taking advantage of what a second LeWeb speaker (investor Fred Wilson of Twitter, Kickstarter and Soundcloud fame) called the transition from hierarchical to democratic decision making.
T-shirts, candy and video games. Is that all you’ve got?
If we assume that creating an awesome brand can make customers notice and then fall in love with your product, the obvious question is “how do you create that brand”. One way to do this is by speaking your audience’s language. This is where sponsored hackathons, complete with candy buffets and free t-shirts, Macbook Pro prizes and video game lounges came from. These events are great opportunities to connect with developers and show them you understand their values, the but risk is that they degenerate into a caricature that ends up turning off developers. New Relic is a great example of this. For years, I’ve admired New Relic branding. They struck the right balance between being a fun, quirky tech brand and aggressive growth-focused marketers. But I’ve began to notice a shift. Whereas previously they provided rewards in-app for accomplishing certain milestones, they are now begging prospects to install their agent in exchange for an Xbox or tshirt or Beats headphones.
It is impossible to visit New Relic’s site and NOT subsequently receive dozens of ads encouraging you to install their server monitoring agent (I dare you to try). I don’t want to argue the efficacy of these programs driving conversions. New Relic is clearly a sophisticated data-driven organization and I bet they’re working. The real question is whether such pandering and low-brow tactics (bribing customers with video games in exchange for action), are they going to end up attracting the wrong developer audience overtime. My argument is yes.
Remember, developers are influencers
Adrian Cockcroft, lead architect at Netflix is probably one of the most famous “developers” in the world right now. A master of personal branding in his own right, his personal endorsement of Amazon Web Services (AWS) over the years has literally created billions of dollars of value for Amazon. If it wasn’t for Netflix using AWS, Amazon would have struggled to gain has much traction as they have. No other cloud services company can claim such a high-profile app built on their service and it is hurting them dearly. Would Cockcroft have been influenced positively by an offer for a free t-shirt? Or an Xbox? No way.
Give developers what they REALLY want…knowledge
Above all else, innovative developers on the left side of the Technology Adoption distribution love to learn. It is what drives them to wake up in the morning and to code all night. Coding is their scientific method, each line an experiment in making an app more efficient, more resilient, more…whatever it needs to be. When approaching a developer market every thing you do should be focused on education and teaching.
Teaching is branding
For businesses that sell to developers, the most effective branding is teaching. Of course you want to be known for being able to solve a hard problem, but beyond that, you want, and in fact need, developers to believe that you are an expert who can ultimately help them become a better developer. When you look at branding in this way, there end up being hundreds of things large and small you can do to help developers fall in love. Here are just a few:
Open source your code
Recently at Mailgun we open-sourced a major part of our application. When we did this, we received a surprising amount of coverage on some of the media properties that are most important to us, notably HackerNews and Twitter, as well as a ton of interest on Github. Developers were ecstatic that one of the most successful email APIs on the planet had just open-sourced their MIME and email address parsing libraries. If your app does anything related to email, this is a big deal because the code is battle tested in a way that would be almost impossible for any other developer to do. That’s a ton of value and it sticks in a developers mind, especially when the company commits to using the same code in their own production environment. This is the open source walk. The rest is just talk.
Share what you’ve learned
Another way to endear other developers to your brand is to teach them, not about your app or API itself, but the underlying technology on which its built. If you have successful API (or a brand new API that’s solved a unique problem), you’ve had to deal with infrastructure scaling or other problems that are likely the exact same problems your customers have. For instance, maybe you outgrew MongoDB for a certain process in your app and transitioned to Redis as a key-value store. Or maybe you’re experimenting with Go, and found some areas that it really helps, or some areas where though promising initially, didn’t end up helping at all. Blog about that. People buy from other people they trust, and showing yourself to be an open, competent and helpful engineering-led company will appeal immensely to other developers.
At Mailgun, after we open soured a big part of our app, we followed this approach and wrote a second blog about what we learned from the experience of open sourcing the code to begin with. The open source movement is exploding right now, but open sourcing code the right way is actually much more complex than most people think (including the Mailgun team). Having been through the process, we felt like we had a lot to teach in this area, and judging from the results of the blog, which ended up being as popular as the one about the code itself, we were right.
Get your customers involved
Because developers are people, and people are social animals, it really helps your brand when you get your customers involved in telling your story. Traditionally, the way this has been done is with case studies. A case study presents a problem the customer had, the solution that they implemented and the results they achieved, everything a prospective dev customer would need to know. The problem is that they are BORING and no one reads them. The value from this type of case study is simply that they exist and provide some social proof that you’re not a complete unknown. But they definitely don’t contribute to your brand, because a brand is what people say about you when you’re not around, and things they ignore don’t make it into that story.
The way to fix this is by having your customers write the case study and making sure they include actually working code, or really good illustrative pseudo-code, so that when the reader walks away, they’ve gained a new skill, not just realized that you need a better marketing department. When your customers are well known, this is approach works really well. But here’s the kicker, it also works really well when they are completely unknown too. The reason is 2-fold. From a pure logistical prospective, when 2 companies have it in their interest to see a blog post succeed, it’s easier than when just one company does. Two companies mean 2 tweets, 2 likes, 2 upvotes. It’s math and it helps. The second, more fundamental reason is that even if the company is unknown, they’re showing their code, so the reader themselves can judge whether the solution is impressive or not. Traditional case studies require the reader to believe that the marketer isn’t lying to them. Developer-focused case studies lay out the code. And that makes all the difference.
Create great docs
Documentation is another great place to continue your developer branding efforts. Documentation has historically been such an afterthought that companies that do it well have a huge headstart in winning over the hearts of developers. So dear to a developer’s heart is documentation that in Rackspace’s San Francisco office there was an article about how to write great docs tapped to the men’s bathroom wall for about a year (sorry no picture)!
Parse, who was recently acquired by Facebook (and who also spoke at LeWeb today), is the best example I can think of here. Simply put, their docs are AMAZING, and when a potential user discovers them, they immediately understand that Parse is not just a mobile-back-end-as-a-service company, but a company who can teach them how to create apps their users will love. Besides, sloppy docs mean sloppy code, and being perceived as a company who writes sloppy code is the death knell for a developer focused brand.
How are you building and promoting your developer-focused brand? I’d love to hear your thoughts in the comments.
*My thanks go to Vianney LeCroart for providing feedback on an earlier version of this article.