DevRel Has One Product. It's Not Content.

Developer relations has spent twenty years answering the same question at every budget meeting: what do you actually do? And for twenty years, the field has given answers that undersell it. We make content. We run events. We create awareness. We do evangelism.

All of those answers describe activities. None of them describe the product. And a function that can't name its product will always be the first line cut in a hard year.

So let me name it. After nine years of doing this work from both sides, inside a vendor and leading an independent community of 210,000 developers, I've become convinced of something simple: developer relations has exactly one product, and that product is trust.

The problem DevRel actually solves

Every technology company has the same structural problem. The people who decide which technology gets adopted are developers, and developers do not believe marketing. Not because developers are cynical, but because they can check. Marketing says the product is easy; the developer installs it that evening and finds out. No other audience can verify claims this fast, and no other audience punishes false claims this hard.

That's the gap DevRel exists to close. Not by shouting louder, but by being the part of the company that developers can actually believe: people who built the thing for real, who say "I don't know" when they don't, who tell you when the product is the wrong fit. A company cannot buy that credibility. It can only employ people who have it and then not ruin them.

Everything DevRel does, the talks, the demos, the docs, the community work, is packaging around that one product. When leaders confuse the packaging for the product, they get a content factory that developers ignore. When they understand the product, they get the one voice in the market that still lands.

Adoption is the business model. Leads are someone else's.

Here's where most companies get the economics of DevRel wrong: they measure it in leads, and leads belong to a sales motion that developer products don't follow.

Enterprise software used to be sold top-down. Marketing generated a lead, sales called the buyer, the buyer signed, and the users got whatever was bought for them. In that world, leads are the right metric, because a lead is the start of the revenue chain.

Developer products win the opposite way. A developer picks a tool on a Tuesday afternoon because it solved their problem. No form was filled in, no salesperson was involved, nobody upstairs knows yet. They use it, it works, a teammate copies it, the team standardizes on it, and months later procurement gets a request to formalize what already happened.

The purchase is the last step of adoption, not the first step of a funnel.

That's the chain: trust leads to adoption, adoption leads to revenue. The developer trusted the honest talk, the working quickstart, the advocate who said "this part is not ready yet." So they tried it. Trying became using, using became spreading, spreading became a contract nobody had to sell.

Measure that chain with leads and you break it. A developer forced through a lead form before the download is a developer using your competitor by dinner. The gate that creates the metric kills the adoption the metric was supposed to predict. This is the quiet tragedy of DevRel teams judged on marketing numbers: they get pushed to do the exact things that stop the thing they're good at.

So when the budget meeting asks what DevRel produces, the full answer has three levels. The product is trust. The outcome is adoption. The revenue arrives later, bottom-up, signed by someone who never saw your campaign. It's harder to attribute, and it's how every major developer platform of the last twenty years actually won.

Why the content era of DevRel is over

For a long time you could get away with the packaging. Content was scarce, so producing tutorials and videos looked like the job, and view counts looked like the results.

That era just ended. Models now produce competent tutorials, overviews, and getting-started content on demand, for free, personalized to the person asking. A developer with a question doesn't wait for your video anymore. They ask a chat window and get an answer in seconds.

And let's be honest about what that content was achieving even before the models arrived. Take the next product video: ten thousand views, the dashboard is green, someone celebrates in the team channel. Now look one row deeper: average watch time, ten seconds. Ten thousand people saw a logo and an intro animation, then scrolled on. Nobody learned anything, nobody built anything, nobody came back. That's not developer relations. That's brand awareness, which is a fine thing to buy, but it's marketing's product, made with DevRel's budget and measured with marketing's ruler.

Compare that with thirty developers in a workshop who all deploy something before they go home, or a quickstart that an agent completes on the first try. Smaller numbers, real adoption. If your dashboard can't tell the difference between ten seconds of scrolling and an evening of building, your dashboard is measuring the wrong job.

Here's what that means, and I don't think the industry has fully absorbed it: every part of DevRel that was secretly content production is being automated right now. Teams built as content factories will be cut, and honestly, correctly so, because their product was never trust. It was volume, and volume is free now.

Scarcity moved. It used to be information. Now it's credibility.

What can't be automated is the reason the function exists. When every answer is generated, developers ask a new question: who do I actually believe? The person who built it for real, hit the real problems, and has a track record of straight answers becomes more valuable, not less.

Trust has two audiences now

There's a second shift, and it's stranger: your product's reputation now lives partly inside the models.

When a developer asks an AI which tool to use, the answer comes from what the model learned and retrieved: your documentation, your community's discussions, the honest and dishonest things said about you across the internet. If the model explains your product wrong, or doesn't mention it at all, that's a relations problem with an audience that never attends your conference.

So the discipline splits in two directions at once. Toward machines: documentation written for retrieval, MCP servers that let agents actually use your product, correcting what the models get wrong. Toward humans: the rooms, the community, the credible person on stage. I've watched the human side grow, not shrink, as answers became free. We ran 67+ free AI conferences in 36 countries this year, with every talk available online, and the rooms filled anyway. When machines take the answers, people come for each other.

The companies that win the next decade of developer adoption will be trusted by both audiences: recommended by the models, and believed by the humans.

What this means if you lead

If you run a company or a DevRel team, this view changes four decisions.

What you measure. Reach measures packaging, and leads measure a sales motion that isn't yours. Measure the chain instead: trust first, who came back, whether the community defends you when you're not in the room, whether the models describe you correctly. Then adoption, who built something, whether an agent can complete your quickstart, how usage spreads inside a company. Harder to count, and worth more.

Who you hire. Credibility can't be taught; presenting can. Hire builders, teach them to speak. A team of great presenters with nothing behind the slides is a marketing department with a GitHub account.

Where the function sits. If DevRel reports into marketing and is judged on leads, you've told it to sell trust, which destroys trust. The function works when it's allowed to say "our product is wrong for this," because that sentence is what makes every other sentence believable.

What you protect. Trust compounds slowly and spends fast. Every exaggerated claim, every community treated as a lead list, every advocate forced to read a script withdraws from an account that took years to fill. The discipline is saying no to the withdrawal that looks profitable this quarter.

The stake in the ground

Here's my prediction, so you can hold me to it. In the next few years, developer relations splits. The teams that were content factories get automated away, and their companies will conclude DevRel didn't work. The teams that were trust functions become more strategic than they've ever been, because they'll be managing the scarcest resource in a market where everything else is generated.

Same job title, opposite futures. The difference is whether the company, and the team itself, knows what the product is.

It was never the content. It was never the views. It's trust, earned by real people who built real things and told the truth about them. That was the product twenty years ago, it's the product now, and it will be the product when today's models are exhibits in a museum, standing behind glass next to Shakey.