What influences developers to adopt a product?
Trust. The tools they adopt and advocate for impact their reputation. You might have heard “no one ever got fired for buying IBM” in reference to making good choices.
But picking older, well-adopted tools can be at odds with how fast the industry moves. Is there a newer alternative that solves my needs better? Ask your developer.
Keeping up the latest trends is part of their job. They need to know what's a fad and what's here to stay. This is why experienced developers become skeptical of almost everything. It's hard to earn their trust.
Developer marketing is about building trust. Here's what's worked for me.
How can I improve my developer marketing?
- Don’t publish content you wouldn’t share yourself.
- Always consider how you can build developer trust. It’s not a one-time transaction. It’s reflected in every product and marketing decision you make.
- When something sucks with your product, own it. Don’t try to hide the failure. Lean into it. Bring the community along for the continuous iteration of your product. “You told us this was bad, and we fixed it”. Follow up with people after you ship.
- Get involved in the community. Host, attend, or sponsor a hackathon or meetup. Spend time talking to developers 1:1. Their feedback drives product improvements and content ideas. Where are people struggling? Write about that.
- Create a developer experience so good that it does marketing for you. Write docs worth sharing, filled with helpful diagrams and detailed descriptions. Create code examples and templates that help developers get started quickly.
Throw out the old playbook
Developers love great marketing, but most companies get it wrong.
They’re trying to apply the enterprise marketing playbook to the wrong audience.
- Enterprise Marketing
- Goal: Grow pipeline and revenue
- Audience: Directors, VPs, or C-suite
- Buyer Interests: Increased efficiency, cost savings, innovation
- How: Sales-served, sign a yearly contract for a discount
- Developer Marketing
- Goal: Grow retained signups and community awareness
- Audience: Individual developers
- Buyer Interests: Transferable skills, affordable, great developer experience
- How: Self-serve, start free then swipe a credit card
What does great developer marketing look like?
I’m a developer who works at the intersection of engineering, product, and marketing. Based on my experience, the best developer marketing:
- Teaches how to build great products
- Builds and retains trust
- Uses precise language
How did they build that!?
When I see a great developer tool, my first thought is: how did they build that?
this is so fast it is actually weird, my brain seems unable to accept such fast UI on an ecommerce website
The fastest storefront I've ever seen. So excited about the new Next.js Commerce powered by App Router. Headless backend by @shopify.
There’s a natural curiosity. I want to reverse engineer the product and learn new tools or skills I can apply to my work.
The best developer marketing shows how to build great product experiences. Bonus points if you capture the “current thing” – a new AI tool, or a popular style of app (TikTok clone).
Great developer marketing is invoking this response as a service.
My first thought was damn the link navigations are snappy as hell
Zero days since the latest JavaScript framework
Developers don’t try your product the first time they hear about it. They certainly don’t want to talk to someone to get access first.
They need to hear positive feedback several times before they trust it enough to try. That's why building, growing, and retaining developer trust is everything.
Trust comes from your marketing being helpful regardless of the product. And retention comes from making something developers actually want.
Individual developers are tired of enterprise marketing being used on them. They’re the wrong audience—they don’t want the cold calls or unhelpful emails. And if you lose their trust, they’re quick to move on to other products.
Trust is built (or lost) through the content you create and put out into the community. It’s a reflection of what you stand for.
Here are some of my red flags when reading developer content:
- Buzzwords and acronyms: Sometimes these are necessary, but there’s a lot of copywriting that looks like “cutting-edge, LLM-powered RAG platform” when it should really be “bring knowledge to your AI model”. Acronyms also alienate newcomers.
- Misusing technical terms: "Our JavaScript framework helps you make responsive websites” – does it though, or is that CSS? This can degrade trust because it shows the author might not have a deep understanding of the subject. Another example is broken or incorrectly formatted code examples. Did they even check that it works?
- Overpromising simplicity: The developer ecosystem is too obsessed with simplicity. I’m guilty. While “get started in one click” might be good sometimes, it can also be harmful. Maybe I want more options? "Simply install our SDK" might not be as simple as it sounds.
- Vague explanations: Developers want a practical example of what your product does. “Utilizing the latest technology to supercharge your development process”. Is this an editor, framework, database, or something else?
Developers are more likely to trust open-source tools. These tools likely have a community of other developers learning together. They can take their knowledge of the tool from job to job as they grow in their career.
Show, don’t tell
Great developer marketing is both concise and precise.
It values your time—every word matters. Show them how to build interesting things, don’t fill a post with 1000 words of garbage.
Consider an email announcing a new version of your product. The pricing has changed, and there's a data migration.
- How can I make it concise?
- Put the bottom line up front: If I stop reading after the first paragraph, did I get what I needed to know? Is there action required? Put that in the email subject line.
- Make it easy to scan: The visual flow of the content is as important as the words you choose. They should be able to quickly scan for landmarks (like code examples or commands they need to run).
- How can I make it precise?
- Address their fears directly: This email mentions a migration. Am I going to lose my data? Do I need to make changes right away? Am I going to be charged more?
- Personalize the content: Show them their team name, the date the migration starts and finishes in UTC, exactly how much their price was before and after, and how they can take action (maybe a CLI command that shows their usage).
What do you want them to remember?
Your product is competing between thousands of others for developer mindshare. You believe yours is better. How do you share that message?
Let the product speak for itself. Listen to customer feedback and iterate. If your marketing isn’t working, their feedback should tell you why.
You’re doing sales because you failed at marketing. You’re doing marketing because you failed at product.
This tweet is provocative, but it makes a point: you can't fix a bad product with more marketing and sales. When you believe in the product, you don’t need to speak down against others. I prefer to do the opposite.
I believe in optimism for software, the web, and the community I’m building. I want people to remember I was helpful, positive, and enthusiastic about the product.
Wait, what about DevRel?
Developer Relations is more than only developer marketing. It's the intersection between product, engineering, marketing, and sales.
For early companies, you might only need DevRel. They are generalists. But as you grow, you need to specialize. Get the right leaders for both developers and enterprise marketing.
Developer marketing leaders come from non-marketing roles (engineering, developer relations). They love showing developers how to build amazing things.
Enterprise marketing leaders come from traditional marketing roles (content, product marketing, growth). They can sell to developers, even if not one, and know how to build a pipeline generating engine.
It’s possible for one person to do both sides of marketing well, but rare.