Developer Relations Is a Product Decision

Developer relations is the function that makes developers outside your company successful with your product. Search the term and page one hands you that definition and a stack of job descriptions. Useful if you are deciding whether to take the job. Useless if you are the founder deciding whether the job should exist, what it should own, and what it changes about the product you are already building.

A better answer shows up in a conversation where nobody says the word. Katelyn Lesse, head of platform engineering at Anthropic, and Angela Jiang, head of product for the Claude platform, sat down with Sequoia to talk about building an ecosystem instead of a walled garden. Read it as a developer relations conversation and the pattern is hard to miss: every lever they pull is a product lever. Which primitives to expose. Whose infrastructure the work runs on. Which pieces to hand the whole industry as a standard rather than keep.

If you build anything other developers plug into, an API, an SDK, an agent, a protocol, those choices are your devrel strategy. The blog posts and the conference talks are downstream of them.

What developer relations actually is

Concretely, the function owns documentation, SDKs and sample code, the path from signup to a first working call, public support, integrations and standards, and the loop that carries what builders struggle with back into the roadmap. The boundaries are what people get wrong. Developer marketing owns awareness. Developer experience owns the interface. Support owns the ticket after something breaks. Devrel is accountable for the whole path and for reporting back what that path is missing.

It gets filed under marketing because its outputs look like content. It belongs next to product because its inputs are interface decisions. A developer who cannot get a non-trivial example running in an afternoon does not need better content. They need a different interface. That is why developer strategy belongs in the same conversation as product, pricing, and go-to-market, which is how we frame it in AI for startups.

Anthropic's platform team states the goal in product terms. Jiang describes the external north star as being able to "give any builder the tools to be able to work with Claude to build whatever they want to build." Deliberately broad, and broad goals only become real through a series of narrow choices. The rest of this article is those choices.

Ship the same primitives you ship yourself

Anthropic's platform serves two customers: outside developers, and Anthropic's own product teams building on the same layer. Plenty of companies split those, running a rich internal API and a thinner public one. This team deliberately does not.

"We want to have the same primitives that are available to everyone," Jiang says, and the reasoning is not generosity. It is that nobody knows which product shape lasts. It is really hard, she says, to figure out a long-lasting form factor, and she points out that two years ago everything was chat and now everyone has moved to agents. A platform built only for your own product's current shape ages at the speed of that shape.

Lesse adds the discipline that keeps dogfooding honest. Internal users have specific requirements, external users have different ones, and over-indexing on either is a trap. So the team will dogfood "something internally at the same time that we open up early access of some sort with external customers," which gets both signals in before a primitive hardens.

The founder version of this is a twenty-minute audit. List every internal endpoint, flag, or helper your own product calls that a paying customer cannot. That list is your real devrel backlog, and it is more honest than any survey.

Decide which layer you sell at

Jiang describes the platform as three layers of a cake. Knowledge is the bottom: what the model needs to know and how you hand it over, which is the shape of the Messages API, tools, skills, memory. Execution sits above it, getting the model to actually do work, which she describes as a low-level harness plus managed infrastructure. Lesse fills in what that infrastructure covers: spawning sandboxes with the right governance and security, and storage around transcript sessions so a run can be stopped and picked back up later. Coordination is the layer the team is moving into now, composing strategies where different tokens get different jobs, one advising, one executing, one dreaming. Lesse's version of the same idea adds a grader that checks the work and sends it back when it is not good enough.

The devrel insight is who buys at which layer. For AI-native startups tinkering at a low level, Jiang says, "they're just going to go for the primitives." Everyone else, where squeezing a harness is not the point of the company, reaches for the packaged offering because it is not their core competency.

Same product, two audiences, opposite needs. Your job is to decide which altitude you sell at this year and be explicit with the group you are not serving. Ship only raw primitives and the second group never reaches value. Ship only the packaged product and the first group, who are the people most likely to discover your product's next form factor, will route around you.

Which altitude you pick also decides your revenue motion. Primitives sold to individual developers is a bottom-up motion. A packaged layer sold to a buying committee is not. Choosing between a top-down and a bottom-up sales motion is the same decision seen from the revenue side.

