Don't sell to developers. Focus on value, advocacy and creating internal champions
My thoughts and lessons on selling to developers; and why a focus on value, advocacy and internal champions can help.
Most products talk about B2B (business to business) and B2C (business to customers).
But there’s a third that almost no one ever talks about:
Business to Developers (B2D) - A new term I never heard about until I came across the book The Developer facing Startup (shout out to Shane O’Connor for the recommendation!)
And B2D is a completely different game.
Developers aren’t like “buyers” in the traditional sense. They don’t want to be sold. They hate being pitched. They over-index on truth, clarity, signal. They care about how something actually works — and whether it genuinely solves a problem they have.
Over the past 12 months I have been solo bootstrapping my open source project EventCatalog. Going from $0(mmr) to $16k(mmr), I am learning on the fly and sharing things as I go.
I am no expert on sales, but I have my own thoughts and things I would like to share, that work for me, and hopefully work for someone out there.
Don’t lead with the product
If you want to sell a developer tool, it can be hard. Developers are hard to “sell” too. So the best way around that, is don’t sell them anything.
At some point, early adopters of your tool may want to speak to you. This is great. Above all things, speak to your users.
When you are on a call with developers that want to learn more about your tool, never lead with the solution or the tool. Focus on their problems.
Ask questions and dive deeper, get to the root causes of the problems.
After this, you can then explain or demo your solution focused on their problems. Don’t give them a demo of all the features… just enough to show some value.
If your tool does not do what they want, just say. Either add it on your backlog, or at least keep a note of it. When many developers ask you for the same missing feature, you know what the product is missing.
If they want to continue, suggest they do a proof of concept (still no money is exchanged). Give them access to your paid features, and let them test the return of investment themself (ROI). Will they get the value you suggested?
Help them. Create a CRM and track who you speak to. Create notes, their pain points and get back to them.
Be authentic and help them see the value you believe.
Which brings me to the next point….
Educate and guide internal champions
Developers that contact you are the internal champions. Most time they don’t have the authority or the budget to purchase your tool, but they have the influence to make it happen.
You want to make sure your internal champions are looked after. Help them understand your product/solution and focus on helping them get the ROI they need and the value they need from your product.
Invest your time into them. Go on calls with them. Answer their questions.
Be human about it, don’t sell to them.
If you invest your time into your champions and you may just see return yourself later down the line.
Developers also leave companies, if your tool worked for them at a previous company, there is a high chance they may recommend it in a new company.
Remember when it comes to selling the software, this can take months! Especially if you are selling enterprise software. So keep in touch with your champions and help them!
Advocate for the problem space; not your solution
Many companies hire Developer Advocates to educate the problem space and solutions in that space. I was a developer advocate at AWS diving into event-driven architecture I understand the importance and benefits of advocacy.
When you are building a developer tool, IMO the best way to share your product is to advocate for the problem space (not your solution).
To give you example, I believe that event-driven architectures are great, I’ve spent the last 10 years diving into this niche and ecosystem, and advocate for it. After speaking to 100s of companies I learnt that discoverability is a problem with message based architectures, in fact complexity is a problem and it’s all a shit show under the hood….
I spend most my time focusing on the problem space. How can we make event-driven architecture better for everyone? The talks and blog posts I write around the subject, don’t really talk much about EventCatalog, but the problem space as a whole….
When you lead the problem space with your product or solution, it turn’s a lot of developers off. They disconnect and instantly think it’s a sales pitch. So don’t do it.
Instead, lead with the problem space, advocate for other tools and suggestions, make the pie better for everyone not just you. But to do this, you must give a shit about what you are building and the space in which you are building.
Summary
Selling to developers is hard, so rather than sell just focus on their problems and value you can add.
Help them with anything they need, create internal champions and let them advocate your solution for you.
Help the bigger picture, advocate for the problem space. Your solution is just part of that space… make the place greater for everyone.
Be human; be authentic and the rest will come.
Hope this helps anyone out there that needed to read this or understand it more detail.