Some marketing truths are universal. But if you find yourself selling to developers, buckle down, because you'll be facing some uniquely challenging obstacles.
I should know. Two years ago I switched from being a developer myself to being the founder and CEO of QuickAdminPanel — a code generator for the Laravel framework that I needed to market and sell to developers. It was a hell of a lot harder than I’d ever anticipated. There are a number of reasons why.
Obstacle 1. Developers love to write code, not buy code.
Unlike most people, developers are capable of building tools for themselves. In fact, developers love building tools for themselves, even if it means reinventing the wheel.
"Why should we use your bug tracking tool, when our team has super special needs, and the only option is a custom-built system?"
"Why should we use any of the hundreds of project management systems that exist? We only need 5% of those features, so we should build our own. And we’ll even get to try out new framework X!"
Get used to hearing reasoning like that. Rarely are developers cool with buying software that they can "easily" create themselves.
Obstacle 2. Developers don't trust code written by others.
Quite often developers believe they are the only ones who know how to write software correctly. Design patterns, test coverage, continuous integrations, microservices, and other buzzwords are their bread and butter.
Imagine that some other so-called-professional comes to them offering solution-X-built-with-alien-framework-Y. Not a chance.
Things get even worse if developers have to integrate your code into their own systems. They’ll have dozens of suggestions for how your API should work differently or return other formats.
Obstacle 3. Developers hate ads and are allergic to marketing bullshit.
To be honest, we all hate ads nowadays. But for some reason — maybe due to their computer savvy and the sheer amount of time they spend on the web — developers are especially skilled at ignoring banners and ads. They can smell them from a mile away.
Fancy slogans like, "Our software performs 5x faster," will be met with, "Oh really? Let’s test it and prove you wrong!" (And they will!)
So, what can we do?
Ok, let’s stop crying and get to the positive side of things — it’s not that bad, after all. There are ways to conquer developers' hearts and minds.
I’ve been on both sides: 15 years of experience as a web-developer, using free and premium tools, and now I've switched to selling them myself. During those years there were numerous lessons learned, so maybe this article will help you to avoid the same mistakes I’ve made.
Lesson 1. Developers don't have time to save time.
After we launched QuickAdminPanel, we wanted to show off everything we’d worked so hard on. When users signed up for a free trial, we ended up bombarding them with dozens of features, fields, and checkboxes.
Most of these features were optional, but guess what? They scared people off. We had to strip almost everything away to get developers to stick around.
It’s likely that your product is aimed at saving time for developers. But the problem is that they don’t have time to try out new tools and adapt to other workflows, even if they’re better in the end.
In our case, our tool for generating admin panels competes against code snippets developers have from their previous projects. Once they’ve re-used code all their lives, why should they bother changing their habits?
So when you actually convince developers to try your software, make the first success ridiculously easy and quick. They need to feel the impact immediately, without filling in dozens of forms or integrating APIs.
Finally, what if they currently use another product, similar to yours? Find out which one, and then think about potential data migration, integration, etc. Make it easy for them to switch to your product, up to the point of helping them manually, like Nathan Barry has done with ConvertKit.
Lesson 2. Only developers can sell to developers.
I admit, I like creating stuff. All developers do. So when I started my company, I put all my focus on building the product and hired others to do the rest.
For our first attempt at outbound sales, I hired a remote sales guy to find potential developers on Twitter and contact them. He was an IT person himself, but not a developer. He didn’t know much at all about the technical details of the Laravel framework, and it showed. Luckily, he only contacted a few prospects before resigning — otherwise the reputation of our product (as well as my personal reputation) would have suffered.
There’s a saying that everyone has to do their job. Developers need to write code, and sales people need to sell the results of that code. But if you’re a technical founder selling to other developers, you need to take off your dev cap and start selling.
You see, only a developer can explain technical stuff to other developers and answer all the questions and doubts. Conversations with salespeople, even if they’re trained to some extent, usually end with, "I'm not sure. Let me check with my team and get back to you".
You have to be a part of the developer community. Your "selling" process should be participating in StackOverflow forum discussions, replying to tweets with questions, writing posts about best practices (more on that later), and more.
Your developers should be doing support, too. Especially in the case of live-chat support (we use the free Tawk.to), I'm the one answering all the questions. We don't get that many right now (about 3-5 chats per day), so I can handle it myself. But if we grow and need to scale, support will be handled only by developers, not outsourced to some random call center in East Asia.
Lesson 3. Use your product yourself, and make sure everybody knows it.
I started tweeting about the first versions of QuickAdminPanel from the very first working screenshots, sharing my experience with messages like, "Gosh, it was harder than I expected," and "Did you know Laravel framework had this function?"
It worked very well. There was no direct impact immediately, but later I noticed customers coming to us because they had seen me tweeting, so they'd become "silently engaged."
The best scenario is when you or your team are regular users of your product. Not only does it help with product development, but it helps with marketing, too.
Another topic to mention here — video demos and screencasts. There are two types of them: the "official" ones to put on your homepage, and casual or even live-coding videos where you just show what you’re doing in front of the camera.
Short explainers should be probably done by a professional video team, but you can always shoot amateurish sessions, just talking about your product. It doesn’t have to be perfectly shot, it may have bugs and glitches, you may fail at something during video — it’s all fine. Show the human side, how you use the product, and talk to the camera/people.
I have a YouTube channel called Laravel Business, and sometimes I shoot demos for QuickAdminPanel under the same brand. Here are my top results:
- Build Laravel Sports League app with QuickAdminPanel: 3777 views, 32 upvotes
- Creating Laravel 5.4 LMS. Part 1: Start with QuickAdminPanel: 1810 views, 31 upvotes
- Build Laravel Appointment Schedule app with QuickAdminPanel: 1239 views, 13 upvotes
And all those videos are just screencasts of me doing live-coding session (or, should I say, live-generating), with my face in the bottom-right corner:
I simply click "Start Recording" in Camtasia Studio and start talking. Sometimes I edit out some parts if there were major fails or bugs on the screen, but for the most part the video is served to viewers as-is, and it works.
Sometimes I get totally unexpected comments from the audience, like this email:
Lesson 4. Use content marketing to solve your customers' problems, not to sell to them.
One of the best visitor sources to our homepage is an article I wrote comparing 13 Laravel Admin Panel Generators. Ours was mentioned only as one on the list, with a full disclaimer that I’m a founder but trying to write an honest market analysis, which I did.
Be picky about what you write about and where you publish it. Your content has to solve real problems for potential customers, and you need to publish it where those customers hang out and are likely to see it.
What content doesn’t work well for developers:
- Top X reasons why to use X (if they already use X, they don’t need to know why)
- How to deal with edge-case scenarios in your software (will be relevant only to a few)
- Look at our new feature, it will change your world (they don’t care about your features)
On the other hand, what does work:
- Best practice guides, how to do X
- Best tools reviews
- Market competition analysis
Lesson 5. Developers are obsessed with features. Or are they?
Early on in my company’s life, we positioned QuickAdminPanel as "a CRUD builder with extra modules," and we emphasized all of the various features inside of system. We continued to launch more and more modules, but eventually noiced that our marketing messages weren’t really hooking people. It was like they didn’t even notice our new features. Then it struck me.
- Instead of "Stripe integration module," we should have said, "Allow your customers to pay for premium package with credit card."
- Instead of "AJAX Datatables," we should have said, "Have large amounts of data? No worries, we will handle it."
- Instead of "Filtering by active users," we should have said, "Create multi-tenant applications where everyone can only see their data."
The list goes on. When talking about your product’s features, choose your words carefully. Talk about solving real problems for your customers, not showing off what you’ve done.
Also keep in mind that you shouldn’t write directly about your product. Articles like "How to use X" will convert only if someone is already familiar with X and wants to know more. At first you need to hook people with solving their problem. In other words, you should write about "How to do smth with X" and first part of the article should be written about the problem, not your solution.
Even better — you can write a course how to solve the problem without your solution, and then finally show how it’s done 10x faster with X. We’ve done that with a free course called How To Create Admin Panel in Laravel 5.4. It has eight lessons, and the last one is called, "Do it all much quicker with QuickAdminPanel." Worked like a charm.
Lesson 6. Open-source does not mean free. "Sell" on GitHub!
In the early days, our potential customers were asking questions like, "So, can you show us how it actually works?" Blog articles are too long to read, explainer videos are hard to shoot, so we went another way — featuring the demos as open-source projects.
We had the luxury of actually generating some projects with our tool, and with a few changes release them as standalone products. Here are a few examples:
- Larancer: system for freelancers to manage their clients/projects/income
- LaraQuiz: Laravel 5.3 based quiz system
- Laravel 5.4 adminpanel starter project with roles-permissions management
Also, we have an open-source version of our generator. You could look at it as a "free trial" version, too.
As a result, GitHub is our #3 source of visitors. See the monthly stats below:
Let’s get back to the thought that developers trust other developers like them. As a part of this marketing strategy, you should participate in the open-source community.
Create a few tools on topics, related to your premium offer. Put them on GitHub. For free. Support them, react to the issues, release updates from time to time. It gives you a lot of karma points in the community.
What also worked for us was putting links to our premium tool into all descriptions and readme files.
Our message to the community: these small products are free, but if you want to have some more — come to us and purchase. Works really well and brings many customers.
Lesson 7. Who are you actually selling to?
Sometimes it’s not the developer who pays the money for software. If you’re dealing with B2B sales and your client is a company, then usually the "recommendation" comes from a developer or CTO, but the "money approval" comes from higher management.
You have two options:
- Somehow convince that technical guy that they absolutely need your tool;
- Or transform marketing message to the management language.
For us, instead of saying, "You will generate a Laravel project with our tool," we had to change the message to, "Your company will save hours or days on not writing basic code for every project."
We had a few customers like this, and in the end had to group them as a totally separate segment, even releasing a special agency plan with features like team accounts or whitelabeling.
Also, if you’re selling to companies, it’s a wonderful opportunity to earn even more money. They typically have bigger budgets to spare than solo freelance developers. But, on the other hand, be careful to not be distracted by their requests for personal features. Your product vision and roadmap should be aimed at majority of the market, not edge-cases.
Lesson 8. Developers trust their tribe. Almost blindly.
There’s an emerging trend called "influencer marketing," and it’s especially effective in the world of developers.
We were "lucky" that I was actively blogging about Laravel framework for more than a year at LaravelDaily.com, with 3000 visitors hitting website daily. I’m also really active on Twitter, posting various useful links about the framework. So my personality could be considered as influencer and somewhat an unfair advantage. But this influencer doesn’t have to be directly from your team.
Speaking of Twitter, I highly recommend this social network for marketing to developers specifically. For some reason, 140 characters are a better form for developers to express themselves. I know a lot of programmers who use Twitter but not Facebook or Instagram.
But my recommendation is not only posting: you should also reply to people you consider influencers. After a few conversations you will likely have their permission to ask for some help in testing your product, or even promoting it. Just write a direct message.
It also works with guest-blogging. I’ve already mentioned my successful review-article on Laravel News — it’s one of the most popular resources in Laravel community. Developers trust whatever is written there. If you publish your article on someone’s blog which is less known or not trusted that much, the results won’t be as good.
Quick tip on guest-blogging: make sure that the link to your product would be inside of the text in some relevant context, as a totally "natural" source that readers would like to check out. If you leave your link only in your signature at the bottom, no one will click it. If you add a link in the very beginning, it may be considered a sponsored article. (Developers hate marketers, remember?)
Lesson 9. Be there with the crowd.
This example is not our own, but I’ve seen quite a lot of companies sponsor events for developers. They usually have their own branded booth with some goodies — t-shirts, giveaways, vouchers.
However, use this approach with caution. I’ve seen this both working like a charm, and failing miserably. The key is to actively engage with the crowd — not only by answering their questions, but going out to them and talking about topics outside of your product.
What also works extremely well is some kind of entertaining game, released specifically for that conference. People will have fun, while also remembering your name and brand. Win-win. Latest example is Laracon US 2017 special typing challenge by Tighten Co.
Lesson 10. Don’t pretend to be Microsoft if you go solo.
Remember a few lessons ago I told I was active on Twitter? That was my "official" LaravelDaily account which I used mostly to promote my freelancing services. But for QuickAdminPanel I saw something was different. It felt too official and was understood like branded PR messaging. Didn’t work too well.
When I changed the strategy and started tweeting more from my personal account rather than the official one, I saw more engagement: replies, retweets, followers, also customers.
Final thought and lesson is about being a human. A lot of companies are engaging with potential customers from their corporate accounts. Guess what, no one wants to follow an unknown startup. But people like to follow interesting people.
So my suggestion is to broadcast messages from official accounts, but also power it up by engaging with the accounts of founders or developers. Every little bit helps.
I love this quote (not sure about the author): "There is no more B2B or B2C. It’s Human to Human, #H2H." So try to be a human and sell to people personally. At least in the beginning, while you can afford to talk to every customer, it’s really powerful and also a great feeling.
Bonus lesson: It’s all about trust.
As an extra thought to leave you with, I want to motivate those who have just launched and are disappointed with their first results. Calm down and don’t panic. It’s a rare case when startups take off immediately. It takes time.
It’s not only about time or your product features. Look at it from the perspective of your customers. In the beginning, you’re nobody to them. They don’t trust you or your product. They won’t give you their precious data at first.
Partly, the reason is that in the software world, a huge number of projects are abandoned within the first year as unsuccessful. Therefore consumers get used to having a "this is just another startup that’s probably going to fail" reaction, and they wait for some time until giving things proper attention.
However, if you’re still around after a year or so, and growing stronger with your feature base and marketing messages, and also getting your first testimonials from the community, then the snowball effect may start. That happened for us. At some "tipping point," our numbers just started growing significantly, and we reached new customer communities and got more exposure. People started trusting us.
So with that, I wish you all the best, and I hope my personal lessons were useful. Hit me in the comments if you want to discuss further!