Thomas Wolf, co-founder and chief science officer of Hugging Face, gives the constraint from the open source side on YC Root Access. Treat the library as a product and the community as your clients, he says, and note the bar those clients set: they are "very difficult to please as clients because everything is free so they want actually the best." His design rule is about abstraction count, and it cuts against packaging everything: "each new abstraction you impose your user to learn is like a friction point." Every layer you add to make things easier for one audience is a tax on the other.

Do not be precious about your own infrastructure

The strongest walled-garden instinct is wanting the workload to run on your machines. Lesse rejects it flatly: her team is not precious about whether a customer runs the work on Anthropic's infrastructure or somewhere else entirely.

In practice that shows up as self-hosted sandboxes, so an agent's execution environment can run on infrastructure the customer already has, and MCP tunnels, so an agent can reach a server that never leaves the customer's firewall. What the team keeps an opinion on is the architecture: how agents get assembled so they are reliable and scalable, and the interfaces you conform to. Where the compute happens is negotiable.

That distinction is the whole trade. You defend the interface, not the hosting. Founders usually have it backwards, holding on to the hosting because that is where revenue is metered, then discovering the enterprise customer they wanted cannot deploy them at all. Lesse names that customer directly: the enterprise whose position is that it has a walled garden of its own and needs to figure out exactly how these solutions plug into it. Every hard dependency on your infrastructure is one more reason for that buyer to build it in-house instead.

Give away the standard, keep the interface

Skills and MCP are the clearest ecosystem moves in the interview, and Jiang's reasoning is unsentimental. Claude needs those standards to be useful, so "we can just give them out to the rest of the ecosystem" and work with everyone to get better results across it.

She reaches for electricity as the analogy. It became a transformative utility because you can wire it into everything, which required plugs and conventions no single company could set alone. "They always have to work with the ecosystem and work with partners."

Wolf makes the same bet from Hugging Face, which pivoted from a game company into an open source library that went viral. His framing is that distributing power catalyzes ecosystems rather than cannibalizing them, and that the community around a free library is a demanding customer worth designing for.

For a startup the question is narrower: which piece of your surface is worth more as a shared convention than as a differentiator? It is almost always the connective tissue, the format, the protocol, the schema, and almost never the thing customers pay for. Giving away the connective tissue while keeping the value is a moat move rather than a charitable one, because a standard you authored is a standard shaped like your product. That is the same logic behind what actually defends a company in the AI era: the defensible part is rarely the part you were guarding.

Your documentation is the front door, and agents read it now

Documentation used to be the least glamorous devrel deliverable. That changed when the reader stopped being human.

On YC's Lightcone, the partners walk through a shift in developer tool go-to-market. Ask a major model how to connect a web app to send email and the answer the partners get back is Resend, a Y Combinator company from the Winter 2023 batch. Its founder saw the shift early and posted over a year ago that ChatGPT had become one of Resend's top three sources of traffic, ahead of GitHub and Twitter. Then, in the panel's words, "he actually optimized his documentation to be agent-friendly": pages phrased as the question a person or an agent would ask, answers structured in tight bullets, a parseable code snippet on every one.

The conclusion is worth writing on a wall: "documentation is going to be the front door for a lot of these agents to recommend dev tools." Docs now have to be optimized twice, since the same page "needs to be optimized for humans, needs to be optimized for agents," and given how many more tool-selection decisions agents will make than humans ever have, a small improvement compounds into a large one.

This is the work with the best return for a small team right now, and it needs no headcount. It needs your docs to answer questions in the words a caller would actually use, to include a runnable snippet in every answer, and to be machine-readable: an llms.txt file, clean HTML, and content that survives a plain fetch rather than a JavaScript app that renders nothing to a crawler. If you are still choosing which tools your own team builds on, the same signal works in reverse when you evaluate AI developer tools.

Security is part of the developer experience

Two threads in the interview belong together, and founders usually treat them as separate departments.

The first is that opening a platform means agreeing on safety with companies you also compete with. Jiang frames it without philosophy: nobody wants technology doing negative things on their own service, and cyber is the obvious case, since "we all kind of want to make sure our critical infrastructure is good." Standards work is not only about how systems interoperate. It is also about what everyone agrees not to enable.

