What do you think?
Rate this book
Developer Marketing Does Not Exist: The Authentic Guide to Reach a Technical Audience
Learn to authentically engage with developers to attract more of them to your product. Typical marketing tactics will fall flat on an audience of developers that sniff out anything promotional. Most developers are too skeptical to fill out lead forms or provide you with their real email address, which leaves you staring at your analytics with questions the data can’t possibly answer. To reach a technical audience, you must acknowledge that developer marketing does not exist. Then, once you put away your marketing toolbox, you can begin to authentically engage with developers, a first step towards cultivating future customers. Adam DuVander has worked with dozens of developer-focused companies to help them attract millions of the right developers to their products. Developer Marketing Does Not Exist will help you uncover what will actually resonate with your technical audience so you can start to reach more developers.
- GenresBusinessNonfiction
122 pages, Kindle Edition
Published May 10, 2021
55 people are currently reading
368 people want to read
About the author
Adam DuVander
5 books4 followersAdam DuVander has written for WebMonkey, Wired.com's web developer resource, since 2000. He has presented his work at SXSW and O'Reilly's Where 2.0 conference. DuVander founded Portland Web Innovators and sits on the board of Portland nonprofit Legion of Tech. He blogs at mapscripting.com.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 6 of 6 reviews
May 30, 2021
This book is definitely worth 4.5-5 stars, but please keep in mind the following remarks:
* this is not a book for developers
* this is not a book for building a software product/service strategy
* this is not a book about building a professional community (around the topic, product, etc.)
This IS a book about developer marketing - exactly this very topic. Probably the only one so far. Rather a booklet than a book (in fact), but it covers the topic well enough. So it's a book for marketers who'd like to deliver a convincing, credible message for developers who are the potential customers/users of a particular product.
What's interesting, this book doesn't cover many answer to the question: "WHY?" (why developers prefer X to Y, why Z attracted developers but doesn't anymore? why developers are allergic to K?) Initially I was surprised, but I've figured out that: probably it would not be possible to make it fully understandable for marketing ppl, but also: do they really care? They don't have much impact on the actual product they bring to the market, only on how it's presented.
So, once you embrace the idea of what standpoint this book represents and who is it for, there's no better book on the topic available. It's well structured, occasionally funny, has got engaging intros to every chapter. The only clear drawback was the price - a bit too much for such a short booklet.
* this is not a book for developers
* this is not a book for building a software product/service strategy
* this is not a book about building a professional community (around the topic, product, etc.)
This IS a book about developer marketing - exactly this very topic. Probably the only one so far. Rather a booklet than a book (in fact), but it covers the topic well enough. So it's a book for marketers who'd like to deliver a convincing, credible message for developers who are the potential customers/users of a particular product.
What's interesting, this book doesn't cover many answer to the question: "WHY?" (why developers prefer X to Y, why Z attracted developers but doesn't anymore? why developers are allergic to K?) Initially I was surprised, but I've figured out that: probably it would not be possible to make it fully understandable for marketing ppl, but also: do they really care? They don't have much impact on the actual product they bring to the market, only on how it's presented.
So, once you embrace the idea of what standpoint this book represents and who is it for, there's no better book on the topic available. It's well structured, occasionally funny, has got engaging intros to every chapter. The only clear drawback was the price - a bit too much for such a short booklet.
November 21, 2023
This was a useful book. Plenty of action items and simple frameworks. Also quick and entertaining read.
My favorite quotes from the book:
“Developers sniff out anything that smells like marketing. They are a tough audience, because they’ll ridicule you if they sense inauthentic motives.”
“Developers have high expectations and are extremely skeptical.”
“Your marketing messages to developers should not feel like marketing. You need to find ways to promote your product without promotion. With hype comes skepticism.”
“You can reach more developers if you shift away from seeing yourself as a marketer. Yes, that word may be in your title, but reframing toward education will help you find the mindset to attract a technical audience.”
“Your product announcements will become much more impactful when you’re sharing knowledge, not features. So will everything else you publish.”
“Three common types of developer content—blog posts, tutorials, and guides—each get their own chapter.”
“If your developer portal could have only a single element on it, I would choose a big button that says, “Get Started.”
“For a first experience, you want to decrease the “Time to Hello World,” the gap between reading the document-ation and writing the first bit of code on their own machine.”
“Avoid These Common Getting Started Mistakes”
“1. Don’t put your product first. Yes, developers are getting started with your product, but the use case should still be front and center. Choose a common problem and show how to solve it with a subset of your full functionality.”
“2. Don’t include a bunch of concepts. Sometimes there’s context that you need to know before using your product. Don’t front-load it within your getting started. Instead, drip out the concepts as needed during the first experience. You can always link to the full concepts documentation.”
“3. Don’t cover everything. Remember the car salesperson doesn’t walk you through the manual. Developers aren’t looking for a lengthy guided tour. You should get them as quickly as possible to experiencing your product. That’s it.”
“4. Don’t have multiple getting started guides. You’ll have many tutorials, and some may be introductory in nature. But there should be one initial experience, staking a clear claim of what you expect developers to do first. You might have different versions of the getting started guide for multiple languages, but you can guide them through a single place to make that selection.”
“5. Don’t go too long. Since this is a first experience, you want it to be consumable in one sitting. So, keep it short. Once you’ve explained the minimum information needed to see the potential in your product, end the guide. You can always suggest some next steps at the end of the guide, with handy links for developers who are ready for more.”
“Until developers have the first experience, you’re simply a tool that might help them.”
“Imagine you want to learn the piano and you’ve never touched a keyboard. A piano teacher might first show you how to find middle C and to play a simple scale starting with that note. That’s the first experience, but you’re a long way from playing a complete song. Your next step would be to learn a few chords, or a simple melody. That’s where you’d first feel success, like you were on your way to learning piano.
For developer experience, the first success is when developers have something that feels like a complete app or integration.”
“The key is to seed a developer’s imagination with common use cases so they can grow their own ideas. You aren’t stifling creativity or limiting possibilities by sharing the ways others use your product. It’s quite the opposite.”
“A great sample application will include: Full code needed to run the app
- Walkthrough tutorial explaining how it works
- GitHub repository that includes code and basic documentation Working demo to show how it looks when complete (optional)
- One click installation in cloud hosting, like with a Heroku button (optional)
- Case study of a customer who successfully runs something similar (optional)
- Interactive code explorer to pull in tutorial content while viewing the code (optional)”
“Some companies see sales as a speed bump that separates the serious prospects from the tire-kickers. Developers see it as more than a speed bump; it’s a blocked road—and they want to kick the tires. That’s how developers understand things. Provide a self-serve option, in whatever way you can, so that developers get a chance to check out your product for themselves without first having a conversation.”
“Related to self-service, developers don’t want any gotchas. Salespeople provide gotchas, which is why developers want to be able to sign up on their own. Similarly, “call us” and other hazy pricing practices make developers nervous and skeptical.”
“The best way I know of reaching developers is through frequent, helpful blog posts.”
“While your blog posts should always be outwardly-focused on the developer problems, each should harness the company point of view. What do you believe that competitors don’t? Make sure your blog posts spread that belief.”
“Here is the tutorial structure in four elements: 1. Explain the context 2. Show the end result 3. Walk through the steps 4. Help them take the next step”
“Someone on your team will always be able to approve, reject, or change the edits anyone submits. To fully embrace your developer community, you can extend edits to your entire site—yes, even the marketing pages.”
“In a talk at Heavybit Accelerator, Runscope founder John Sheehan identified three rules for using the Runscope playbook: 1. Don’t require a sign up
2. Do one thing well
3. Make it free”
“Developers are more likely to share a tool that doesn’t have a catch—such as a required signup or a paid plan. Just like a gated guide, a simple tool that requires an email address will increase skepticism. Finally, it’s easier to recommend something that solves a specific problem rather than a multipurpose tool.”
“You may not think of documentation as marketing, but you should.”
“Enter into long-term partnerships, not quick growth tactics. Find someone already interacting with the right developers and explore partnership opportunities. It doesn’t necessarily have to cost a lot.”
My favorite quotes from the book:
“Developers sniff out anything that smells like marketing. They are a tough audience, because they’ll ridicule you if they sense inauthentic motives.”
“Developers have high expectations and are extremely skeptical.”
“Your marketing messages to developers should not feel like marketing. You need to find ways to promote your product without promotion. With hype comes skepticism.”
“You can reach more developers if you shift away from seeing yourself as a marketer. Yes, that word may be in your title, but reframing toward education will help you find the mindset to attract a technical audience.”
“Your product announcements will become much more impactful when you’re sharing knowledge, not features. So will everything else you publish.”
“Three common types of developer content—blog posts, tutorials, and guides—each get their own chapter.”
“If your developer portal could have only a single element on it, I would choose a big button that says, “Get Started.”
“For a first experience, you want to decrease the “Time to Hello World,” the gap between reading the document-ation and writing the first bit of code on their own machine.”
“Avoid These Common Getting Started Mistakes”
“1. Don’t put your product first. Yes, developers are getting started with your product, but the use case should still be front and center. Choose a common problem and show how to solve it with a subset of your full functionality.”
“2. Don’t include a bunch of concepts. Sometimes there’s context that you need to know before using your product. Don’t front-load it within your getting started. Instead, drip out the concepts as needed during the first experience. You can always link to the full concepts documentation.”
“3. Don’t cover everything. Remember the car salesperson doesn’t walk you through the manual. Developers aren’t looking for a lengthy guided tour. You should get them as quickly as possible to experiencing your product. That’s it.”
“4. Don’t have multiple getting started guides. You’ll have many tutorials, and some may be introductory in nature. But there should be one initial experience, staking a clear claim of what you expect developers to do first. You might have different versions of the getting started guide for multiple languages, but you can guide them through a single place to make that selection.”
“5. Don’t go too long. Since this is a first experience, you want it to be consumable in one sitting. So, keep it short. Once you’ve explained the minimum information needed to see the potential in your product, end the guide. You can always suggest some next steps at the end of the guide, with handy links for developers who are ready for more.”
“Until developers have the first experience, you’re simply a tool that might help them.”
“Imagine you want to learn the piano and you’ve never touched a keyboard. A piano teacher might first show you how to find middle C and to play a simple scale starting with that note. That’s the first experience, but you’re a long way from playing a complete song. Your next step would be to learn a few chords, or a simple melody. That’s where you’d first feel success, like you were on your way to learning piano.
For developer experience, the first success is when developers have something that feels like a complete app or integration.”
“The key is to seed a developer’s imagination with common use cases so they can grow their own ideas. You aren’t stifling creativity or limiting possibilities by sharing the ways others use your product. It’s quite the opposite.”
“A great sample application will include: Full code needed to run the app
- Walkthrough tutorial explaining how it works
- GitHub repository that includes code and basic documentation Working demo to show how it looks when complete (optional)
- One click installation in cloud hosting, like with a Heroku button (optional)
- Case study of a customer who successfully runs something similar (optional)
- Interactive code explorer to pull in tutorial content while viewing the code (optional)”
“Some companies see sales as a speed bump that separates the serious prospects from the tire-kickers. Developers see it as more than a speed bump; it’s a blocked road—and they want to kick the tires. That’s how developers understand things. Provide a self-serve option, in whatever way you can, so that developers get a chance to check out your product for themselves without first having a conversation.”
“Related to self-service, developers don’t want any gotchas. Salespeople provide gotchas, which is why developers want to be able to sign up on their own. Similarly, “call us” and other hazy pricing practices make developers nervous and skeptical.”
“The best way I know of reaching developers is through frequent, helpful blog posts.”
“While your blog posts should always be outwardly-focused on the developer problems, each should harness the company point of view. What do you believe that competitors don’t? Make sure your blog posts spread that belief.”
“Here is the tutorial structure in four elements: 1. Explain the context 2. Show the end result 3. Walk through the steps 4. Help them take the next step”
“Someone on your team will always be able to approve, reject, or change the edits anyone submits. To fully embrace your developer community, you can extend edits to your entire site—yes, even the marketing pages.”
“In a talk at Heavybit Accelerator, Runscope founder John Sheehan identified three rules for using the Runscope playbook: 1. Don’t require a sign up
2. Do one thing well
3. Make it free”
“Developers are more likely to share a tool that doesn’t have a catch—such as a required signup or a paid plan. Just like a gated guide, a simple tool that requires an email address will increase skepticism. Finally, it’s easier to recommend something that solves a specific problem rather than a multipurpose tool.”
“You may not think of documentation as marketing, but you should.”
“Enter into long-term partnerships, not quick growth tactics. Find someone already interacting with the right developers and explore partnership opportunities. It doesn’t necessarily have to cost a lot.”
July 4, 2025
Great guide for getting started with developer marketing. As someone whose career has spanned technologies, it was a good reminder of the nuances of reaching developers and the specific focus that requires!
October 16, 2025
Actionable, short, hitting a bullseye. If you need to market something for developers this is a must read. Personally, I was doing some of these things intuitively. Still, having all dimensions of this nonexistent thing (marketing for devs) covered in one short book it’s a dream come true.
April 21, 2022
Brief, to the point, a lot of practical tips 👌
September 7, 2024
A fantastic resource for the growth marketers and creators new to the devtool industry.
Displaying 1 - 6 of 6 reviews