Developer Marketing with Adam DuVander
A LaunchDarkly co-founder once spent 80 hours in an engineering class building a working hammer from raw wood and metal. Adam DuVander uses that story to explain the 'Jedi developer mind trick' — showing a reader exactly how hard it is to build the thing your product already solved, without ever mentioning the product.
Adam DuVander is the founder of Every Developer, which helps developer tool companies with strategic technical content, and author of Developer Marketing Does Not Exist and the newer Technical Content Strategy Decoded.
We get into why 'proud to announce' is close to the worst possible headline, why thinking in concepts rather than one-off topics changes what you choose to write, the deliberate craft behind the Jedi developer mind trick, and why engagement, not page views, is the metric worth caring about.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
Why write a second book, when the first one already became something of a standard reference?
The first book, Developer Marketing Does Not Exist, is really the philosophy — drawn from years in developer relations and as a journalist covering developer topics. This new one, Technical Content Strategy Decoded, assumes you already understand that philosophy and gets into the actionable steps for actually doing it — how to create the strategic content developers will genuinely want to find and consume.
Early-stage teams often look at a company like Stripe and feel like they need to match everything Stripe does. Is that the wrong instinct?
It's very easy to get overwhelmed comparing yourself to companies that have been at this for years and trying to do all the things they do at once. What's actually more valuable early on is knowing what you shouldn't be doing yet. With Stripe specifically, the real lesson is in their early landing page, from back around 2011 — you can see how deeply they understood the audience trying to integrate payments at a time when that meant setting up a merchant account and a separate payment gateway, real friction that doesn't exist anymore. They spoke directly to that pain. That's the thing worth learning from Stripe: not replicating their current scale of content, but understanding how they got inside the head of the audience that would love their product.
How does a startup actually start building that kind of deep understanding of its audience?
At some level you have to genuinely understand who that audience is — and if you're a small dev tool team, there's a good chance you started the company because you personally hit a problem big enough that you knew lots of other developers had it too. Whoever's responsible for technical content needs to act as a translator, sitting between the problems developers actually want solved and the product on the other side. One of Every Developer's early clients, Stoplight, makes an API design tool, but most of the content we've worked on with them is about OpenAPI and JSON Schema conventions and best practices — not the product itself, but the underlying problem space it lives in.
You talk about thinking in 'concepts' rather than 'topics.' What's the actual difference?
It's very easy to be scattershot — someone has an idea for a topic, you write it, and there's no real throughline, especially if you've heard advice like 'you need to post every day.' Thinking in concepts means stepping back and treating something like OpenAPI more like a tree you can move up and down through — a huge data format at one level, with distinct branches underneath it, like the data format itself versus how teams collaborate on an OpenAPI spec. Those are related but genuinely different concepts, and which one you choose to go deep on changes who your content actually attracts.
Can you unpack how a single concept like 'collaborating on OpenAPI' turns into multiple topics?
Within one concept you can find many distinct topics — putting your OpenAPI doc into a GitHub repo so changes are visible across the org, or who actually writes different parts of the spec: do engineers write it, do technical writers, is there someone else involved? Different organizations answer that differently, and there are real trade-offs either way — an engineer writing all the dev-facing docs has certain downsides, and a technical writer declaring API paths without knowing the implementation has different ones. If you're being scattershot, you never surface those deeper topics. Thinking through the concept first means the topics you eventually produce have the best chance of actually landing — sometimes that means producing less content overall, just being smarter about which pieces you commit to.
What's the single biggest content mistake you see early-stage dev tool founders make?
Product-focused content — writing straight toward 'you should use our product' or 'here's what's new in our product.' It's natural, because that's what you're excited to share, but it won't resonate the way content about the actual problem your product solves will. There's a scene in The Office where Dwight, stuck on the party planning committee, puts up a barely-inflated, generic gray balloon display for Kelly's birthday with a sign that just says 'It is your birthday' — every chapter of the new book opens with a scene like that, and this one captures exactly what disengaging technical content looks like: technically accurate, but with no opinion, no reason for anyone to care.
Is there a legitimate way to write about something genuinely new without it turning into a generic announcement post?
Announcement posts are genuinely the hardest to write well — when I was editor at ProgrammableWeb, the phrase 'proud to announce' was my signal that a post was really just a product pitch. My rule of thumb is to imagine the headline: 'company you don't know releases product you don't care about' — that's the shape you want to avoid, even though it could describe a huge share of dev tool announcement posts. At some point you do need to say something is new, but that needs a foundation of why the reader should care in the first place. A common trap for startups is a blog whose last five posts are all release notes — technically showing you've shipped, but blending together with no individual reason to click into any one of them, versus each post being framed around something the reader actually cares about, even if release notes happen to be part of it.
You've mentioned LogRocket as an example of a company doing this well. What's their approach?
Think about what your 'beat' would be if you were a media company with no product at all — LogRocket has a genuinely great front-end-focused dev blog that would hold its own as a standalone media property, entirely separate from the fact that LogRocket also happens to sell a tool for front-end developers. That's a bigger scale than most small teams can match immediately, but seeing the early version of that approach — being genuinely helpful in a specific area even without mentioning your product — is a strategy that plants seeds for something that can grow into a much larger property over time.
How does an early-stage team actually know if their content strategy is working?
The 'become a media company' framing has a real downside: a media company wants raw page views because that drives ad revenue, but that's not the goal for a dev tool company. The metrics that actually matter are less about vanity numbers — hitting number one on Hacker News feels great but evaporates the next day — and more about engagement: does someone actually read the piece, and do they take a next logical step, whether that's more content, documentation, or signing up? We had a client whose top-performing post by raw views was a developer jokes post — lots of traffic, but it had zero connection to their actual product, and the audience finding it probably wasn't even developers evaluating tools, more likely friends of developers looking for jokes to tell them. Being technical isn't the same as being useful technical content — you have to be able to draw a real line from the topic to genuine interest in what you sell.
Doesn't that create tension with the advice to avoid product-focused content?
That's exactly why the book has three chapters specifically on translation — your job is to build that connective tissue between a topic and the product, both in how you write it and in choosing topics that have a logical link in the first place. Someone reading deeply about OpenAPI and API best practices is plausibly interested in an API design tool like Stoplight's; someone reading a great front-end resource is plausibly interested in a tool that helps debug front-end errors, which is LogRocket's actual product. It doesn't need to be a direct, one-to-one connection, but the audience for the content and the audience for the product need to genuinely overlap — and then you look at real engagement signals to decide whether to keep investing in that specific concept.
Can you explain the 'Jedi developer mind trick' you've talked about before?
It's describing, in real depth, how someone would solve the problem your product solves without using your product — and going deep enough that the reader feels the weight of it themselves. LaunchDarkly does this well; one of their co-founders has a great talk about an engineering class where she was given wood, metal, and a blueprint and told to build a physical hammer from scratch. It took her over 80 hours, and the result still wasn't as good as one you could buy off the shelf at any hardware store for a few dollars. She learned she could build a hammer, but never wanted to again. That's the trick: show the genuine edge cases and hidden complexity in solving a problem yourself, walk through how you'd handle them, and only then reveal — almost incidentally — that this has already been solved. It's not a head-on 'build vs. buy' pitch; it's closer to 'these are not the droids you're looking for' — you could build this, but by the way, you really don't want to.
So the mind trick genuinely tells people how to build it themselves, rather than just implying it's hard?
Yes — you actually share the real considerations, so that someone sufficiently motivated, or perhaps ill-advised, could go build it themselves. This new book works the same way: my goal is to give people everything they need to actually implement this strategy on their own. Most readers will be able to do it themselves, and some will become clients of Every Developer anyway — that's fine either way, since the other real goal is helping the many companies, especially new startups, who wouldn't become clients regardless, still have a genuine shot at creating great content.
Does that openness connect to how developers generally think about open source and knowledge-sharing?
Very directly — the currency of developers is knowledge exchange. Inside an organization, you have to share what you know about a system so your fellow engineers can build on it, and open source is the same instinct playing out externally. That's a big part of why educating developers, rather than pitching them, works as an approach at all — it matches how developers already relate to information and each other.