The second is that "enterprise-ready security and compliance controls" are what actually unblock deployment. Lesse describes the failure mode precisely: her team ships something genuinely innovative, and the customer says that is really cool, but I cannot use any of it for these reasons. The innovation was never the bottleneck.

The practical version, and I write this as a CISSP: your integration surface is your attack surface, and every ecosystem move adds to it. A connector runs with somebody's permissions. A tunnel through a firewall is a hole you authorized. A third-party skill is code you did not review executing with your customer's context. So publish the security model as developer documentation rather than as a PDF behind a sales call: what scopes exist, what data crosses the boundary, how to rotate a credential, what an integration can and cannot do. Developers read that page before they build, and security review is the step where a promising integration quietly dies.

How to know it is working

Three numbers tell you more than any amount of conference activity.

The first is the time from signup to a first non-trivial result. Not hello world, the first thing a developer actually came for. The second is the share of your active builders who got there without talking to a human, because that number is what tells you whether the path works or whether your team is quietly carrying it. The third is the count of product changes you shipped because an outside builder hit a wall, which is the only proof the feedback loop runs in both directions.

Stars, followers, and talk invitations are inputs at best. And if documentation is now the front door for agents as well as people, add one more: whether the major assistants return your product when someone asks the question your product answers.

What to do this week

1. Run the parity audit. List every internal capability your own product uses that a customer cannot access. Pick the one with the shortest path to public and ship it.
2. Pick your altitude and say it out loud. One sentence naming which layer you sell at, primitives or packaged, and what you tell the audience you are not serving this year.
3. Time your own onboarding. Stopwatch from signup to first non-trivial result, on a machine that has never seen your product. Anything longer than an afternoon is an interface bug, not a documentation bug.
4. Rewrite your three most-read doc pages as questions. Real user phrasing, a runnable snippet in every answer, and publish an llms.txt so agents can read the whole thing.
5. Design one escape hatch. Find the hardest dependency on your own infrastructure and offer the alternative: self-hosting, bring-your-own-key, or a tunnel to what stays behind the customer's firewall.
6. Publish the security page. Scopes, data boundaries, credential rotation, and what an integration is allowed to do. Treat it as developer documentation, because that is how it gets read.
7. Talk to your two weirdest users. The ones bending the product in ways you did not design for are the feedback loop devrel exists to run. Anthropic's platform team found one customer who exposed an MCP server on top of their own agent so other agents could call it as a tool, and another set working with systems so old they have no APIs at all.

Developer relations, done well, is not a department you add once you can afford it. It is the accumulated result of decisions you are already making about what to expose, what to standardize, and whose machine the work runs on. Make them deliberately and the community forms around the product. Make them by default and no amount of content will fix it. That habit, turning a vague function into explicit weekly decisions, is what the AI Operating System for Startups is built to teach.

Sources

• Anthropic's Katelyn Lesse and Angela Jiang: Building an Ecosystem, not a Walled Garden on Sequoia Capital's channel, the conversation this article distills. Every quote attributed to Lesse or Jiang comes from it.
• Roles and backgrounds, confirmed on their own sites and their LinkedIn profiles: Katelyn Lesse (LinkedIn), who leads platform engineering at Anthropic, joined in 2025, and previously led Connect engineering at Stripe, and Angela Jiang (LinkedIn), who leads product for the Claude platform and previously led API at OpenAI and Connect at Stripe. Sequoia's episode page carries the full transcript, which is the authority used here for who said what.
• Lessons from Building Open Source Libraries on YC Root Access, for Thomas Wolf on treating an open source community as demanding clients and on abstraction as friction. His role as co-founder and chief science officer of Hugging Face is confirmed on his personal site and his LinkedIn profile.
• The AI Agent Economy Is Here on YC's Lightcone, for documentation as the front door agents use to pick developer tools, and for the Resend case study. Resend's batch and product description are on its Y Combinator company page; TechCrunch covered the company as a developer-focused email platform. One note on the number: the panel describes ChatGPT as a top-three channel of inbound customer conversion, while the founder's own post frames it as a top-three source of traffic. This article uses the founder's framing.